Skip to content
Website Rescue Rescue

PHP Errors

PHP Allowed Memory Size Exhausted

Intermediate Risk: medium

Last reviewed

Hosting access often needed Database access usually not needed

Direct answer

Allowed memory size exhausted means a PHP request hit the memory_limit ceiling—raise the host PHP memory_limit (and WP_MEMORY_LIMIT / WP_MAX_MEMORY_LIMIT when appropriate), then find the plugin, builder, or import that is consuming the RAM instead of endlessly increasing the number.

WordPress sites often surface this as a fatal in the log, a critical-error screen, a white screen, or an HTTP 500. Page builders, WooCommerce, and bulky plugins are frequent offenders. This guide explains how WordPress memory constants relate to php.ini, how to raise limits safely, and how to tell memory fatals apart from other PHP crashes.

Intermediate

What the error means

PHP allocates a per-request memory budget controlled by the memory_limit directive in php.ini (or the host MultiPHP INI). When a script tries to allocate past that ceiling, PHP throws a fatal: “Allowed memory size of X bytes exhausted.” WordPress can request a higher limit via WP_MEMORY_LIMIT (front end) and WP_MAX_MEMORY_LIMIT (admin) in wp-config.php, but those defines cannot exceed what the server allows—if php.ini is 128M, defining 512M in wp-config still stops at 128M. This is a resource fatal, not the same as an undefined function, parse error, or type error: those fail for logic reasons even when plenty of RAM remains.

Common symptoms

  • Error log or debug.log shows “Allowed memory size of … bytes exhausted” with a file and line
  • Critical error or white screen on heavy pages (builders, cart, reports) while light pages work
  • wp-admin fails during plugin/theme updates, media imports, or WooCommerce reports
  • Elementor, Divi, or similar editors crash while the public site mostly loads
  • HTTP 500 or host error page timed to the same memory fatal in logs
  • Raising memory temporarily restores the page; lowering it reproduces the crash
  • Symptoms worsen after adding a plugin, enlarging a page, or importing products/images

Most likely causes

  1. 01 Host PHP memory_limit too low for the current plugin and builder stack
  2. 02 WP_MEMORY_LIMIT unset or lower than what admin-heavy workflows need
  3. 03 Page builder, WooCommerce, or analytics plugins loading oversized datasets in one request
  4. 04 Runaway loop, unbounded query, or memory leak in a custom plugin or snippet
  5. 05 Image or XML/CSV import processing huge files in a single PHP worker
  6. 06 Object cache or opcode issues amplifying memory use after a partial update
  7. 07 MultiPHP INI reset after a PHP version change that dropped memory_limit

What changed before the problem started

  • New or updated page builder, WooCommerce extension, or backup/migration plugin
  • PHP version or MultiPHP INI change that lowered memory_limit
  • Large product, media, or page import
  • Theme customization or code snippet that queries too much data at once
  • Traffic or cron spike hitting a heavy admin-ajax or REST endpoint
  • Host plan limits enforced after an upgrade/downgrade

Troubleshooting steps

  1. 01

    Confirm the fatal is memory exhaustion

    Open the host error log or wp-content/debug.log and find “Allowed memory size” / “exhausted.” Note the file path—it often names the plugin or theme. If the fatal is a different message (undefined function, parse error), do not treat it as a memory problem.

  2. 02

    Raise the host PHP memory_limit first

    In cPanel MultiPHP INI, Plesk, or the host’s PHP settings, set memory_limit to at least 256M for typical WordPress sites (512M when builders and WooCommerce run together, if the plan allows). Save, wait a minute, and retest the failing URL.

  3. 03

    Align WordPress memory constants in wp-config.php

    Add or update `define('WP_MEMORY_LIMIT', '256M');` and, for stubborn admin tasks, `define('WP_MAX_MEMORY_LIMIT', '512M');` above the “That’s all, stop editing!” line. Remember these cannot exceed the host memory_limit.

  4. 04

    Isolate the heavy plugin or builder

    If a modest limit still exhausts, rename the plugins folder or disable likely offenders (builder, backup, related-products, statistical plugins) via FTP. Restore service with a sane limit, then re-enable one at a time while watching the log.

  5. 05

    Retest the specific heavy workflow

    Reproduce the same action: open the builder, run the import, load the report. Confirm the memory fatal is gone and that lighter pages still behave. Purge page cache so you are not viewing a cached success or failure.

  6. 06

    Enable WP_DEBUG_LOG without displaying errors

    Set WP_DEBUG and WP_DEBUG_LOG true with WP_DEBUG_DISPLAY false while reproducing once. Capture the stack, then turn debug display off so visitors never see paths or internals.

When to stop troubleshooting

Escalate if the host hard-caps memory below what the stack needs, logs point to core or encoded plugins you cannot replace, exhaustion continues at 512M+, or checkout/admin stay down during business hours. Bring the exact fatal line, phpinfo memory_limit, and a list of builder/WooCommerce plugins.

Information to collect before requesting help

  • 01 Exact “Allowed memory size … exhausted” log line with file path
  • 02 Effective memory_limit from phpinfo or host PHP settings
  • 03 Current WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT values if set
  • 04 Whether failure is front end, wp-admin, builder, or CLI/cron
  • 05 Recent plugin, theme, PHP, or import changes
  • 06 WordPress, WooCommerce, and page-builder versions
  • 07 Hosting provider and plan resource limits

How a professional repairs the problem

We confirm the fatal is memory exhaustion, raise host and WordPress limits to a safe baseline, then isolate the plugin, builder view, or import that consumes RAM. We leave limits high enough for legitimate workloads and replace or reconfigure leaky components so the site is not one spike away from another fatal.

Frequently asked questions

Is this the same as a generic PHP fatal error? +
It is a specific kind of fatal. Undefined functions and parse errors fail for code reasons. Memory exhaustion means the request ran out of allowed RAM. The log wording tells you which playbook to use.
Why did raising WP_MEMORY_LIMIT do nothing? +
WordPress cannot exceed the server memory_limit. If php.ini is lower, update the host PHP setting or MultiPHP INI first, then align the wp-config constants.
How much memory does WordPress need? +
Simple sites may run at 128M; builder-heavy and WooCommerce sites often need 256M–512M. If one plugin needs far more, fix or replace that plugin rather than treating megabytes as unlimited.
Can Elementor or WooCommerce alone trigger this? +
Yes. Editor loads, large product catalogs, and report screens are common triggers. Raise limits reasonably, update the extension, and reduce overlapping heavy plugins.
Will more memory hide a bad plugin forever? +
Temporarily. A leaky or unbounded process will eventually exhaust any ceiling and hurt neighbors on shared hosts. Use the higher limit to recover, then repair the culprit.
Does a white screen always mean memory exhaustion? +
No. White screens and critical errors have many causes. Only trust the “Allowed memory size exhausted” line in the log before focusing on memory_limit.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.