A blank white screen when opening the Elementor editor — especially on a large or widget-heavy page — is almost always Elementor Pro's editor hitting a PHP memory or execution-time ceiling, 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 Elementor editor itself (not just the front-end page) loads a large amount of JavaScript, widget configuration, and page data server-side; Elementor's own documentation recommends at least 256M for comfortable editing, and many hosts default to 128M or lower.
  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 back to false once you're done checking — leaving it on in production isn't a security concern by itself, but leaving WP_DEBUG_LOG on can grow the log file over time.

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 — 256M is Elementor's documented recommendation; if you're already at 256M and still hitting the issue, try 512M rather than jumping 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 — 300 (5 minutes) is a reasonable ceiling for the Elementor editor's load process; the default on many hosts is 30, which is genuinely too short for a heavy Elementor page.
  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. Go to Elementor → Tools → Regenerate CSS (and Regenerate Files if you're on Elementor Pro) to rebuild Elementor's cached data.
  2. If the white screen persists, 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.

Related fixes

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?

aaPanel's php.ini-level setting is the actual ceiling and takes priority — a WP_MEMORY_LIMIT constant in wp-config.php can raise WordPress's own internal limit but cannot exceed what PHP itself allows at the server level. If aaPanel's memory_limit is still set too low, 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?

256M (or 512M if needed) is a normal, safe permanent setting for a WordPress site running Elementor Pro — it's not a temporary workaround. Elementor's own system requirements documentation lists 256M as the recommended baseline, so there's no need to lower it back down afterward.