Please allow an option in "safe mode" to disable customer <script> to ensure the Elementor editor itself is not broken due to user error

[gregbenz]

Describe the Problem

It is awesome that the Elementor editor supports custom user <script>, including in the editing environment. However, this creates the risk that a user error can destabilize the Editor in such a way that the user cannot fix their mistake. As an example, a page with obfuscated JS using domain protection may render the Editor unusable if that page is copied to a staging domain.

Once that happens, you may get lucky and be able to roll back the page to the last revision (assuming the failure was recent and not co-mingled with other changes you wish to preserve). However, there are many cases where that easy path will not be available, in which case you may be forced to do things which are complicated / cumbersome (reproduce the page from scratch) or risky (direct manual editing of the underlying database).

==> Request: when "safe mode" is invoked in Elementor, disable any customer script in the editing environment to ensure that Elementor may still edit the page so the customer may fix/remove their problematic script.

Propose a Solution

Safe mode should make customer <script> inert to ensure the Elementor editor is able to edit, so that you can fix the issue.

Elementor could add a toggle next to the safe mode option called “disable user scripts” (or just make it part of the default or a third option in the safe mode dropdown).

When enabled, any user scripts (inline or custom blocks added via the global Elementor editor) would be rendered inert by adding type="elementor-disabled-safe-mode" to the <script> when in the editor in safe mode. This simple adaptation in the editing environment would prevent execution of the script, not show it as text on the page, and allow the user to edit and fix the problematic script.

Here's an example of how the original problem script would be rendered inert in safe mode under this proposal (no timeout is necessary for failure, but this would give you a few seconds if you wish to test this example. This example is derived from a real failure caused by obfuscated customer JS missing a dot in the domain protection, which was exposed a year later when working with Elementor in a staging domain):

<script type="elementor-disabled-safe-mode">
   setTimeout(() => {
    window.location.replace('about:blank');
  }, 5000);
</script>

Additional Context

No response

Agreement

• I confirm I have read and followed all the guidelines and instructions outlined in the Feature Request form.
• I agree that my discussion may be closed without further action if it doesn't meet all the requirements outlined in the Feature Request form.

[caleb-bright]

Good idea