Fatal Error: Allowed Memory Size Exhausted — The Real Fix

You refresh the page and instead of your site you get a wall of white text: Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes). The number changes, the message doesn't. It means PHP hit its memory ceiling and gave up mid-request. Here's what's actually happening and how to fix it without just cranking the limit blindly.

Symptom: What You're Actually Seeing

The error usually shows up in one of these places:

• A blank white screen on the front end, sometimes with the fatal error text printed raw if display_errors is on
• The WordPress admin loads but a specific screen (Plugins, Updates, an import tool) dies partway through
• A line in error_log or cPanel's Errors tool reading PHP Fatal error: Allowed memory size of X bytes exhausted in /home/user/public_html/wp-includes/... on line Y

Note the two numbers in the message. The first (say, 134217728 bytes = 128 MB) is your current memory_limit. The second is how much PHP tried to grab for the operation that failed. That second number tells you almost nothing useful on its own — it's just the last straw, not the total usage.

Cause: Why PHP Runs Out

Every PHP process has a hard ceiling set by the memory_limit directive. When a script's total memory usage crosses that ceiling, PHP kills the request immediately rather than let it keep grabbing RAM. A few things push usage up:

• Plugin/theme bloat. Page builders (Elementor, Divi), WooCommerce with a large catalog, and SEO plugins that scan every post on save are the usual suspects in WordPress.
• A low default. Shared hosting commonly ships with 64 MB or 128 MB as the default memory_limit, which was fine a decade ago and isn't now.
• Bulk operations. Importing a large XML file, running a plugin/theme mass-update, regenerating thumbnails for thousands of images, or a WP-CLI command with no --memory_limit override.
• A memory leak in one plugin. If usage climbs on every request regardless of what you're doing, one plugin is likely holding onto objects it shouldn't. Deactivating plugins one by one narrows this down fast.

Two configs matter for WordPress specifically: PHP's own memory_limit, and WordPress's internal WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT constants in wp-config.php. WordPress caps itself at whichever is lower — raising PHP's limit alone won't help if WP_MEMORY_LIMIT is still set to 40M.

Fix: Raise the Limit the Right Way

Don't just set it to 1024M and move on — start reasonable (256M is a good baseline for a modern WordPress site) and only go higher if you still hit the wall.

1. cPanel — MultiPHP INI Editor (best option, no code)

1. Log into cPanel, open MultiPHP INI Editor
2. Select your domain from the dropdown, switch to Editor Mode
3. Find memory_limit and set it to 256M (or higher)
4. Click Apply

This changes the actual PHP-FPM/CGI handler config for that domain, so it's the most reliable fix on shared and reseller hosting. If you don't see the option, your account may be on suPHP or an older handler — ask support to confirm which PHP handler you're on.

2. wp-config.php (WordPress-specific ceiling)

Add these lines above the /* That's all, stop editing! */ line:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

WP_MEMORY_LIMIT applies to normal front-end/admin requests. WP_MAX_MEMORY_LIMIT applies to admin-only heavy tasks (like the media library or plugin updates). Neither of these can exceed what PHP itself allows — they're a ceiling within a ceiling.

3. .htaccess (Apache with mod_php only)

php_value memory_limit 256M

This only works if PHP is running as an Apache module. On PHP-FPM (which most modern cPanel accounts use), this line does nothing and can actually throw a 500 error if PHP is misconfigured to reject it. Check your PHP handler in MultiPHP Manager before using this method.

4. php.ini in your home directory

If you have a custom php.ini in your account's root or the site's document root:

memory_limit = 256M

Save it, then check MultiPHP INI Editor or run php -i | grep memory_limit over SSH to confirm it actually took effect — a misplaced php.ini is a common reason people think a fix "isn't working."

Confirm the New Limit Is Live

Create a temporary file (delete it right after) with:

<?php phpinfo(); ?>

Load it in a browser and search the page for memory_limit — you'll see the Local Value and Master Value side by side. If Local still shows the old number, the change didn't apply at the level you edited (wrong domain selected, wrong PHP version, or a handler mismatch).

If Raising the Limit Doesn't Fix It

Sometimes the real problem is a runaway plugin, not a genuinely heavy site. If bumping to 512M just delays the same error:

• Enable WP_DEBUG_LOG and watch wp-content/debug.log for which file/line is allocating memory right before the crash
• Deactivate all plugins, then reactivate one at a time, reproducing the action that triggers the error after each one
• Check for infinite loops in custom code — a recursive function or an unbounded WP_Query loop will eat any amount of memory you give it
• For large imports, run them via WP-CLI instead of the browser: wp import file.xml --authors=create — CLI requests get their own memory allowance separate from web requests

Prevention

If you're on Getwebup hosting and don't see MultiPHP INI Editor in cPanel, or the limit keeps reverting after you save it, open a ticket — that usually means the account is on a locked PHP handler and needs a quick change on our end.