Capture the exact memory error and affected task, confirm the effective runtime and host constraints, then repair the evidenced workload or capacity mismatch with a bounded recovery plan.
Allowed memory size exhausted tells you that a PHP allocation failed under the relevant limit. It does not, on its own, identify the component that created the workload or tell you how much memory a WordPress site should have. Start with the exact failing task and the configuration actually used by that task.
Imagine a fictional local-history site importing a large archive. Public articles still open, but the import stops with a fatal error. The proposed record below is an investigation plan, not a measured import. Its purpose is to avoid replacing an unexplained failure with an arbitrary larger number.
Record the error and the operation together
Keep the error time, time zone, action, input scope, installed versions and most recent relevant change. Record the reported allowed bytes and attempted allocation without exposing server paths or private filenames in a public ticket. Ask an authorized operator to retain the protected original log.
The file named at the failure location is a useful lead. It is not proof that the file’s owner alone caused the earlier allocations. For the archive import, establish which import step failed, what had already completed and whether a repeat could create duplicate records.
Preserve the affected content and a usable recovery point before changing the workload. Do not repeatedly rerun a partially completed import merely to obtain another error message. The current data state is part of the incident, especially when a task performs writes before it stops.
Separate allocation limit from hosting capacity
The PHP configuration manual defines memory_limit as a script-allocation bound. That value is not the same as a hosting account’s physical capacity. PHP 8.5 also provides max_memory_limit, a startup cap on requested values; earlier versions and host policies can behave differently.
For the fictional site, ask the host which PHP version and runtime executed the failed import, which effective limit applied and whether a supported change is available. Do not treat a number from an unrelated command-line session or another website as proof of this request’s configuration.
The hosting resource-limits guide distinguishes provider units and constraints. Use it to frame the capacity conversation. A new PHP setting cannot be assumed to remove every account, process or concurrent-workload constraint imposed by the hosting arrangement.
Understand what WordPress constants request
The WordPress configuration handbook describes WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT. These are requests within the runtime arrangement, not purchased memory. A host can restrict changes, and an administration task can have a different requested limit from an ordinary public-page request.
The wp_raise_memory_limit reference shows that a request can return false when memory_limit cannot change. The effective configuration remains the relevant evidence; a constant written in a file is not proof that the running task received that value.
Have the operator confirm the correct installation and configuration path before any edit. A shared hosting account can contain several sites. Record the actual value, context and supported override location for this one, instead of copying a snippet into every configuration file that looks plausible.
Build a task-focused comparison
| Observation | Comparison to request | What it does not prove |
|---|---|---|
| Only the archive import fails | Same workflow with a supported smaller input in staging | All ordinary pages need more memory |
| Failure began after one change | Controlled comparison with the last working component set | The last changed file is certainly responsible |
| A configured increase has no effect | Effective runtime value and host override rules | Another larger number will be accepted |
| Several unrelated tasks fail | Shared workload and runtime evidence from the operator | Database corruption or a security incident |
Make comparisons in a recoverable environment with representative data, and label any difference from the live workload. A tiny demonstration may show that a tool starts successfully without showing it can complete the real archive. Keep input size and completed steps in the record.
Ask the component maintainer whether a supported batch or streaming workflow exists for this task. That question is more actionable than requesting an undocumented maximum. Do not split files arbitrarily if the importer requires one coherent input or cannot safely resume.
Use a controlled component investigation
If evidence points to an interaction, the safe plugin-conflict guide provides a comparison workflow. Change one relevant condition at a time in a suitable test copy. Preserve the active configuration and recovery instructions, rather than deactivating essential features on the public site without a plan.
Send the maintainer a redacted record of the task, versions, effective limit and reproduction scope. Explain what completed and what did not. A report that says “your plugin uses too much RAM” without those details gives the maintainer little to investigate and may blame the wrong layer.
If support asks for private data or a full database, decide what evidence can be shared safely through an approved route. A staging reproduction should not casually expose customer records, account secrets or a live configuration file.
Choose a bounded repair, not an unlimited setting
A justified repair may change an inefficient workload, use a supported smaller batch, correct a runtime mismatch or increase a supported allocation within available capacity. The evidence and responsible operator should determine which action fits. These choices are not interchangeable remedies for every fatal error.
Before a limit increase, record the previous setting, intended new value, scope and review point. Ask the host about concurrent work and operational impact. Removing the limit altogether can hide an allocation problem while transferring the risk to other tasks, so it is not a reasonable default diagnostic step.
The autoloaded-options guide addresses another possible workload concern. A warning there is not proof of this task’s cause, and a memory fatal is not authorization to delete options. Connect the two only when task-specific evidence supports that connection.
Verify completion and the state of the data
- Repeat the affected operation through its supported, recoverable workflow.
- Confirm the effective runtime configuration and review the relevant error window.
- Check that expected records or files are complete, with no duplication from retries.
- Confirm ordinary public and administration journeys still work.
- Retain the bounded setting, recovery instructions and any remaining workload limit.
The site is not repaired merely because the last attempt took longer to fail or stopped displaying the fatal publicly. A successful result connects the intended task, correct data state and a configuration the operator can maintain.
Sources and verification
Editorial review 2026-10-15. Source check dates are recorded separately. Notes describe what each source supports and its limits.
View sources
- PHP core configuration directivesChecked memory_limit restricts script allocation; PHP 8.5 adds a startup maximum that can cap requested values.
Limits: Defaults do not establish the installed version of the reader or effective configuration. - WordPress wp-config.php handbookChecked WordPress memory constants request runtime limits subject to hosting restrictions.
Limits: Changing a constant does not add physical server capacity. - WordPress wp_raise_memory_limit referenceChecked A runtime request can fail when the PHP setting is not changeable; contexts can differ.
Limits: Reference code does not prove the effective value on a particular website.