Your site was fine last night. Nobody logged in, nobody changed anything, and this morning every page returns “There has been a critical error on this website.”
If the site runs Elementor, you can probably stop looking. Elementor 4.3.0 was released on September 22, 2026, and WordPress’s built-in auto-updates installed it overnight on a great many sites. If your Elementor Pro is an older version, the two can’t load together — and the site stops before it renders anything.
Below is how to get back online. If you’re in a hurry, read the next two sections and stop.
Rather not do this yourself? Get in touch — phone, email or live chat, whichever is fastest. WordPress repair covers exactly this kind of emergency.
Everyone else: start here.
First: confirm this is your problem
Two things have to be true.
Elementor (free) is on 4.3.0, 4.3.1 or 4.3.2, and Elementor Pro is on 3.32 or older. Don’t rule yourself out because you’re already on 4.3.2 — the later releases did not change the dependency check. If you updated to 4.3.2 hoping it would resolve this, you will see exactly the same exception.
Your PHP error log will say so plainly. Look for this on every single request:
PHP Fatal error: Uncaught Elementor\Core\Experiments\Exceptions\Dependency_Exception:
Depending on a hidden experiment is not allowed.
in /wp-content/plugins/elementor/core/experiments/manager.php:968
The stack trace shows the call arriving from elementor-pro/core/modules-manager.php. That’s the important detail: the error is thrown by the free plugin, but it’s triggered by Pro. Neither plugin is broken on its own. The combination is.
If you can’t reach your error log, the combination of “Elementor site” plus “500 error that appeared without anyone doing anything” is strong enough evidence to act on.
You are not affected if you’re on Elementor Pro 3.33.0 or later, on Pro 3.10 or earlier, or running the free Elementor without Pro.
Get back online
Two routes. Pick based on whether your Elementor Pro licence is active.
Option 1 — Update Elementor Pro to 3.33 or later
This is the proper fix. Pro 3.33.0 changed the Menu module so it no longer depends on the problematic experiment, and it loads cleanly alongside Elementor 4.3.
The catch is that Pro updates require an active licence. If yours has lapsed, this option isn’t available until you renew — which is precisely how most affected sites got here.
One caveat on version 3.33
Upgrading Elementor Pro to 3.33 clears this specific error, but it’s worth knowing where you stand with Elementor’s own support policy. Elementor supports eight major releases backwards, which on 4.3.0 puts the oldest supported Pro version at 3.35.0. Anything below that still runs — it just isn’t covered if something else breaks later. If your licence is active and you’re updating anyway, go to the current release rather than the minimum one that stops the bleeding.
Option 2 — Roll Elementor back to 4.2.4
If you can’t update Pro right now, go backwards instead. Elementor 4.2.4 is the last 4.2 release and works fine with older Pro versions.
With WP-CLI:
wp plugin install elementor --version=4.2.4 --force --skip-plugins=elementor-pro
wp plugin auto-updates disable elementor --skip-plugins=elementor-pro
--force is required because Elementor is already installed. --skip-plugins=elementor-pro stops WP-CLI from loading the code that throws the exception — it applies only to that command and doesn’t deactivate anything.
Without WP-CLI: download elementor.4.2.4.zip from WordPress.org, then replace the wp-content/plugins/elementor folder over SFTP or your host’s file manager. Once the site loads, go to Plugins in wp-admin and click Disable auto-updates next to Elementor.
That second step is not optional. Leave auto-updates off until Pro is on 3.33 or later. Turn them back on too early and WordPress reinstalls the latest release, and the site goes down again.
If rolling back to 4.2.4 isn’t enough
A small number of sites have stayed down after rolling back, and only came up again on 4.2.3. It’s an edge case rather than the rule, but if 4.2.4 leaves you with the same white screen, step back one more release before assuming the problem lies elsewhere. Rollback remains the reliable path here — occasionally it just needs to go one version deeper.
Locked out of wp-admin entirely?
wp-admin fails with the same fatal error, so you can’t use the Plugins screen. Over SFTP:
Either rename wp-content/plugins/elementor-pro to something else — elementor-pro.off works. WordPress treats a renamed folder as deactivated, the site loads again, and you can work from wp-admin. Anything built with Pro features won’t render until you rename it back.
Or replace the wp-content/plugins/elementor folder with the 4.2.4 copy. This keeps Pro running and is the better option if the site is public and you can’t afford broken layouts.
If you rename Pro to get in, remember to rename it back once Elementor is on 4.2.4 or Pro has been updated.
What actually went wrong
Worth understanding, because the mechanism explains why nothing you did caused it.
Elementor ships certain features as “experiments” — feature flags that can be visible or hidden. Other features can declare a dependency on an experiment.
Elementor Pro’s Menu module — the mega menu — declares a dependency on an experiment called nested-elements. In Elementor 4.2.4 that experiment is visible and everything is fine. In 4.3.0 it was marked as hidden.
Elementor’s experiments manager doesn’t permit a feature to depend on a hidden experiment. So when Pro registers its Menu module, the manager checks the dependency, finds the experiment hidden, and throws a Dependency_Exception. Nothing catches it. Every request dies there — front end and admin alike.
Two things make this worse than it needed to be.
You don’t have to use the mega menu. The dependency check runs when Pro registers the module, before Elementor ever checks whether the feature is enabled. A site that has never touched the mega menu breaks identically.
4.3.1 didn’t fix it. Released September 23, its changelog lists a single fix for admin top bar translations. Wordify compared the 4.3.0 and 4.3.1 code and found the failing check and the hidden flag both unchanged.
4.3.2 didn’t fix it either. Released September 24, its changelog mentions improved update stability between Elementor Core and Pro, along with a security fix. It does not change the dependency check that causes this error — sites on 4.3.2 running an older Pro fail exactly the same way. Updating forward is not the fix here. Getting Pro to 3.33 or later is.
Why this happened to you specifically
There’s a pattern here, and it’s worth naming because it’s extremely common.
The free Elementor plugin updates from WordPress.org. WordPress’s built-in auto-updater handles it, and for most people that’s switched on and forgotten about.
Elementor Pro updates from Elementor’s own servers, and it requires an active licence. When a licence lapses — the card expired, the renewal email went to someone who left, nobody noticed — Pro simply stops updating.
From that moment the two halves of the same product drift apart. One keeps moving, the other is frozen. It works for months. Then one release changes something the frozen half depends on, and the site goes down at three in the morning without anyone touching it.
This is the failure mode we described in why WordPress sites break when you update them: the risk isn’t in any single update, it’s in the gap between components that are supposed to move together.
Is auto-updating the problem?
The tempting conclusion is to switch auto-updates off entirely. Don’t.
A site that only updates when someone remembers is a site that eventually sits unpatched through a security release. WordPress shipped two of those in five days this month — one of them a critical unauthenticated RCE. Manual updating doesn’t reduce risk; it moves it somewhere less visible.
The actual problem isn’t that the update was automatic. It’s that nothing checked the site afterwards.
An update that runs at 3am on a live site with no health check and no restore point is a coin flip you’re not present for. The same update applied to a staging copy first, tested, then deployed with a rollback path ready, is just maintenance.
Three things to do once you’re back up
Check every premium plugin licence. Elementor Pro, your theme, ACF Pro, WooCommerce extensions. Any lapsed licence is a component that has quietly stopped updating and is drifting out of sync with everything around it.
Read your PHP error log even when the site looks fine. Version mismatches often produce warnings long before they produce fatals. There have also been reports of Attempt to read property 'ID' on null in elementor/core/base/document.php on mismatched installs — a warning, not a crash, but a signal.
Decide who checks the site after an update runs. That’s the whole issue. Not whether to update, but whether anyone looks afterwards.
The short version
Elementor 4.3.0 marked the nested-elements experiment as hidden. Elementor Pro 3.11 through 3.32 still depends on it, so Pro throws a Dependency_Exception that nothing catches, and every request returns a 500. You don’t need to have used the mega menu. Neither 4.3.1 nor 4.3.2 fixes it.
Update Elementor Pro to 3.33 or later if your licence is active. If it isn’t, roll Elementor back to 4.2.4 and disable auto-updates for it until Pro is current. If you’re locked out of wp-admin, rename the elementor-pro folder over SFTP to get back in.
Then check your other premium licences, because this will happen again with a different plugin.
Site down right now? Get in touch — phone, email or live chat. WordPress repair is what we do.
Want this handled before it happens? Our WordPress Maintenance package is $69/month, fixed — every update staged and tested before it reaches your live site, licences monitored, offsite backups, and a rollback path that already exists when you need it. For WooCommerce stores it’s $89/month, including test transactions through your real payment gateways.
The sites that stayed up through this week weren’t lucky. They just had someone checking.
WPerizo.com — WordPress & WooCommerce. Nothing else. 🦔
