Wordpress - How to eliminate weird 404 errors in wp-admin?

i was having problems all day with what seemed to be 404 misfirings.

anyway, i just finished chatting with a dreamhost tech support person who told me that a user account i have with them was hitting process memory resource limits (all processes) and that was what was causing strange, seemingly htaccess-related problems. i was getting intermittent 404 errors from an htaccess file that should not have been called at all! it was dreamhost with a haunted house server.

apparently, the process killing robot that dreamhost uses will kill a web process in the middle and then for some reason, the (now zombie) apache actually tries to finish its job (doing its best to exit cleanly out of the unglamorous end to a subrequest is my best guess). it throws a 500 error into the main http log, but after doing so, it actually fires off the rewrite condition and rule that should never have been fired (using the standard file -f and directory -d htaccess file above) - and it doesn't write a new log entry! a new (invisible man) request then triggers the index file in the last line of the htaccess file

beware the resource limits in dreamhost basic accounts! if you go over their limits, and you have htacess with mod_rewrite lines you will see strange things that are only fit for halloween night - invisible men, haunted 404s! undead processes! zombie apache! htaccess moving on its own! yikes!

hope this helps you avoid some hours of pain.

The only way to debug this is to disable one plugin at a time, each time trying to reproduce the problem before you disable another plugin. Start with the plugins that have anything to do with the administration of WP, then move down to regular theme plugins, widgets and such.

Inspect the "Not Found" page that you are served better (browse with Opera and open the Info panel which will show you the headers, alternatively browse with Firefox and have Firebug with the "Net" panel enabled) and do a search through all of your plugins to see if they might be serving it directly. If not, take a look at the log of the web server to find out what exact resource it's unable to serve; a plugin might be doing some fancy redirecting or rewriting so it's not necessarily the URL you see in your browser that's causing the 404.

This is just a rough idea: If you get a "real" 404 error (with headers set), then you could search through your plugins and look for the PHP header() function and the 404 number. This could drill down the number of plugins from 70 to just some. Then you only need to check for those.

This can be easily done with a IDE like Eclipse PDT that offers search for a specific PHP function call.

Next to that but with no guarantee that it sucessfully works, is to write a plugin that hooks into header setting and then giving you trace which code is actually setting a potential 404 (backtrace). This would only work if the plugin is using the WordPress API function. The first method to look for the PHP function will work regardless of WP API.