Being on track to write a really simple plugin that should take care of the memory related crashes problem I began to wonder a bit about how Memory Limit is dealt with in WordPress 3.0 core code.
First of all, the reason for having a memory limit is to [help] prevent poorly written scripts for eating up all available memory on a server (from the PHP Manual). So the original idea of this setting is to set the memory limit in the servers configuration. That’s normally the job of the administrator and an application should not deal with it on it’s own. Otherwise there would be no need to have such a limit.
On the other hand, a server should be properly configured for an applications needs that is calling it it’s home. For example running WordPress with a 4 megabyte limit is not suitable and instead a very bad idea. This leads to check WordPress system requirements, but they do not name a minimum amount of memory at all. So a wordpress user is left alone to figure this out, as well as for WordPress developers because they have no mark for orientation. So far so bad but nothing surprisingly at all. Documentation is for those of who are damn stupid.
Okay, let me help you with this one: It is said, that a standard (default) blog needs 32 MB and the new multisite variant 64 MB. Those are the standard WordPress memory limits. They are defined within core code (albeit the implementation is buggy and renders those default constants useless but it’s enough for the moment to read the code as documentation replacement and just go on). Let’s say, these memory limits of 32 or 64 MB are intended. Blogs with more content, especially long posts, need more memory than that, but to gather the proper amount for a concrete install is not within the scope of this post, so I won’t go into detail here. Let’s take these values in absence of anything else.
As already written, the wordpress application is then designed to set the memory_limit directive everywhere when it seems to fit to make more memory than that/configured available. It’s used in the following places:
When it comes to these places, it looks like the magic value of 256MB has been elected to provide enough memory. I know images that are of larger size than that. And I know that standard servers do not provide that much memory for PHP. So why 256MB? Probably because Matt Mullenweg needed it for his photoblog. And since then no complaints must have been heard so to use that value in other places as well. But who knows, the original intentions nor for what this fix was for in concrete might never be revealed precisely because mostly the changes are done w/o any accompanied ticket-info (, ).
Server! Give Me The Memory! Or I Will Kill You!
The originating problem which did make me think about writing the Memory Limit Plugin was that many users reported that setting to limit to 256MB kills the request because the server prevents wordpress doing so. As written, 256MB is a very high value.
Because next to a PHP memory limit, there are other things that control and limit the amount of memory that can be consumed by PHP and processes in general. Often this is referred as soft- and hard-limits. In short: soft can be gone over but warns, hard is a show-stopper.
The popular PHP extension Suhosin for example can prevent script from doing such a thing. If that’s the case on your blog you’ll find something like this in your error log:
… ALERT – script tried to increase memory_limit to 268435456 bytes which is above the allowed value …
This is the poster scenario, because suhosin is very popular (and well, yeah, useful). If you run into this problem, please tell your system administrator that you need 256MB of memory for wordpress and both, the php and the suhosin memory_limit directive should reflect that accordingly. But be warned, you just might get a harsh answer, because 256MB for webhosting is often considered as a misconception. Maybe it helps if you say, “well, it’s WordPress” and that you have large images to process.
Next to that, a properly configured server has hard limits as well. That means, for whatever has been configured in PHP or suhosin, the system takes care of any process anyway and if the PHP process in a CGI/FCGI configuration is consuming more memory than allowed, it well get killed. Period. Normally this will return a 500 Internal Server Error then.
If you’re running PHP as an apache module, this might just bring the whole server down, at least one of it’s childs. Connection terminated. As written on top, it’s wise to have a memory limit and it’s wise that this is properly configured by the servers administrator. Otherwise you can run into problems you do not want to run into.
And even if you feel like so: Fighting against your Admin will always make you lose, it’s not a fight you can win. Okay maybe with your wallet. But then it’s your money anyway.
To configure or not to configure
So buying hardware and properly configuring a server can cure the problems to run wordpress. If this is not an option, the problem remains. On the one hand, WordPress wants more memory, but how to deal with that? How to prevent wordpress from triggering other limits on your server? That’s what my plugin should do, prevent the blog from crashing.
First of all, let’s take a look how much memory should be allowed. The best hint by your sys-admins would be the bespoken memory_limit directive. It was configured by the server’s administrator. In case that is not enough, a good software should report this to it’s user so that he can discuss with system support how much memory is possible and to configure it accordingly.
WordPress does not warn because it know that their users feel what the application wants. And anyway, the truth is, who wants warnings? Who needs them? Warnings are completely useless, they only come when you don’t need them. So it’s a wise-programming style to block all warnings as wordpress does.
Since WordPress is changing the memory limit, this prevents the usage of the setting as it was designed for. But that’s for the moment only, because ini_restore() restores a given configuration option to its original value.
So it’s as easy as restoring the default value by calling
ini_restore('memory_limit'); for the admin, for example within the admin_init hook. But for the admin, there is as well another filter that can return the maximum allowed memory: admin_memory_limit. So that filter can return the original value as well to override the 256MB magic number and set it to the server-configuration.
So now everything is in order to create a plugin, right? It’s possible to gather the original memory limit value and it’s possible to filter the setting done by wordpress. Using that filter was suggested by Andrew Nacin in the related trac ticket. Thanks to Nacin, I know knew how I could implement such a great plugin. You know it’s a joke, don’t you? That filter is only in there for one of the many places where the memory limit is set. All the other places lack of such a filter – well I think because nobody was caring for years anyway.
So to make the long story come to an end: This can not be fully fixed with a plugin and WordPress 3.0 is broken. Tja, Pech gehabt Jungs. So to say, you need to get your server properly configured, to be worry free, extend the PHP Memory Limit to 256MB.
So instead of writing a plugin in the first place, I
‘ll suggest a patch instead. Should be easy to solve with a single wordpress configuration constant.
- Memory Bump (WordPress Plugin) – Set Memory Limit to 256MB in the admin, similar as in 
- Ticket #14889: Memory Comparison Broken / WordPress Memory Limit
- Ticket #13847: WP increasing the memory above other server limit
- WP3 exceed 256 memory limit
- Memory Usage Monitoring (WordPress Plugin)
- WP System Health (WordPress Plugin)