Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
Fix a WordPress memory crash by identifying the exact fatal error, checking the server’s effective PHP memory_limit, then correcting the code or workload that consumes it. Set WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT only as appropriate headroom; those constants cannot override a host-locked PHP limit. A reliable repair therefore combines evidence from logs, a controlled limit change, and isolation of the plugin, theme, import, media job, or other task that exhausted memory.
Recognize an out-of-memory crash before changing anything
Save the failure message and the time it occurred. The most useful clues are:
Allowed memory size exhausted, usually followed by the number of bytes PHP tried to allocate and the file where the allocation failed.- A WordPress message saying, “There has been a critical error on this website.”
- A blank white page, an HTTP 500 response, or a dashboard that stops loading midway.
- A recovery email identifying a plugin, theme, or PHP file involved in a fatal error.
The file named in the error is a lead, not automatically the root cause. A plugin may be the caller while another extension, an incompatible PHP version, a damaged WordPress file, or an unusually large operation created the conditions for failure.
Collect evidence from all available logs
- Read the WordPress recovery email, if one was sent. Record the extension name, file path, function, and timestamp.
- Ask the host for the PHP and web-server error-log entries covering that timestamp. Shared hosting often hides these logs from the account user.
- Enable controlled WordPress debugging only long enough to reproduce the problem. In
wp-config.php, place the following before the line that includeswp-settings.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Reproduce the failing request, then inspect wp-content/debug.log. Keeping display disabled prevents visitors from seeing paths, queries, or other diagnostic details. Turn debugging back off after collecting the evidence unless you are working on a protected staging site.
#1 Best Overall
Understand which memory limit is actually stopping PHP
WordPress has requested memory values, but PHP’s active memory_limit is the effective ceiling. WordPress can ask PHP for more at runtime with ini_set() when the server permits that change. A locked or lower PHP setting wins.
| Layer | What it controls | Typical scope | Who can change it |
|---|---|---|---|
PHP memory_limit |
Maximum memory available to one PHP process | Whole site, virtual host, or server, depending on configuration | Server administrator, host panel, or a permitted per-site override |
WP_MEMORY_LIMIT |
WordPress request for front-end operations | Visitors’ page loads and other non-administration requests | Site administrator editing wp-config.php, if PHP allows the request |
WP_MAX_MEMORY_LIMIT |
WordPress request for administration and back-end operations | Dashboard actions, updates, media handling, and similar admin work | Site administrator editing wp-config.php, subject to the PHP cap |
| CLI PHP configuration | Memory available to command-line PHP processes | WP-CLI commands, imports, exports, and scripts | Shell user, host, or the command’s temporary -d override |
Web requests and command-line requests can load different php.ini files. A value that appears correct in the dashboard may therefore be unrelated to a failing WP-CLI import, and vice versa.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Use sensible starting values, not a universal promise
The WordPress Hosting Handbook’s current guidance gives these starting tiers:
| Workload | Starting memory guidance | Qualification |
|---|---|---|
| Vanilla WordPress installation | 128M minimum | Starting guidance, not a guarantee that every theme or request will fit |
| Typical recommended default | 256M | Current Handbook recommendation for a general site; actual consumption varies |
| WooCommerce, page builders, multilingual plugins, or import/export jobs | 512M or more | Starting headroom for heavier workloads, not proof that inefficient code is fixed |
Choose the smallest value that supports the documented workload with room for normal traffic. A very high limit can let a runaway request consume more server RAM and make a crash affect other sites on the same machine.
Apply the WordPress constants safely
Back up wp-config.php before editing it and preserve its existing formatting. Add the constants once, above the /* That's all, stop editing! */ comment and, specifically, before the file loads wp-settings.php:
define( 'WP_MEMORY_LIMIT', '128M' );
define( 'WP_MAX_MEMORY_LIMIT', '256M' );For a heavier, evidence-based workload, the second value might be 512M if the host’s PHP limit and available RAM support it. Do not add a second definition lower in the file; duplicate constants can create confusion and do not raise a host-enforced ceiling.
Confirm whether the change took effect
- Repeat the same front-end request that failed and check the PHP log for a changed allocation limit.
- Repeat the same dashboard action for an administration failure.
- Compare the active PHP configuration, not merely the text in
wp-config.php. If the effectivememory_limitremains lower, WordPress’s request was denied or capped.
Do not assume that saving the file changed a running PHP worker. Depending on the host’s PHP handler, a service restart or PHP-FPM reload may be required; only the host may have authority to perform it.
When wp-config.php changes do nothing
A no-change result usually means the active PHP configuration is lower, immutable, or different from the one you edited. Ask the provider to confirm the effective memory_limit for the affected site and PHP version, and request the relevant server-log entries if you cannot access them.
Check the configuration layers
- Inspect the PHP configuration used by the web server, not just a command-line PHP binary.
- Check for a per-site override, pool configuration, control-panel setting, or additional
.inifile that loads after the main file. - Confirm that the site did not switch PHP versions or handlers immediately before the crash.
- On shared hosting, ask whether runtime
ini_set()changes are disabled. A host-enforced cap cannot be bypassed with a WordPress constant.
If the provider cannot raise the limit, reduce the operation’s scope, disable the offending extension, or move the workload to an environment where you control PHP settings. Server-level help is especially important when the entire account becomes unavailable rather than one URL failing.
Use WP-CLI with the PHP configuration it really loads
WP-CLI may invoke a different PHP binary and a different set of configuration files from the web request. First locate the CLI value:
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Rank #3
php -i | grep memory_limitOn systems without grep, run php -i and search its output for memory_limit. Also review the reported “Loaded Configuration File” and additional .ini directory so you know which files are active.
For a single controlled command, pass a temporary limit to PHP:
php -d memory_limit=512M $(command -v wp) plugin listReplace plugin list with the operation you need, such as an import or export command. This affects that invocation only; it does not change browser requests or the server’s permanent policy. If the command still fails, capture its exact error and identify whether the task itself is processing too much data at once.
When a permanent CLI change is required, the host or system administrator must alter the CLI php.ini or its additional configuration files. Restart or reload the relevant PHP service when the configuration method requires it, then rerun php -i to verify the active value.
Treat a higher limit as a diagnostic step, not the cure
WordPress’s common-errors guidance describes an allowed-memory error as meaning that the installation does not have enough memory to achieve the requested operation. Raising the limit can supply temporary headroom, but it can also postpone the same failure until a larger request arrives.
Isolate the expensive code
- Record the file path and line number from the fatal error or log.
- Check whether the failure occurs on every page or only one URL, dashboard screen, import, image operation, or scheduled task.
- On a staging copy or during a maintenance window, deactivate the named plugin and reproduce the request. If the crash stops, update, reconfigure, replace, or remove that plugin rather than leaving the limit permanently elevated.
- If no plugin is implicated, switch temporarily to a standard theme on staging. A theme conflict or an incompatible PHP feature can consume memory before the page is rendered.
- Test with the heavy operation divided into smaller batches: fewer products per import, fewer images per media job, or a narrower date range for an export.
- Restore one change at a time so you know which component caused the failure.
WordPress identifies plugin and theme conflicts, incompatible PHP, memory limits, and corrupted files as possible causes. A limit increase does not repair corrupted files or make incompatible code safe.
Recover dashboard access after a fatal plugin or theme error
Recovery Mode is designed for a regular page load that triggers a fatal PHP error. WordPress automatically activates it when it detects that kind of fatal error; it does not cover CRON or other background tasks.
- Open the recovery link sent to the site administrator’s email.
- Sign in through the temporary recovery session.
- Use the error details to deactivate the suspected plugin or switch away from the suspected theme.
- Load the affected page in a normal, non-recovery session to confirm that the site is stable.
- Update or replace the component after checking PHP compatibility, then retest with debugging controlled.
Because Recovery Mode is temporary, it is not a solution for a cron job, queue worker, scheduled import, or other process that keeps exhausting memory after normal pages recover. Those failures require server logs, WP-CLI or task-specific logs, and a reduction or repair of the background workload.
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallMatch the remedy to the workload
| Failure pattern | Likely first action | What the action proves |
|---|---|---|
| Every front-end page fails after a change | Use recovery email/logs, then disable the newest plugin or revert the theme on staging | Whether a regular request is invoking incompatible or excessive code |
| Only dashboard media editing or updates fail | Set an appropriate WP_MAX_MEMORY_LIMIT, verify PHP’s cap, and test the specific asset |
Whether admin-only work needs more headroom or a particular file is malformed |
| WooCommerce or page-builder operation fails | Use the heavier starting tier, then profile the plugin operation and reduce batch size | Whether the workload exceeds capacity or contains an inefficient query/task |
| Large import or export fails | Run smaller batches; check WP-CLI’s separate limit and use a one-command override | Whether the CLI process, rather than browser PHP, is the constrained layer |
| Only cron or background processing fails | Inspect scheduled-task logs and CLI/server PHP settings; do not rely on Recovery Mode | Whether a worker has a different configuration or an unbounded queue |
| All sites on a shared account slow or crash | Contact the host with timestamps and request server-level memory and error logs | Whether account-level resource limits or neighboring processes are involved |
Common reasons the “fix” fails
The constant was placed too late
If the definition appears after WordPress has loaded its settings, it may not affect the request. Place both constants before the wp-settings.php include and remove duplicate definitions.
The host cap is lower
WordPress cannot force a locked php.ini value higher. Verify the active web PHP configuration and ask the host for a change instead of repeatedly editing the same file.
Best Value
Only the browser limit was raised
WP-CLI, cron, and worker processes can load different settings. Check each execution context independently.
The wrong component was blamed
The file in a fatal error is where PHP ran out of room, not necessarily where excessive memory was first allocated. Reproduce with the suspected plugin, theme, PHP version, and task narrowed one at a time.
Free tools Windows power users keep installed
One-click scans. No signup required.
Debug output was left public
Leaving WP_DEBUG_DISPLAY enabled can expose server paths and implementation details. Keep logs protected and disable visible debugging after diagnosis.
Prevent the next memory crash
- Keep WordPress, plugins, themes, and PHP on versions that are mutually compatible.
- Remove inactive extensions that still load code or schedule jobs.
- Schedule large imports, exports, image processing, and updates during low-traffic periods, and split them into batches when the tool supports it.
- Monitor both front-end and administration requests; they can legitimately need different limits.
- Document the host’s effective web and CLI limits so a future PHP-version change does not silently revert them.
- Keep a staging copy for testing plugin, theme, and PHP changes before production.
- Retain timestamps and log excerpts when contacting support; they let the provider locate the corresponding server event.
A practical decision sequence
- Capture: save the exact fatal message, URL or command, timestamp, and named file.
- Classify: decide whether the failure is front end, administration, CLI, cron, or account-wide.
- Measure: check the effective PHP
memory_limitfor that execution context. - Apply limited headroom: set the appropriate WordPress constant or one-command CLI override only if the host and available RAM support it.
- Reproduce: run the same request or task again and compare the log.
- Isolate: deactivate or replace the implicated plugin/theme, correct PHP incompatibility or corrupted files, or split the workload.
- Verify: test normal visitors, the dashboard, and scheduled/CLI tasks separately before declaring the incident resolved.
This sequence distinguishes a capacity problem from a code defect. It also prevents a temporary memory increase from masking a failure that will return as the site grows.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
