WPFIX STACK — home
Elementor Fixes

Elementor White Screen on aaPanel? Fix PHP Limits Without Breaking Your Server Config

Elementor editor showing a white screen on your aaPanel-hosted WordPress site? Raise memory_limit and max_execution_time safely from aaPanel's PHP settings tab.

By Published Updated 6 min read

A bright modern office setup with computers and a mug on a desk.
Photo by Tranmautritam on Pexels

A blank white screen when opening the Elementor editor — especially on a large or widget-heavy page — is most often PHP running out of memory (or time) while the editor loads, not a broken plugin. On aaPanel-hosted sites this is straightforward to fix without touching SSH: aaPanel exposes memory_limit and max_execution_time per PHP version directly in its panel UI, and raising them safely resolves most cases.

Symptoms

  • The Elementor editor loads a blank white page (front end of the site works normally).
  • The white screen appears specifically when opening large pages, ones with many widgets, or ones with Elementor Pro's Theme Builder templates loaded.
  • Opening a simple, mostly-empty page in the editor works fine — it's only the heavier pages that break.
  • Enabling WP_DEBUG shows a "Allowed memory size of X bytes exhausted" or a fatal error referencing memory, or the page simply times out without any visible error at all.

Likely causes, in order of how often they actually happen

  1. PHP's memory_limit is too low for what the Elementor editor needs to load. The editor (not just the front-end page) loads a large amount of widget configuration and page data server-side. Elementor's system requirements (opens in a new tab) set a 256 MB minimum, recommend 512 MB, and suggest 768 MB for best performance; many hosts default to 128M.
  2. PHP's max_execution_time is too short for pages with a lot of dynamic content or many widgets, causing the editor's initial load request to be killed mid-process before it finishes rendering, which shows as a blank screen rather than a clear error.
  3. A plugin conflict or corrupted Elementor data cache is a real possibility too, but it's much less common than the two limits above — worth ruling out only after confirming the PHP limits are already adequate.

Fix it: lowest-risk steps first

Step 1 — Confirm this is actually a PHP limit issue before changing anything

  1. In wp-config.php, temporarily enable debugging by setting define('WP_DEBUG', true); and define('WP_DEBUG_LOG', true); (add them above the "That's all, stop editing!" line if they're not already present).
  2. Reproduce the white screen by opening the problematic page in the Elementor editor.
  3. Check wp-content/debug.log for a line mentioning "Allowed memory size" or a fatal error tied to memory. If you see it, proceed to Step 2. If the log shows something else entirely (a specific plugin function, a PHP version incompatibility), that's a different issue and raising limits won't fix it.
  4. Turn WP_DEBUG and WP_DEBUG_LOG back to false once you're done checking. WordPress recommends against running debug tools on live sites (opens in a new tab): errors are displayed on the page by default, which can expose file paths to visitors, and wp-content/debug.log can be downloaded by anyone who requests it unless your server blocks it.

Step 2 — Raise memory_limit for this PHP version in aaPanel

  1. In aaPanel, go to Website → find your domain → confirm which PHP version it's running (shown in the site's settings), then go to App Store (or Software Store) → PHP → find that same version → Settings.
  2. Open the Configuration tab (sometimes labeled php.ini or Config file depending on aaPanel version) — this is the panel's editable view of that PHP version's php.ini.
  3. Find memory_limit and raise it. Elementor's documented minimum is 256M and its recommendation is 512M (requirements (opens in a new tab)), so 512M is a sensible target for a site whose editor already white-screens; there's no need to jump arbitrarily higher.
  4. Save and restart that PHP version's service (aaPanel prompts for this automatically, or restart it manually from the PHP version's overview page).

Step 3 — Raise max_execution_time alongside it

In the same PHP configuration screen:

  1. Find max_execution_time and increase it. Elementor's requirements don't state a value for it; the common default of 30 seconds can be too short for a heavy Elementor page, and 300 (5 minutes) is a generous ceiling while you test.
  2. Save and restart the PHP service again if aaPanel doesn't do it automatically.
  3. Note that some hosts also enforce a separate max_input_time — if raising max_execution_time alone doesn't fully resolve the white screen, check and raise that value too, in the same configuration screen.

Step 4 — Rule out a plugin conflict or corrupted Elementor cache (only if Steps 1–3 didn't fully resolve it)

  1. Clear Elementor's generated files to rebuild its cached data: Elementor → Editor → Home, then Tools → Clear Files & Data (Elementor's guide (opens in a new tab)).
  2. If the white screen persists, turn on Elementor's Safe Mode (opens in a new tab) (Elementor → Editor → Tools), which loads the editor without other plugins and theme code. If the editor opens in Safe Mode, deactivate other plugins one at a time (starting with any caching, security, or optimization plugins) and retest the editor after each, since these categories are the most likely to interfere with the editor's own AJAX/REST requests.

Verify the fix

  1. Open the previously broken page in the Elementor editor and confirm it loads normally.
  2. Open the largest, heaviest page on the site (or a Theme Builder template) as a stress test, since that's most likely to hit limits again if they're still insufficient.
  3. Check wp-content/debug.log (with WP_DEBUG briefly re-enabled) to confirm no further memory or timeout errors appear.

If you need to roll back

If raising the limits causes any instability on shared/limited hosting (unlikely on a VPS running aaPanel, but possible on resource-constrained plans), return to the same Configuration tab in aaPanel and restore the original memory_limit and max_execution_time values you noted before making changes, then restart the PHP service. Since this is a server-configuration change rather than a WordPress data change, there's nothing to restore from a WordPress-side backup — reverting the php.ini values is sufficient.

FAQ

Will raising memory_limit slow down my server or affect other sites?

memory_limit is a per-request ceiling, not memory reserved in advance — increasing it only allows individual PHP processes to use more memory if they need to, it doesn't pre-allocate anything. On a VPS running multiple sites under the same PHP version, a higher ceiling means a single runaway process could theoretically use more RAM, but normal Elementor editing sessions won't approach that unless something is already wrong.

Do I need to change this in wp-config.php too, or is aaPanel's setting enough?

Set it in aaPanel; that's the reliable place. WordPress's WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT constants only ask PHP to raise the limit at runtime, and WordPress notes that some hosts don't allow that (opens in a new tab) (for example when the value is locked in the PHP-FPM pool configuration). If aaPanel's memory_limit is too low and can't be raised at runtime, a wp-config.php change alone won't fix the white screen.

I raised both limits and it's still white-screening — what next?

At that point it's more likely a plugin/theme conflict or a corrupted browser cache of the editor's JavaScript rather than a server limit. Try the editor in an incognito window first (rules out browser cache), then work through Step 4's plugin deactivation process before assuming it's still a PHP configuration issue.

Is 256M memory_limit safe as a permanent setting, or should I lower it after fixing this?

Keep it. Elementor's requirements (opens in a new tab) list 256 MB as the minimum and 512 MB as the recommendation, so 256M–512M is a normal permanent setting for a site running Elementor, not a temporary workaround — there's no need to lower it afterward.

Stefan Nistor

Founder, WP Fix Stack

Stefan runs WP Fix Stack. Every guide checks its commands, menu paths and limits against the official documentation of WordPress, PHP, the hosting panel, Cloudflare or the plugin involved, and links those sources so you can verify them. Fixes are ordered from the least risky step, each guide ends with a way to confirm the fix and roll it back, and guides are corrected, with a new Updated date, when the documentation or the software changes.

Every guide explains the symptom, likely causes, the safest order of checks and how to confirm the fix. How we check our guides.

On this page