Fixed: Elementor 4.3.0 and 4.3.1 critical error with Elementor Pro: "Depending on a hidden experiment is not allowed"

Updated September 25, 2026: Elementor 4.3.2 fixes this. Released on September 24, it changes the check so a feature that depends on a hidden experiment no longer stops the page loading. We reproduced the error on a test site running 4.3.1, updated to 4.3.2, and the site loaded normally. The quickest fix is to update Elementor to 4.3.2, and you don't need an active Pro licence to do it. If your site is already down, see how to fix it below for getting the update on while wp-admin is broken.

Updated September 24, 2026: Elementor 4.3.1 is out, and it doesn't fix this. We compared the 4.3.0 and 4.3.1 code: the check that throws the error and the hidden setting on nested-elements are unchanged, and the 4.3.1 changelog lists one fix, for translations in the admin top bar. Sites on 4.3.1 with Elementor Pro 3.11 to 3.32 get the same critical error.

If your WordPress site went down overnight and it runs Elementor, check your plugins page for Elementor 4.3.0, or 4.3.1, which has the same problem. Elementor released 4.3.0 on September 22, 2026, and sites with WordPress's built-in auto-updates switched on for Elementor installed it without anyone touching them. If the site also runs an older Elementor Pro (3.11.x through 3.32.x), every page now fails with "Depending on a hidden experiment is not allowed" in the PHP error log.

We saw this on sites we host on September 23 and traced it through the PHP error logs and the plugin source. Here's the exact error, how to get back online, and what changed in 4.3.0.

The error: "Depending on a hidden experiment is not allowed"

Visitors see WordPress's generic critical error page, and the server returns HTTP 500:

There has been a critical error on this website.

Your PHP error log shows this on every 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

With this stack trace (paths shortened):

#0 /wp-content/plugins/elementor/core/experiments/manager.php(88): Elementor\Core\Experiments\Manager->initialize_feature_dependencies()
#1 /wp-content/plugins/elementor-pro/core/modules-manager.php(91): Elementor\Core\Experiments\Manager->add_feature()
#2 /wp-content/plugins/elementor-pro/plugin.php(372): ElementorPro\Core\Modules_Manager->__construct()

The exception is thrown inside the free Elementor plugin (elementor/core/experiments/manager.php), but the call comes from Elementor Pro (elementor-pro/core/modules-manager.php). The fault sits in how the two versions work together, so you need to look at both.

Are you affected?

You're affected if both of these are true:

• Elementor 4.3.0 or 4.3.1 (the free plugin) is installed and active.
• Elementor Pro 3.11.x to 3.32.x is installed and active. The Menu (mega menu) module first appears in the 3.11 releases. We confirmed the problem in versions from 3.11.1 to 3.28.1.

You're not affected by this error if:

• You run Elementor Pro 3.33.0 or later. We checked 3.33.0, 3.33.1, 3.33.2, 3.34.0, and 3.35.1.
• You run Elementor Pro 3.10 or earlier. Those versions don't have the Menu (mega menu) module, so there's nothing to trip the check. We checked 3.5.2, and 3.6.2 through 3.10.3.
• You run Elementor 4.3.2 or later.
• You run the free Elementor without Pro.

You don't have to have switched anything on to hit this. The check that fails runs before Elementor looks at whether the feature is enabled, so a site that has never used the mega menu breaks the same way.

How to fix it

Updating Elementor to 4.3.2 is the simplest fix and works whether or not your Pro licence is active. The other two options were the only fixes before 4.3.2 came out.

Option 1: Update Elementor to 4.3.2 or later

If wp-admin is working, update Elementor from the Plugins screen as normal.

If the site is down, wp-admin is down with it, and a plain wp plugin update elementor fails too, because WP-CLI loads the same broken code. Tell WP-CLI to skip Pro while it updates:

wp plugin update elementor --skip-plugins=elementor-pro

