Subtle diagonal pinstripe pattern in light grey and cream, giving an impression of printed editorial paper

Fixing the WordPress Memory Exhausted Error by Adjusting php.ini

A PHP “Allowed memory size exhausted” error means one request reached its configured ceiling while loading WordPress, a plugin, a theme, or a third-party library. It does not automatically mean the server has run out of physical RAM. On a typical WordPress host, PHP runs separately from the web server, MySQL, Redis, and the operating system, so checking the PHP process limit first prevents costly changes to unrelated server resources.

The safest repair is to identify the task that fails, raise the relevant limit to a measured value, and then reduce any workload that is genuinely excessive. This sequence matters across the Australian market, where managed plans may impose platform ceilings while VPS servers give administrators direct control. A higher number can stop an immediate fatal error, but it cannot repair a runaway loop, a leaking plugin, or millions of records loaded into one request.

Why WordPress Requests Exhaust PHP Memory

WordPress is not inherently memory hungry. Its usage rises as PHP loads the active theme, hooks, options, translations, and every enabled plugin. Multisite networks, localisation, page builders, security scanners, and WooCommerce extensions can add substantial overhead. A useful first step is to record which plugins are active and test with unused extensions disabled, especially on an administrator page where all tools are loaded.

Large media libraries and imports create another common pressure point. Resizing one high-resolution image can require far more memory than displaying a thumbnail, while CSV imports, database repairs, and backup tasks may hold large arrays in memory simultaneously. Repeated database queries also matter because each returned result can consume PHP memory even when MySQL itself remains within its allocation.

Concurrency creates a separate problem. Several PHP workers can each approach their individual ceiling, so a busy site may exhaust the server’s available resources even when no single request exceeds 512 MB. Sydney and Melbourne retailers often see bursts during end-of-financial-year promotions and Christmas trading, while WooCommerce cron requests add further background work. The right limit must therefore fit both the heaviest individual request and the host’s worker configuration.

Confirm the Effective PHP Memory Limit

Open WordPress Site Health, select Info, and look for the PHP memory limit. Record that value together with the PHP version, server architecture, and active plugin list. Also capture the exact failed action and its timestamp from WP_DEBUG_LOG or the web-server error log. A WordPress log may not contain every PHP fatal, particularly when failure occurs before WordPress finishes loading.

On a server with SSH access, these commands reveal the command-line PHP configuration:

php --ini
php -r 'echo "memory_limit=" . ini_get("memory_limit") . PHP_EOL;'

The result describes PHP CLI, which is useful for WP-CLI but does not always match the FPM service serving website requests. A host may run PHP 8.2 for FPM and PHP 8.3 for the command line, or apply different pool settings. Australian regions in Sydney, Melbourne, and Brisbane affect network latency and hosting availability, but they do not determine this per-process limit; the PHP configuration does.

Raise the Limit in the Hosting Panel

Managed WordPress and shared hosting often do not permit direct access to php.ini. Instead, the provider may expose PHP Selector, MultiPHP INI Editor, Plesk PHP Settings, or a custom resource control panel. This is a common arrangement among Australian host resellers and agencies. Set the memory limit there, apply the change, and allow the panel or PHP service to reload. Values such as 256M or 512M are more useful than an extreme figure unsupported by the plan.

Start with 512M for a proven heavy task, then retest it. If the operation succeeds comfortably and Site Health reports the new value, there is no reason to jump directly to unlimited memory. A limit of 1G allows one faulty request to consume far more RAM before failing, potentially forcing the host to terminate other workers or apply penalties.

If the setting cannot be changed, send the provider the PHP version, FPM or module type, current limit, requested limit, and supporting error message. The WordPress memory troubleshooting reference can help distinguish an import, image editor, cron, or ordinary page-view failure. The provider may need to adjust the FPM pool because a panel value alone might not override the actual server ceiling.

Edit php.ini on a Linux VPS

First identify the PHP version used by the website and locate its loaded configuration. Common FPM paths include /etc/php/8.2/fpm/php.ini and /etc/php/8.3/fpm/php.ini, while CLI configuration normally sits under the corresponding cli directory. Distribution packages and containers can use different paths, so do not copy a command until php --ini and the active service have been checked.

Back up the current configuration, then create a clearly named override in the FPM conf.d directory when that directory is enabled. For example:

memory_limit = 512M

A file such as 99-wordpress.ini makes the purpose obvious and avoids editing several core PHP files. If a pool definition imposes its own php_admin_value[memory_limit] directive, update that existing pool entry instead. Pool-level settings can take precedence over the general file, which explains why changing a visible php.ini sometimes appears to have no effect.

Reload or restart the matching PHP-FPM service after validating its syntax. The service name might be php8.3-fpm, php8.2-fpm, or simply php-fpm, depending on the server:

sudo systemctl restart php8.3-fpm

Then verify the result through Site Health or another FPM-aware method rather than assuming the CLI value changed. Do not confuse max_execution_time with memory: allowing a script to run longer does not give it more memory, and stopping it sooner does not resolve an exhausted allocation.

Align WordPress With the PHP Runtime

WordPress has its own limits for normal and administrative work. When they are not already defined in wp-config.php, values such as these can be added before the stop-editing line:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

The first generally covers front-end WordPress requests, while the second supports heavier administration, imports, and maintenance tasks. These constants do not control every PHP process on the server. WP-CLI, cron workers, image tools, and third-party scripts may use separate settings, while the host’s configured ceiling still matters.

Per-directory files can help on selected hosts. A .user.ini file may set a higher limit for CGI or FastCGI, while .htaccess works only when the server uses mod_php and allows the relevant directive. Neither is a reliable substitute for the FPM configuration on a modern host. Keep the change in one authoritative location to avoid conflicting values and confusing test results.

For sites without SSH or panel access, the hosting provider must make the server-side adjustment. Agencies that prefer to delegate this work can use managed WordPress support to verify the PHP version, apply the setting, and test the failing workflow. Whatever route is used, record the effective limit rather than merely confirming that a value was entered.

Verify the Change and Control Memory Growth

Treat the adjustment as a controlled change with evidence before and after it. The starting values and failing operation provide a baseline for deciding whether the new limit fixed the cause or merely delayed failure.

Record the starting point

After the change, repeat the same operation with representative data. A small sample may pass even though a production import still exceeds the allocation. Compare response time, memory use, worker saturation, and log output, then retain the lowest stable limit.

Verify the result

Persistent growth can indicate a leak rather than an undersized limit. Review active plugins, clear expired transients safely, optimise oversized queries, and use persistent object caching where appropriate. Daylight-saving changes add another Australian consideration: New South Wales and Victoria shift clocks while Brisbane remains on AEST, so cron schedules for stores operating across those zones deserve review. A verified limit, bounded workload, and clean logs under realistic traffic are the reliable signs of a stable WordPress installation.