The symptom always looks the same: a heavy operation stops halfway, or the page goes blank, and the error log carries the line Allowed memory size of ... bytes exhausted. It is not broken code: it is an operation that did not fit in the memory it was given.
Three ceilings, and the order they apply in
All the confusion comes from there being three different limits with similar names. None can exceed the one above it:
| Ceiling |
What it is |
| 1. The account memory |
The total your plan gives you, shared by everything running at once. It is the ceiling over all the others and it is not changed in cPanel: the limits nobody advertises. |
| 2. PHP’s memory_limit |
The most one request may spend at a time. You change it in cPanel yourself. |
| 3. WP_MEMORY_LIMIT |
A ceiling WordPress imposes on itself, inside the previous one. Changed in wp-config.php. |
|
Raising ceiling 3 without raising 2 does nothing. It is the commonest mistake, and it explains the afternoons lost editing wp-config.php with nothing changing. WordPress cannot exceed PHP, and PHP cannot exceed the account. Change both, in that order.
|
Step 1: PHP, in cPanel
| 1 |
In cPanel, open Select PHP Version and go to the Options tab. Alternatively, MultiPHP INI Editor does the same per domain.
|
|
| 2 |
Find memory_limit and pick a higher value than the one there.
|
|
| 3 |
Save. The change takes effect immediately; you do not need to ask us for anything.
|
|
The table of the four PHP limits, with values that solve nearly everything and the order they have to sit in relative to each other, is in PHP limits: memory, time and upload size.
Step 2: WordPress, in wp-config.php
Add these two lines above the one saying That’s all, stop editing:
| 1 |
define( 'WP_MEMORY_LIMIT', '256M' ); applies to the site.
|
|
| 2 |
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); applies only to the admin dashboard, which is where the heavy operations run: imports, updates and backups.
|
|
If the site goes blank after saving, it was not the memory: it was a syntax error in the file. One missing quote is enough. See common WordPress errors.
Step 3: confirm it took
Do not trust the file: confirm on the site.
| 1 |
In the WordPress dashboard, open Tools › Site Health › Info and the Server section. PHP’s memory_limit is there, and a WordPress section shows the limit it sets itself.
|
|
| 3 |
Repeat the operation that was failing. That is the test that counts.
|
|
|
A cause nobody looks for: the PHP version. If the domain runs one version and you changed the options of another, the value does not move and it looks as though the panel is broken. Check which version is active for this domain before touching the options.
|
When raising it is the wrong answer
Worth saying, because it saves everybody money: if you are raising the same limit for the third time, the limit is not the problem.
| What is happening |
What to do instead of raising it |
| An enormous import never finishes |
Break it into parts. Most import tools have that option. |
| A page full of images blows up |
It is the images that are wrong, not the memory: the site is slow. |
| One plugin alone wants half a gigabyte |
That plugin has a defect, and the defect is not the server’s. Find it by deactivating half at a time. |
| The whole site has grown heavy over the years |
The conversation has become about the plan: shared hosting vs VPS. |
To find which plugin it is, the error log line usually gives the path of the file that blew up. How to read it is in where the PHP error log is, and if the messages are showing on the site itself, PHP warnings showing on your site.
RECOMMENDED PRODUCT WordPress hosting One-click install, updates handled, and speed that holds up. See plans |
Angola
Brasil
Kenya
Moçambique
Nigeria
Portugal
South Africa
United Kingdom
United States
International
