WordPress Allowed Memory Size Exhausted in wp-admin

The Problem

A memory exhausted error in wp-admin means one PHP request used more memory than the server allowed. It may happen while opening the dashboard, editing a large page, running an import, generating a report, uploading media, updating plugins, or loading a builder screen. The browser may only show a critical error or blank admin page, but the useful clue is usually in the fatal log line: the memory limit, the attempted allocation, and the file path that was running when the request failed.

Do not treat the first fix as simply raising a number. WordPress can request different limits for public requests and admin requests, and hosting PHP configuration can still cap what WordPress is allowed to use. A higher limit may be appropriate for legitimate admin work, but repeated failures usually need a second question: which plugin, theme, query, import, backup, scan, or editor workflow is consuming so much memory?

First Checks Before You Change Anything

• Capture the exact fatal message, including the byte limit, attempted allocation, file path, line number, URL or admin action, timestamp, and user role.
• Check whether the public site still works. If only wp-admin fails, preserve public traffic while you investigate the admin request path.
• Compare PHP `memory_limit`, `WP_MEMORY_LIMIT`, and `WP_MAX_MEMORY_LIMIT` instead of assuming one setting controls every request.
• Identify the heavy action that triggers the error: import, export, media processing, backup, security scan, WooCommerce report, builder edit, plugin update, or dashboard widget load.
• Use staging, SFTP, WP-CLI, or hosting file tools before broad plugin deactivation on a live store or membership site.

How to Fix It Manually

1. Read the newest PHP fatal error from the server log or a safe debug log with public error display disabled.
2. Convert the byte value in the message to megabytes so you know whether the request hit 128M, 256M, 512M, or another configured cap.
3. If the path points to one plugin, theme, builder, report, backup, scanner, or import tool, reproduce that action on staging and disable only that component first.
4. If the path points to WordPress core, check the stack trace or surrounding log lines before blaming core; core files often appear because a plugin called a heavy core API.
5. If the site has a genuinely low PHP limit, ask the host to raise PHP memory and confirm whether WordPress is allowed to use `WP_MAX_MEMORY_LIMIT` for admin requests.
6. Split large imports, exports, image regenerations, and reports into smaller batches or move repeatable work to CLI/server-side jobs where practical.

After each step, retest the same admin action. If the error disappears, document whether the fix was a host limit change, a smaller batch size, a plugin update, a disabled module, a theme rollback, or a code change. If a temporary change did not help, reverse it so the site does not collect unrelated workarounds.

How WPlura Helps

Web Plura Diagnostics is useful after the first log capture because it keeps the surrounding evidence in one local review. It can surface hosting limits, PHP memory status, max execution time, plugin and theme impact signals, update risk, cron pressure, front-end response checks, and support-safe exports. It does not automatically fix memory leaks or replace hosting support; it helps make the next handoff more specific.

Symptoms to Confirm

A memory exhausted message is more precise than a generic white screen. Confirm the action that consumes memory before changing server settings. If the dashboard loads but one report fails, the problem is probably different from a site where every admin request fails immediately after a plugin activation.

• The fatal line includes text such as `Allowed memory size of ... bytes exhausted` and names a PHP file that was active when the allocation failed.
• Only one admin workflow fails, such as a CSV import, media regeneration, WooCommerce analytics report, page-builder edit, backup job, or security scan.
• The issue started after a plugin update, PHP version change, large content import, new builder module, restored backup, or host plan/configuration change.
• The site works for visitors but wp-admin fails for administrators, which usually points to admin-only memory pressure rather than a public caching issue.

Likely Root Causes

Do not treat a memory exhausted message as proof that WordPress core is broken. The failing file path shows where the request ran out of room, not always the original cause. A plugin may load too much data, a report may query too many rows, a builder may load a large template tree, or a backup/import process may hold too much content in memory.

• The PHP `memory_limit` is too low for the site, or the host does not allow WordPress to raise the admin-side limit requested by `WP_MAX_MEMORY_LIMIT`.
• A plugin, theme, builder, backup, security scan, analytics report, or import/export task loads too many records, files, images, or options into one request.
• A recently restored backup, migration, or database cleanup left unusually large autoloaded options, transients, logs, sessions, or orphaned metadata.
• The workflow belongs in smaller batches, WP-CLI, Action Scheduler, server cron, or a queue instead of one browser-triggered admin request.
• A plugin update, PHP version change, or host configuration change exposed an existing memory-heavy workflow that had previously stayed just under the limit.

