Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I run a WordPress site with about 70 active plugins.

Every so often, I'll get a random error page ("Not Found", though I haven't checked the headers to see if it's a 404) on a /wp-admin/ page that pops up out of nowhere.

Simply trying again resolves the error, however it's quite inconvenient if the error happens during a plugin upgrade (because the auto-reactivation fails). I think this same issue is responsible for certain modules on my Dashboard failing to load sometimes.

Given the list of plugins I have installed, does anyone know of issues with or between any of them that might cause this problem?

Edit:

Hosting info: DreamHost; I think the server's running a custom Debian build with Apache httpd

share|improve this question
1  
Not to be a PITA but this is really a support issue and not something we'd to cover here; I'm going to vote to close. Ask over at http://wordpress.org/support instead. If you do some testing and narrow your question to be applicable to more than just your situation it might make an acceptable question here. Again, sorry to be this way but we WordPress Answers should be applicable to all users and tons of support requests will kill that. –  MikeSchinkel Aug 18 '10 at 5:15
    
I concur so I'm going to vote to close too. –  Ben Everard Aug 18 '10 at 9:57
1  
Agreed. Voting to close as too localized. –  John P Bloch Aug 18 '10 at 14:16
    
I vote not to close. Many people new to WP may encounter 404 errors in WP-Admin, and ultimately it comes down to a bug in a plugin or theme, or their effect perhaps on a rewrite rule (either stored in the database in wp-options or in the .htaccess file). What we should be doing, instead, is providing general troubleshooting steps one can take to identify the problem area much faster. –  Volomike Aug 18 '10 at 20:21
    
Well, even this is tending to be a support question, it has enough info to at least suggest some ways to solve the issue quickly. –  hakre Aug 20 '10 at 10:11

5 Answers 5

up vote 3 down vote accepted

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.

share|improve this answer
    
I definitely have a lot of mod_rewrite stuff in my .htaccess files. Sounds like this is what's happening to me. I knew I hit memory limits with my backup jobs, but not for "real" requests. Thanks for sharing your experience; hopefully your answer will save a lot of people time. –  dgw Oct 23 '10 at 20:56
    
It's not just Dreamhost. I moved from Dreamhost to a private server elsewhere, and I still have this problem all the time. –  supertrue Sep 23 '12 at 22:09

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.

share|improve this answer
    
At 70 plugins, it would be really neat if one could find a way to do that super fast without having to manually deactivate and test each one, such as with a plugin tester file. –  Volomike Aug 18 '10 at 20:23
    
I see you've edited your original answer with a great tip to find the answer faster. –  Volomike Aug 18 '10 at 20:45
    
Thanks, asbjornu. I'll look into doing this after I get back from vacation with my family. –  dgw Aug 19 '10 at 15:45
    
I looked through server logs and couldn't find anything more specific than "Premature end of script header". Guess it couldn't be that easy... –  dgw Sep 1 '10 at 20:34

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.

share|improve this answer
    
This sounds promising. Something else to look into after my vacation. :) –  dgw Aug 21 '10 at 4:16
    
I managed to do some looking while still out of town, and have only found that my backup plugin seems to call for outputting a 404. Firebug shows that it's really a 404, though. Some progress... However I'm now having trouble triggering the problem, so I guess I'll take a break. I hate intermittent bugs! –  dgw Sep 1 '10 at 20:33

More information needed:

1) Why so many plugins?

2) What OS is your hosting provider running?

3) What webserver?

4) Do you have access to the httpd server logs, particularly the error logs?

5) What do the error logs say in the timeframe[s] surrounding these issues?

(Now, truth be told, if we're generalizing for "average J6P running WordPress might have this exact question, we could start by directing said J6P to answer at least the above 5 questions...)

share|improve this answer
    
I have all those plugins because I use the functions they serve; why else? The error logs don't say much at all. I'm on DreamHost, so I think the server's running a custom Debian build with Apache httpd. –  dgw Sep 1 '10 at 20:37
    
Now that you mention it, I, too, see those random errors on my DH sites as well. It particularly occurs when I'm trying to do a Network upgrade in my MS installs and run the importer. Strange. –  ZaMoose Sep 3 '10 at 20:44

I can only relate my own experience, and so far, I have not found a "definite" rule to fix all issues at one stroke.

The major problem with DreamHost's setup is that, in the eternal fight to keep memory consumption at a minimum, it means getting rid of as many features as possible — namely, all that will reduce bandwidth (good for the visitors!) or CPU (good for the server, but DreamHost doesn't control CPU consumption as aggressively as they control RAM). For instance, this means getting rid of gzip'ed HTML + CSS (which will consume CPU + RAM) or any of the several Minify plugins (which will consume RAM as well). The more sophisticated the cache (I'm fond of using W3 Total Cache, or at least WP Super Cache), the more RAM will be consumed as well.

Similarly, many plugins which limit the number of MySQL queries to improve performance will instead consume RAM. So finding a trade-off where you can still keep your site replying with good performance while avoiding to consume precious RAM is a hard task!

So far, my best results on busy sites is to uncheck Page Speed Optimization and Extra Web Security which will apparently consume a lot of RAM, and rely instead on a combination with W3 Total Cache and Cloudflare (free reverse proxy service). Cloudflare will effectively do the same thing as the "Extra Web Security" module, but since it runs outside DreamHost, it's fine. W3 Total Cache consumes a lot of memory but once the pages are statically stored locally, Cloudflare will very efficiently cache them — so you might get 404/500 while editing posts, at least your visitors will not experience them (Cloudflare also can serve static pages even if DreamHost gives a 404 or a 500).

Also, thanks to this article, I have found out that FastCGI uses more RAM than 'normal' CGI. And since PHP 5.3 is better at managing RAM (more aggressive garbage collection, less memory leaks), I've experimentally switched to PHP 5.3 CGI (not FastCGI) without Page Speed Optimization nor Extra Web Security, relying on W3 Total Cache + Cloudflare to accelerate the site. Now the backoffice is slower (more CPU consumption!) but at least I don't see 404/500 (so far!).

I'm still unhappy with the combination, so I'll certainly continue to tweak DreamHost's settings hoping to reduce RAM consuption even more and still get adequate performance. Like @dgw said, I also use a lot of plugins — because I require their functionality. Not everybody hosting WP with DreamHost has simple, blogging needs; the more complex the site, the more functionality it will require... and that's the beauty of WordPress, you just need to use the plugins you really need, and keep the core WP install simple if you're happy with few needs. Plugins, however, aren't necessarily "bad" or that heavy on the site; but it's true that some may consume a lot of RAM...

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.