A page suddenly died with WordPress’s “critical error” screen. The logs showed the server burning through 1 GB of memory per page load. The culprit: an accordion tab configured to embed the very template it lived inside.
01The symptom: one page down, everything else fine
The report was short: “the Capabilities page shows a critical error.” Sure enough, one URL on the client’s staging site returned WordPress’s famously unhelpful white box, while the homepage, wp-admin, and every other page worked perfectly.
There has been a critical error on this website.
A page-specific fatal is actually good news: it means the crash lives in that page’s content or in a code path only that page triggers. The bad news was everything else — no hosting access, no SSH, no FTP, log URLs blocked by the CDN’s firewall, and the plugin file editor disabled. All we had was wp-admin.
02Getting a real error without server access
Two wp-admin tricks saved the day. First, Wordfence → Tools → Diagnostics → Log Files lists the PHP error_log files the host writes into the site directory — with download links. That’s a full server error log without a single hosting credential.
[15-Jul-2026 09:00:27 UTC] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 28672 bytes) in .../wp-includes/shortcodes.php on line 561 [15-Jul-2026 09:04:08 UTC] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted ... in .../plugins/elementor/includes/base/widget-base.php on line 191 [15-Jul-2026 09:06:43 UTC] PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted ... in .../plugins/elementor/core/files/css/base.php on line 298
One gigabyte exhausted while rendering a page of text and accordions is not a “raise the memory limit” situation. Something was allocating in a loop. An OOM fatal carries no stack trace, so the log alone couldn’t say what — but it narrowed the class of bug to runaway rendering.
03Bisecting with nothing but the Plugins screen
With no debugger available, the next tool is the oldest one: turn things off. The suspicion was a recent plugin update, so that got tested first — and promptly cleared.
| Test | Configuration | Result |
|---|---|---|
| 1 | Everything on (as reported) | Fatal |
| 2 | Addon Pro plugin deactivated | Fatal |
| 3 | Addon Lite + Pro both deactivated | Page renders |
| 4 | Lite rolled back one version (WP Rollback) | Fatal |
| 5 | Only the Advanced Accordion widget disabled | Page renders |
Most widget-suite plugins (Essential Addons, in this case) let you disable individual elements from their settings screen. That turns “which of 100 widgets is it?” into a couple of clicks per hypothesis. Five tests in, the answer was: the Advanced Accordion, and only on this page.
04Finding the loop in the data
Why would an accordion — of all things — eat a gigabyte? The accordion’s tabs can embed a saved Elementor template as their content. Time to look at what those tabs actually pointed to. Still without database access, Tools → Export → “My Templates” produces an XML file containing every template’s raw _elementor_data JSON. A short script listed every accordion tab and its target template:
template 52995 'Primary Healthcare' tab 'Maternal Health' → 53020
template 52995 'Primary Healthcare' tab 'Child Health' → 53084
template 53041 'Health Systems' tab 'Digital Health' → 53121
template 53042 'Education Plus' tab 'Education' → 53042 ← itself!
template 53042 'Education Plus' tab 'Arts & Culture' → 53166
There it was. The template named Education Plus contained an accordion whose “Education” tab was set to render… Education Plus. Someone editing the page had picked the wrong entry from the template dropdown — the section itself instead of the similarly-named content template “Education Plus – Education”. An easy mistake: the two names differ by one word.
shortcodes.php.Why isn’t this caught automatically? Elementor’s own Template widget guards against a document rendering itself. Third-party widgets that call Plugin::$instance->frontend->get_builder_content() directly — accordions, tabs, flip boxes, off-canvas panels across many addon suites — typically validate that the target exists and is published, but not that it’s currently being rendered. One mis-picked dropdown entry is all it takes.
05The fix — and the trick that makes it safe
There’s a catch-22 in fixing this: opening the broken template in the Elementor editor makes the editor render it — which triggers the same recursion and can crash the editor too (the site’s logs showed editor OOMs on the very day the bad setting was saved). The way out is pleasantly low-tech: set the template to Draft first. Template-embedding widgets refuse to render unpublished templates, so drafting the template breaks the cycle and the editor opens instantly.
- Draft the looping template. Go to Templates → Saved Templates, find the template (here: “Education Plus”), Quick Edit → Status: Draft → Update. The self-embed is now inert.
- Open it with Elementor. It loads normally now — no crash — because the accordion skips the drafted target.
- Repoint the tab. Select the accordion → Content → expand the broken tab → Choose Template → pick the correct content template instead of the section itself.
- Publish. One click restores the template to published and saves the fix. Reload the page — it’s back.
▼ change to ▼
Don’t fix it by raising WP_MEMORY_LIMIT. No limit survives infinite recursion — you’d just make each crash slower and heavier. And don’t fix it by deleting the widget in a panic: the content in those tabs is fine; only one dropdown value is wrong.
06How to recognize this bug in the wild
- One page fatals, the rest of the site is fine — the loop lives in that page’s content.
- The log shows memory exhaustion at a generous limit (512 MB–1 GB) with the crash location drifting between core Elementor files on each load.
- The Elementor editor also crashes or hangs when opening one specific template or page.
- It started right after someone edited a template — check Last Modified dates in the template library, then export the templates and search the JSON for a template ID that references itself (directly, or A → B → A through a chain).
07Takeaways
For site owners: when an accordion, tab, flip box, or popup asks you to “choose a template,” never pick the template you’re currently editing — and be careful with families of templates that share a name prefix. If a page dies right after a template edit, suspect the edit, not your plugins.
For plugin developers: any widget that renders a saved template should carry a recursion guard. Keep a static stack of template IDs currently being rendered; if the requested ID is already on the stack, bail out and render nothing (or an editor-only warning) instead of recursing. It’s a ten-line fix that turns a white-screen outage into a harmless empty box. That guard is now on our upstream list.
Total damage: one mis-clicked dropdown. Total cost: a full page outage and a debugging session spanning server logs, plugin bisection, and a template-export archaeology dig. The best bugs are the ones where the fix is one click — once you know which click.