Use Diagnostics for the Handoff

Use Web Plura Diagnostics after you have captured the original fatal error and restored enough admin access to run local checks. Its value is not guessing which line of code leaked memory; it is organizing the host, PHP, plugin/theme, update, cron, and response signals that a developer or host needs to see.

1. Install the free Web Plura Diagnostics plugin from WordPress.org only after the site is stable enough to access wp-admin safely.
2. Run Diagnostics to record PHP memory, execution limits, hosting checks, plugin/theme impact context, update risk, cron pressure, and front-end response status.
3. Use Fix First items to decide whether the next owner is the site admin, developer, plugin vendor, theme vendor, or hosting support.
4. Use the support-safe snapshot, JSON export, or CSV export when the host needs environment evidence without raw private logs.
5. After changing a limit, batching a job, rolling back a plugin, or fixing code, rerun the same review and keep the before/after result with the incident notes.
6. Use the WordPress.org plugin page as the installation reference: download the free plugin on WordPress.org
7. Use the WPlura product page for product details and support context: WPlura product details
8. Keep the final decision human-owned. Web Plura can help surface local findings and organize next actions, but it should not replace backups, staging, hosting support, or developer review when the issue is business-critical.

The free WordPress.org plugin is the primary CTA for this workflow: download the free plugin on WordPress.org. For broader product information, use WPlura. Keep product usage practical: capture the fatal error, run the local check when admin access is available, review findings, export or document the result, then continue with the manual fix described in this guide.

Keep Recovery Evidence Useful

A useful memory incident note should help the next person reproduce the failure without repeating every experiment. That matters because memory errors often come back during the same import, report, backup, builder edit, or update window.

• Record the exact action that failed, not only the screen where the error appeared.
• Save the memory limit, attempted allocation, PHP version, active plugin/theme change, and hosting limit answer.
• Keep before/after notes when a host raises memory, a plugin is rolled back, or a large task is moved to batches.
• Separate emergency recovery from prevention: restoring wp-admin is not the same as proving the heavy workflow is healthy.
• Share concise environment evidence with support instead of copying raw logs, stack traces, private file paths, or customer data into tickets.

Prevent the Same Issue From Returning

• Keep PHP memory, max execution time, upload limits, and WordPress admin memory settings documented with hosting support.
• Run large imports, exports, image regeneration, analytics rebuilds, and backups in smaller batches or CLI/server jobs where possible.
• Review plugins that store very large logs, sessions, transients, report caches, or autoloaded options.
• Test updates and PHP version changes on staging before repeating the same heavy admin workflow on production.
• Keep backups and restore instructions ready before editing wp-config.php, changing PHP settings, rolling back plugins, or cleaning database tables.

Good troubleshooting leaves the site easier to support next time. Keep the final fix, the source of memory pressure, the rollback option, and the owner of the setting in one short note that another admin can understand later.

Related WPlura Plugin Help

If a memory exhausted error is blocking wp-admin on a real site, finish the manual checks in this guide first, then use Web Plura Diagnostics as the related WPlura support tool when admin access is available. Start with the free WordPress.org plugin download: download the free plugin on WordPress.org. For teams that need recurring comparison, connected reports, alerts, or portfolio oversight, use the WPlura Pro path after reviewing the free diagnostics first. Pro purchase and private download access starts here: WPlura Pro purchase and private download. Review product details and Free versus Pro fit here: WPlura product details. Keep the plugin workflow practical: collect evidence, make one reversible change, and confirm the result before you move to the next fix.

1. Install and activate the free Web Plura Diagnostics plugin from WordPress.org, then open the plugin screen in wp-admin after you capture the original symptom.
2. Run the diagnostic review before making another live change so you have one local snapshot of the issue, recent risk areas, and ownership clues.
3. Start with Fix First items and decide whether the next action belongs to the site admin, developer, host, DNS provider, or email provider.
4. Use a support-safe snapshot, JSON export, or CSV export when you need to share concise evidence with a developer or hosting support team.
5. After the manual fix, run the same check again and keep the before and after notes with the site maintenance record.

References

Frequently Asked Questions