hellioness

I am not familiar with “Members Only”, but I suspect that that plugin uses it’s own custom login/logout functions instead of WordPress’ standard login/logout. WassUp uses the WordPress function, “wp_get_current_user()”, to identify logged in users. If users don’t log in via WordPress’ standard login or if their alternate login method does not properly set WordPress’ user cookie and data, then “wp_get_current_user()” won’t be accurate, and neither will WassUp.

Do this in your stylesheet or in header.php:

<style type=”text/css”>
.wassup_widget { border: 3px solid #777; }
</style>

This bug is known, see: https://www.wpwp.org/forums/topic.php?id=112
To fix, see: https://trac.wpwp.org/ticket/53

This is a normal fluctuation in your stats. The stats are for a 24 hour period. That means that at 2:00pm your stats are from 1:59pm yesterday – 2:00pm today. Two hours later, your stats will be from 3:59pm yesterday – 4:00pm today. Counts will drop off or increase depending on the number of hits that occurred during the 2-hour period that is time shifted off the stats.

This problem occurred again after I upgraded to WordPress 2.5.1. There seems to some indexing issue here. Right after upgrade, plugins admin screen show only 5 plugins. Then after about 4 hours, all plugins show up.
My wordpress install is in a separate directory from the blog, in case this is relevant.

escapeboy,
There is a patch for wp-login.php to fix the cookie error in WP2.3. The problem seems to occur when your wordpress install is in a subdirectory. This is discussed in the support thread 135598.

Thx Ryan for the wp-login.php patch. Why hasn’t this patch already been applied to the download version of WP2.3? I downloaded and installed WP2.3 on Friday 9/28 and ended up not being able to log into my blog because of this cookie error that was reported over 5 days ago.

I encountered this same bug in WP 2.2.1 on my site as well. Instead of using bloginfo(‘wpurl’) to navigate to the next page, the WP admin “manage posts”->”previous entries” link appends the navigation to the ‘siteurl’ instead, which is a bad link for those of us using permalinks.

Until they fix this bug, all we can do is enter the correct url manually in the address bar to navigate pages in the manage posts/pages admin screen. It’s a pain, but probably a lot less headache than fiddling with wordpress’ admin php code.

I had a similar experience on godaddy.com, myself.

As you already know, the problem with the 404 page on godaddy.com is not an htaccess problem but a problem with godaddy.com hosting. By trail and error, I discovered that Godaddy.com linux servers direct all server-level 404 errors to the page, “missing.html”, in the root directory and completely ignores the “errorDocument 404 /index.php?error=404” command in .htaccess.

Godaddy’s support is so crappy, that the techs there don’t even know this. When I called, I was told that htaccess was only on their windows servers!

You need to customize “missing.html” to include a redirect to wordpress to have 404.php handle your 404 errors. You can even put php code in “missing.html” and it will run.

However, IE’s hijacking of my 404 traffic continues to be a problem. Even with “404.php” and “missing.html” bloated to be over 10k in size, IE still displays its own error page instead of mine most of the time.