Increasing the WordPress memory limit (and the PHP limit behind it)

The fastest fix for "Allowed memory size of X bytes exhausted" is to raise WordPress's own memory limit in wp-config.php. But that only helps if PHP itself allows more memory than WordPress is asking for. On a Flashcloud install, WordPress's limit and the server's PHP limit are two separate settings, and you may need to touch both.

Raise the WordPress memory limit first

Open wp-config.php in File Manager or over FTP/SFTP and add this line above the /* That's all, stop editing! */ comment:

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

This raises the limit for regular front-end and admin requests. If the error happens specifically in wp-admin, during an import, or while a plugin runs a bulk task, also set the admin-side limit:

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

WP_MEMORY_LIMIT covers normal page loads. WP_MAX_MEMORY_LIMIT covers admin and script-heavy tasks, which legitimately need more headroom. Save the file and reload the page that was failing.

Why WordPress caps itself at all

WordPress sets its own internal ceiling on top of whatever PHP allows, as a safety default. Most fresh installs ship with a conservative number, low enough that an image-heavy import, a page builder, or a plugin with a memory leak can hit it before PHP's own limit ever comes into play. Raising WP_MEMORY_LIMIT is almost always step one, and it's often the only step needed.

If that doesn't fix it: check the PHP limit underneath

WordPress can't ask for more memory than PHP is configured to hand out. If you set WP_MEMORY_LIMIT to 256M but PHP's own memory_limit directive is set lower, PHP wins and the error keeps happening.

On a Flashcloud account, PHP resource limits (including memory_limit, along with upload_max_filesize, post_max_size, and max_execution_time) are changed in cPanel, not in the portal's PHP Version tile. The PHP Version tile only switches PHP versions per domain. To change the actual limits:

1. Log in to cPanel (one-click login from the portal at portal.flashcloud.com).
2. Go to Software → MultiPHP INI Editor.
3. Select your domain, then either use Basic mode to edit common directives with a dropdown, or switch to Editor mode for full control over the raw INI values.
4. Set memory_limit to a value equal to or higher than your WP_MEMORY_LIMIT, for example 256M.
5. Save, then reload the page that was failing.

If you don't see the increase take effect, double check you edited the correct domain. MultiPHP INI Editor applies settings per domain, and it's easy to edit the wrong one if you host multiple sites on the account.

Only install a plugin if you can't edit files

Editing wp-config.php and MultiPHP INI Editor directly is the right approach whenever you have file access. A memory-limit plugin is a fallback for cases where you genuinely can't reach the file system, not the first move. Plugins that claim to "increase memory limit" from inside wp-admin are really just automating the same wp-config.php edit, and they add one more piece of code running on every page load. If you already have File Manager or FTP access, skip the plugin and edit the file directly.

Why the limit gets hit in the first place

Raising the ceiling stops the immediate error, but it's worth checking what's actually consuming the memory, especially if you needed to go past 256M. Common causes:

• Plugin bloat. Security suites, page builders, and "all-in-one" plugins each add their own memory overhead on every request. See My WordPress site is slow for how to audit which plugins are the heaviest.
• Large imports or migrations. Media library imports, XML imports, and search-and-replace operations across a big database all spike memory temporarily. These are exactly the cases WP_MAX_MEMORY_LIMIT exists for.
• A WooCommerce store under load. Product catalogs, order processing, and checkout all carry more memory weight than a typical blog. Flashcloud WordPress installs run on LiteSpeed with the LiteSpeed Cache plugin and a Redis object cache preconfigured, which reduces the repeated database and PHP work that drives up memory use under load. See Running a WooCommerce store for the caching and object-cache setup that keeps stores from hitting limits during normal traffic, not just during a one-off fix.

Test the change on staging first

If you're raising the memory limit to get a specific plugin, theme, or import to work, and you're not sure it'll behave once it has the headroom, run it on a staging copy first rather than testing on the live site. See Using WordPress staging for the workflow. This matters most when the memory exhaustion showed up during something risky, like a plugin update or a bulk import, since the underlying operation might still fail or corrupt data for reasons unrelated to memory.

Whatever you're about to run, take a fresh backup first, so you have a clean point to return to if something goes wrong.

When to open a ticket

If you've raised both WP_MEMORY_LIMIT and PHP's memory_limit in MultiPHP INI Editor and you're still hitting exhaustion errors at a high value, that's usually a sign of a plugin actively leaking memory rather than a limit that's still too low. Open a support ticket and include the exact error message with the byte count and which page or action triggers it, and our team can help investigate further.