Without WP-CLI, download 4.3.2 from WordPress.org (https://downloads.wordpress.org/plugin/elementor.4.3.2.zip) and replace the wp-content/plugins/elementor folder with the one from the zip over SFTP or your host's file manager.

Once you're on 4.3.2, you can leave Elementor's auto-updates on.

Option 2: Update Elementor Pro to 3.33 or later

If your Pro licence is active, update Elementor Pro to 3.33.0 or later. In those versions the Menu module no longer depends on the hidden experiment, so Pro loads cleanly alongside Elementor 4.3.0 and 4.3.1. It's worth doing even after you've updated Elementor.

Pro updates need an active licence. This is how a site with a lapsed licence ends up broken: Pro stops updating, the free Elementor keeps auto-updating from WordPress.org, and the two drift into this combination. If you can't renew right away, update Elementor to 4.3.2 (option 1).

Option 3: Roll Elementor back to 4.2.4 and pause its auto-updates

Now that 4.3.2 is out, you shouldn't need this. It's here for anyone who already rolled back. Elementor 4.2.4 is the last 4.2 release, and in 4.2.4 the experiment Pro depends on is still visible, so the check passes.

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

The first command downloads Elementor 4.2.4 from WordPress.org and writes it over the installed 4.3.0. --force is needed because Elementor is already installed, and the plugin stays active. The second takes Elementor off WordPress's auto-update list. --skip-plugins=elementor-pro keeps WP-CLI from loading the code that throws the exception. It applies only to that command and doesn't deactivate Pro.

If Elementor's auto-updates were already off, the second command prints Error: No plugin auto-updates disabled. That's harmless. It means there was nothing to change.

Without WP-CLI, download 4.2.4 from WordPress.org (https://downloads.wordpress.org/plugin/elementor.4.2.4.zip), then replace the wp-content/plugins/elementor folder with the one from the zip over SFTP or your host's file manager. Once the site loads again, go to Plugins in wp-admin and click Disable auto-updates next to Elementor.

If you rolled back to 4.2.4 earlier, you can now update straight to 4.3.2 and turn Elementor's auto-updates back on.

Locked out of wp-admin?

wp-admin fails with the same error, so you can't use the Plugins screen until the site is back. Over SFTP or your host's file manager, either:

• rename wp-content/plugins/elementor-pro (for example to elementor-pro.off) so WordPress treats Pro as deactivated, or
• replace the wp-content/plugins/elementor folder with the 4.3.2 copy described above.

Renaming Pro gets the site loading again, but anything built with Pro won't work until you reactivate it. Replacing the Elementor folder keeps Pro running. If you rename Pro to get into wp-admin, update Elementor to 4.3.2, then name Pro back.

On Wordify: use the WP-CLI or SFTP steps above over SSH or SFTP, or contact our support team and we'll help.

What changed in Elementor 4.3.0

Elementor ships some features as "experiments", which are feature flags that can be visible or hidden. Other features can declare that they depend on an experiment.

Elementor Pro's Menu module (the mega menu) declares a dependency on the experiment called nested-elements. In Elementor 4.2.4, nested-elements is a normal, visible experiment. In 4.3.0 it's marked as hidden.

Elementor's experiments manager doesn't allow a feature to depend on a hidden experiment. When Pro registers its Menu module, the manager checks the dependency, finds that nested-elements is hidden, and throws Dependency_Exception. Nothing catches it, so every request stops there.

Elementor Pro 3.33.0 changed the Menu module so it depends only on the container experiment. That's why 3.33 and later load cleanly on 4.3.0.

Elementor 4.3.1, released September 23, 2026, didn't change any of this code, so the same error occurred on 4.3.1.

Elementor 4.3.2, released September 24, 2026, changes the experiments manager instead. Where it used to throw Dependency_Exception, it now treats a hidden dependency as satisfied and carries on loading. When WordPress debugging is on, it logs a PHP notice saying the feature depends on a hidden experiment. The nested-elements experiment is still hidden in 4.3.2, so the fix is in the check itself.

What happened on Wordify

On Wordify, sites with Automated Safe Updates turned on don't take plugin updates blindly. Each update runs in four steps: we take a restore point and verify it, apply the update, load the site before and after and compare what comes back, and roll back automatically if the site fails that check.

Where Automated Safe Updates applied Elementor 4.3.0 to a site running an affected Elementor Pro, the site failed the health check, Wordify rolled it back to the version it was on before, and paused the 4.3.0 update. When 4.3.1 arrived with the same problem, the same thing happened again. Those customers didn't need to do anything.

Automated Safe Updates is switched on per site, and not every Wordify customer has it on. Sites without it, where WordPress's own auto-updater installed 4.3.0, did go down. Our monitoring flagged them and our support team began restoring them.

We still think auto-updates are the right default, because a site that waits for someone to find time for updates falls behind on security fixes. The risk is an update that nothing checks after it lands. Automated Safe Updates is on every Wordify plan at no extra cost. Here's how it works.

If your host leaves you fixing this over SFTP, we'll migrate your sites to Wordify for free, and you get a 100% money-back guarantee in your first month. See plans and pricing.

Common questions

Does Elementor 4.3.2 fix it?

Yes. Elementor 4.3.2, released September 24, 2026, changes the check so a feature that depends on a hidden experiment no longer stops the page loading. We reproduced the error on a test site running 4.3.1, updated to 4.3.2, and the site loaded normally. With WordPress debugging on, 4.3.2 logs a PHP notice about the hidden dependency instead.

Does Elementor 4.3.1 fix it?

No. We compared the 4.3.0 and 4.3.1 code: the check that throws the error and the hidden setting on nested-elements are unchanged. The 4.3.1 changelog lists one fix, for translations in the admin top bar. Sites on 4.3.1 with Elementor Pro 3.11 to 3.32 get the same critical error.

Is this a WordPress bug?

No. WordPress core isn't involved. The exception comes from Elementor's experiments manager when an older Elementor Pro registers its Menu module.

I never turned on the mega menu. Why is my site affected?

The dependency check runs when Pro registers the module, before Elementor looks at whether the feature is enabled. Having an affected Pro version active is enough.

Why didn't Elementor Pro update itself?

Pro updates come from Elementor and need an active licence. The free Elementor plugin updates from WordPress.org, so it keeps updating whether or not your Pro licence is current.

Can I stay on Elementor 4.3 and just deactivate Pro?

You can, but you don't need to. Update Elementor to 4.3.2 and Pro can stay active. With Pro switched off, anything built with Pro features won't work.

Does WP-CLI work on an affected site?

Add --skip-plugins=elementor-pro to your commands so WP-CLI doesn't load Pro. The rollback commands above include it.

More on this

• Automated Safe Updates, how Wordify tests each update and rolls it back if the site breaks.
• Fixed: WP Rocket fatal error after WordPress 7.1, the last time a routine update took sites down.

Sources

• Elementor on WordPress.org, version history and the 4.3.0 changelog (September 22, 2026)
• Elementor and Elementor Pro plugin source and PHP error logs, read on Wordify servers on September 23, 2026