PHP Fatal Error: Allowed Memory Size Exhausted

What’s actually happening

A page dies partway through and you get a white screen, an HTTP 500, or a half-rendered layout that cuts off. The full error sits in your PHP error_log (or wp-content/debug.log if WP_DEBUG_LOG is on), naming the exact file and line where allocation failed. The byte number in the message is your limit: 134217728 is 128M. The line it points to is often just where memory ran out, not the actual culprit.

Common causes

• A plugin or theme loading thousands of rows or full-size images into memory at once (page builders, migration, backup, and WooCommerce report plugins are repeat offenders).
• memory_limit set too low for the workload, commonly the host default of 64M or 128M.
• An import/export or batch job processing a large dataset in a single request instead of in chunks.
• Code building giant arrays or strings in a loop, or a recursive call with no proper exit.
• An image library (GD/Imagick) decompressing a large photo, where a 4000x3000 JPEG can need 50M+ uncompressed.

How to fix it

1. Read the file and line in the log firstOpen the PHP error_log and find the file:line in the message. If it's always the same plugin, deactivate that plugin and confirm the error stops before touching any limits. Raising memory to hide a leaking plugin just delays the crash.
2. Raise memory_limit in wp-config.phpFor WordPress, add define('WP_MEMORY_LIMIT', '256M'); above the /* That's all, stop editing */ line. For admin-side work add define('WP_MAX_MEMORY_LIMIT', '512M'); too. This only works if it's below the server's hard ceiling.
3. Set it at the PHP level if wp-config won't takeIn php.ini set memory_limit = 256M, or in .htaccess add php_value memory_limit 256M (Apache + mod_php only). On cPanel use MultiPHP INI Editor. PHP-FPM and LiteSpeed ignore .htaccess php_value lines, so use the host's PHP settings panel instead.
4. Batch the heavy operationIf it's your own import/report code, process records in chunks of 100-500 with offsets and free memory between batches (unset($var) and wp_cache_flush() in WP loops). WP_Query with 'posts_per_page' => -1 on a large site is a classic memory bomb.
5. Move to a bigger plan or container if it's legitimateIf the workload truly needs more than ~512M (large WooCommerce migrations, heavy data crunching), shared hosting caps will fight you. A VPS or container where you control memory_limit is the real fix.