A client site I maintain is a live WooCommerce store built on a commercial theme, XStore, plus Elementor PRO. The job was clear: migrate it to a custom theme I wrote myself, lighter and easier to maintain. All product data, orders, and pages stay. Only the presentation layer changes. I tested the activation on staging first, and the moment I switched to my new theme, the homepage fell apart.
My new theme's header showed up on top, clean, matching the design. But below it, the body was still the old Elementor content: the hero video, the product sections, all styled by the old theme. Worse, XStore's off-canvas widgets (the cart, wishlist, and my-account dropdowns) piled on top of my new theme's content. It was not half-finished. It was two themes colliding on one page.
The symptom
My first reflex was cache. This store runs LiteSpeed plus Redis plus Cloudflare, so stale HTML lingering is plausible. I purged everything, hard refreshed, opened an incognito window. Same result. When a broken layout survives a layered cache purge, it is not cache. It is something deterministic, re-rendered on every request.
Second reflex: template files. I confirmed my new theme had a proper front-page.php and index.php. I checked the _wp_page_template meta on the homepage: it read front-page.php, exactly what I wanted. In theory WordPress should pick front-page.php from the active theme and render the body from there. But the Elementor body kept coming out. The WordPress template hierarchy was being ignored entirely.
That is where I stopped guessing and started reading how Elementor actually hooks into the render pipeline.
The root cause
It turned out two mechanisms were running independently, and neither of them cared which theme was active.
First, and the most maddening one: Elementor's per-page Page Layout setting is independent from the WP page template. Every page's Elementor panel has a Page Layout option, and this homepage was set to 'Elementor Full Width'. As long as that value is anything other than 'Default Template', Elementor does not care what _wp_page_template holds. It wraps the page in its own template:
wp-content/plugins/elementor/modules/page-templates/templates/header-footer.phpThat file takes over the body render, replacing whatever the active theme's template hierarchy would have produced. So my new theme's front-page.php existed and was valid, but Elementor intercepted first. Only the value 'Default Template' makes Elementor step back and let the WP template hierarchy run normally.
Second, those off-canvas widgets. XStore Core (the plugin folder et-core-plugin) injects its off-canvas HTML through the wp_footer hook, regardless of the active theme. My new theme had no CSS to hide or contain those widgets, so they rendered raw, stacked on top of the content.
Neither of these is a bug. Both are plugin features working exactly as designed. The wrong assumption was mine: I expected activating a new theme to cut off everything the old theme rendered. But Elementor and XStore live in the plugin layer, not the theme layer, so switching themes does not touch them at all.
The fix
Since the end goal was a clean break from XStore plus Elementor anyway, the cleanest fix was not a CSS hack but deactivating the plugins. Order matters. PRO Elements, the Elementor PRO add-on, has to be deactivated first, because it holds a dependency lock on Elementor core. Deactivating Elementor core while PRO Elements is still active can throw an error.
1. pro-elements/pro-elements.php (deactivate first, releases the dependency lock)
2. elementor/elementor.php (then Elementor core)
3. et-core-plugin/et-core-plugin.php (XStore Core, source of the off-canvas widgets)With those three off, purge the cache again explicitly: LiteSpeed, Redis, Cloudflare. Deactivation alone does not evict HTML that was already rendered into the cache. Then hard refresh, and the homepage finally renders purely from the new theme's front-page.php.
If the client turns out to want Elementor kept for some pages, there is a gentler workaround: open each page and set its Page Layout to 'Default Template' one by one. That hands render control back to the template hierarchy without deactivating anything. It is more tedious and manual, but valid when Elementor is still in use.
What made me comfortable running this on staging: the rollback is bulletproof. Reactivate the old theme plus those three plugins, and the Elementor data is still intact in the database. Deactivating a plugin deletes nothing; it just stops rendering. So the migration stays reversible up to the last minute.
Takeaways
- If you switch themes but the page body does not change, check Elementor's per-page Page Layout, not just
_wp_page_template. - The values 'Homepage' and 'Elementor Full Width' bypass the template hierarchy; only 'Default Template' lets the theme run.
- Elementor and XStore live in the plugin layer, not the theme. Switching themes does not touch them.
- Deactivate plugins in the right order: PRO Elements first, then Elementor core, then XStore Core.
- Deactivation alone is not enough: purge LiteSpeed, Redis, and Cloudflare, because old HTML is still cached.
- Plugin deactivation is reversible: the Elementor data stays in the DB, so rollback is just reactivating.