How to Increase WordPress Memory Limit
%203.png&w=256&q=75){kind=small}
The Fatal Error
"Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes)" is the exact line you will see in the debug log or right on a white screen, and it means PHP hit a hard ceiling mid-request and killed the process rather than let it keep allocating memory. The number changes depending on the limit in effect — 268435456 bytes is 256MB, 134217728 is 128MB — but the shape of the problem is always the same: something WordPress was doing (rendering a page, running a plugin routine, processing an import) asked for more RAM than PHP was configured to hand out, and PHP refused rather than let the server run out of memory system-wide.
On a generic PHP application, the fix is just raising memory_limit in php.ini and moving on. WordPress is more specific than that: it layers two of its own memory constants on top of whatever PHP-FPM allows, and neither one can push past the PHP-FPM pool ceiling underneath it. Get the layering wrong and you either waste time editing the wrong file or raise a number that silently has no effect. This is that layering, WordPress-specific, not the general PHP tuning story.
WordPress's Two Memory Constants
WordPress core defines two separate memory ceilings, and confusing them is the most common reason a fix does not stick. WP_MEMORY_LIMIT governs ordinary front-end page loads and general wp-admin screens — the default WordPress falls back to is 40MB for the front end and 256MB for admin if you never set it, though most real hosting environments already run PHP-FPM pools well above that. WP_MAX_MEMORY_LIMIT is a second, higher ceiling reserved specifically for admin-only heavy-lifting tasks — a plugin or theme can call wp_raise_memory_limit() to bump the effective limit up to this second constant for operations like large media imports, XML/CSV importers, PDF or thumbnail regeneration, and backup plugins building an archive in memory.
The split exists on purpose. WordPress does not want every ordinary visitor request reserving admin-import-sized memory just in case, so it keeps the everyday ceiling modest and only lets specific admin operations reach for the bigger number. If your fatal error happens while browsing the site normally, WP_MEMORY_LIMIT is the one to raise. If it happens during a WooCommerce product import, a Migrate/Duplicator-style export, or a media library bulk regenerate, WP_MAX_MEMORY_LIMIT is the relevant constant, and it is allowed to be set higher than WP_MEMORY_LIMIT since it only applies to those bounded, admin-triggered operations.
Editing wp-config.php Correctly
Both constants must be defined above the /* That's all, stop editing! Happy publishing. */ line in wp-config.php, or WordPress never picks them up — anything added below that marker sits in the block that hands control off to wp-settings.php, past the point where these defines still get evaluated by the bootstrap sequence that reads them.
Set WP_MEMORY_LIMIT to whatever covers normal page loads on your stack — 256M is a safe, common value for a theme with a handful of plugins. Set WP_MAX_MEMORY_LIMIT higher, since it only kicks in for the specific admin operations that call for it, and a too-low value here is exactly what produces "allowed memory size exhausted" the moment someone runs a large import. Neither value is a request for more server RAM — it is a ceiling PHP enforces against a single request's own allocations, so raising it costs nothing unless a process actually tries to use that much.
The PHP-FPM Ceiling Underneath
WP_MEMORY_LIMIT cannot exceed the memory_limit set in the site's underlying PHP-FPM pool — WordPress's own constant is a request made to PHP, not an override of PHP itself, and PHP always enforces whichever number is lower. On a CloudStick server, each website runs its own PHP-FPM pool with its own memory_limit directive, defaulting to 256M unless changed. Define WP_MEMORY_LIMIT at 512M in wp-config.php while the pool is still capped at 256M, and WordPress will keep hitting the same fatal error at 256M — the wp-config.php change did nothing, because the pool below it never budged.
"Raising WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT only changes what WordPress asks PHP for — the PHP-FPM pool's own memory_limit is the real ceiling, and WordPress can never negotiate past it."
So the wp-config.php edit and the pool edit are two separate steps, and both need to move together. CloudStick's EasyPHP tool lets you view and adjust the per-site PHP-FPM memory_limit directly from the dashboard, without opening or hand-editing the pool file — pick the site, raise the number, and the pool reloads with the new ceiling applied, so the wp-config.php constants you just set actually have room to matter.
Find the Real Culprit Before You Raise Anything Further
A single plugin is usually the actual trigger, not a genuine config gap — a stock WordPress install with a handful of well-behaved plugins rarely needs more than 256M for normal operation. If you find yourself repeatedly raising the limit and still hitting the same fatal error, check what was running when it happened: an XML/CSV import tool, a PDF or invoice generator, a page builder rendering a very large layout, or a backup plugin zipping the whole site in-process are the classic offenders, because they load large data sets or build files entirely in memory instead of streaming them.
As a next step: set WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT above the "stop editing" line as shown, confirm the PHP-FPM pool's memory_limit is raised to match through EasyPHP or the pool config, and if the error keeps recurring during one specific action, look at disabling or replacing the plugin behind that action rather than continuing to chase the number upward. Memory limits exist to catch runaway processes — treat a repeat fatal error as a signal to find the runaway process, not just a bigger number to type in.
