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
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.
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…
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.
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…)