Elementor Popup “Publish Settings / Display Conditions” Not Loading: Cause and Fix

In this article, we will cover the most random issue that can occur, but can cause a lot of trouble without knowing how to fix.

For example, a site that has used Elementor popups for a while without trouble suddenly refuses to show the “Publish Settings” or “Display Conditions” panel. You click “Publish” or “Update” in the Elementor editor, the modal window appears, but the body of the window stays blank and just shows a loading spinner. You cannot change where the popup shows or what conditions it uses, so the popup becomes very hard to manage.

This problem has been seen on sites running either Elementor Pro or PRO Elements. The popup template itself is not usually the issue. The failure happens inside the editor JavaScript.

How the problem shows up

The editor symptom is always the same. In the Elementor editor for a popup:

1. You click “Publish” or “Update”.
2. You open “Publish Settings” or “Display Conditions”.
3. The modal opens, but the content area never loads.
4. The spinner stays visible and the conditions interface never appears.

If you inspect the DOM, you will usually see an element like this:

<div id="elementor-publish__modal" class="dialog-widget dialog-lightbox-widget">
    <div class="dialog-widget-content">
        <div class="dialog-message">
            <div class="dialog-content">
                <div id="elementor-publish">
                    <div id="elementor-publish__screen" class="elementor-templates-modal__content"></div>
                </div>
            </div>
            <div class="dialog-loading dialog-lightbox-loading"></div>
        </div>
    </div>
</div>

The important detail is that #elementor-publish__screen is completely empty, even though the modal is open.

What is actually breaking

The reason the modal body is empty is that a JavaScript error is stopping Elementor’s editor from finishing the render of the “Publish Settings” tab. On many sites using Elementor Pro or PRO Elements, the browser console shows the same error:

Uncaught (in promise) ReferenceError: sprintf is not defined

The stack trace usually points into one of the “Pro layer” editor scripts, for example:

• /wp-content/plugins/elementor-pro/assets/js/editor.min.js
• /wp-content/plugins/pro-elements/assets/js/editor.min.js

This means the Pro layer (Elementor Pro or PRO Elements) expects a function named sprintf to exist as a global, but in the current environment that function is missing. Once that ReferenceError is thrown, the rest of the code that should populate #elementor-publish__screen does not run. The result is a modal that opens but never shows the conditions UI.

Often this appears after an update of WordPress, Elementor core, Elementor Pro or PRO Elements, or some combination of those. One typical pattern is:

• Elementor core is on a newer version.
• Elementor Pro or PRO Elements is on a slightly different version line.
• The Pro script still calls sprintf, but the global sprintf helper it counted on no longer exists.

The same pattern can also show up when core and Pro are technically on matching version numbers, but an internal dependency changed and the Pro script was not fully updated for it yet.

How to confirm this is the issue on your site

If you want to verify that this is the problem you are seeing, open the popup in Elementor, then open your browser’s developer tools and switch to the Console tab. Next, click “Publish” or “Update” and then open “Publish Settings” or “Display Conditions”.

If you see a message like this:

Uncaught (in promise) ReferenceError: sprintf is not defined
    at editor.min.js:...
    at web-cli.min.js:...

and the Publish Settings window stays empty, then you are dealing with this exact error. It does not matter whether the Pro layer is Elementor Pro or PRO Elements. The core idea is the same: a Pro editor script expects sprintf, does not find it, throws an error, and the conditions panel never renders.

General steps before applying a code fix

The first thing to try on any Elementor site is to make sure versions are synced and caches are not interfering:

• Confirm that Elementor core and the Pro layer (Elementor Pro or PRO Elements) are on compatible versions and not stuck on a mismatched pair.
• Regenerate Elementor CSS and data from Elementor → Tools → General.
• Temporarily disable caching and optimization plugins that rewrite JavaScript.
• Test the editor again.

If all of that is already done and you still see the sprintf is not defined error with the blank Publish Settings window, then the simplest way to restore the editor is to add a small compatibility shim that defines window.sprintf in the editor context.

A small compatibility shim for Elementor editor

The idea of the fix is to define window.sprintf only inside the Elementor editor so the Pro script can call it without error. When WordPress’s wp.i18n.sprintf exists, we map that to window.sprintf. When it does not exist, we provide a simple fallback that returns the template string unchanged. This is enough to prevent the ReferenceError and let the rest of the editor logic run.

Add the following snippet to your child theme’s functions.php file or via a “Code Snippets” plugin. The code is complete as written.

<?php
/**
 * Temporary compatibility fix for "sprintf is not defined" errors
 * in the Elementor editor when using Elementor Pro or PRO Elements.
 *
 * This defines window.sprintf in the editor context so that Pro editor
 * scripts do not crash when opening Publish Settings or Display Conditions.
 */

add_action( 'elementor/editor/after_enqueue_scripts', function() {
	?>
	<script type="text/javascript">
		(function() {
			try {
				// If a global sprintf is missing, define it for the editor.
				if (typeof window.sprintf === 'undefined') {
					// Prefer WordPress' i18n sprintf if available.
					if (window.wp && wp.i18n && typeof wp.i18n.sprintf === 'function') {
						window.sprintf = wp.i18n.sprintf;
					} else {
						// Fallback: very simple implementation that returns the template.
						window.sprintf = function(template) {
							return template || '';
						};
					}
				}
			} catch (e) {
				// Fail silently to avoid breaking the editor if something unexpected happens.
			}
		})();
	</script>
	<?php
});

This hook uses elementor/editor/after_enqueue_scripts, so it runs only inside the Elementor editor, not on the public front end. It does not modify your layouts, your popup templates, or the markup that visitors see. Its only purpose is to make sure that when Pro editor scripts call sprintf, that function actually exists.

How to apply and test the fix

To use the shim:

1. Add the code above to your child theme functions.php file or create a new snippet with exactly this code in a snippets plugin.
2. Save the file or activate the snippet.
3. Clear any page cache or server cache if you have one.
4. Open your popup in Elementor again.
5. Click “Publish” or “Update”, then open “Publish Settings” or “Display Conditions”.

If this was your issue, the console error about sprintf should disappear and the conditions UI should load again as normal.

Reversibility and long term plan

This fix is fully reversible. If you decide later that you no longer need it, you can simply remove the snippet from functions.php or deactivate/delete the snippet in your snippets plugin. There is nothing to roll back in the database and no permanent configuration change. Once the code is gone, the site behaves exactly as it did before you added it.

In the long run, the best solution is always a proper update from the plugin authors so the Pro editor scripts no longer rely on a missing global and are fully in sync with the current Elementor core and WordPress environment. Until that update arrives, this small shim restores access to the Publish Settings and Display Conditions panels so you can continue working with your popups without interruption, whether you are using Elementor Pro or PRO Elements as your Pro layer.