|

Why One Page Freezes the WordPress Editor, and How to Find the Cause

ByJR Lopez

One page on a WordPress site I was working on had started freezing the block editor. The page would begin to load in the editor, then lock up, which meant nobody could make changes to it.

The usual advice for a problem like this is to deactivate your plugins one at a time until the problem goes away. In this case that advice would have pointed at the wrong thing. Here’s what was actually happening, how I found it, and the method I now use for any page that freezes the editor.

The short version

  • A page can freeze the WordPress editor even when the plugin behind an element isn’t at fault. The problem is how the visual editor interacts with that element on the page.
  • To diagnose it, switch to the Code editor just before the freeze happens, then remove elements one at a time until you find the one causing it.
  • In this case the cause was one of two Lottie animations on the page. Its connection to the animation file was corrupted, or the source file itself was bad. Deleting the block and recreating it with a new animation source fixed the freeze and kept the design intact.

Why “deactivate your plugins” can send you the wrong way

Deactivating plugins is a reasonable test when the whole editor is broken. When only one page freezes, it’s a blunt instrument. The plugin that provides an element is usually working fine on every other page that uses it. What breaks is the interaction between the visual editor and one specific instance of that element: its saved settings, its data or the file it points to.

Deactivating the plugin does make the freeze stop, because the editor no longer tries to render the element at all. That looks like proof the plugin is the problem. It isn’t. You’ve hidden the symptom, and you’ve also disabled a feature the rest of the site depends on. The real question is narrower: which element on this page is the editor choking on, and why?

Step 1: Get into the Code editor before the freeze

The visual editor freezes because it renders the blocks. The Code editor doesn’t render anything. It shows the page as raw block markup, so it stays responsive even when a block is the problem.

Timing matters. You have a short window after the page opens before the visual editor finishes rendering and locks up. Switch to the Code editor in that window:

  • Keyboard: Ctrl + Shift + Alt + M on Windows, or Cmd + Shift + Option + M on a Mac.
  • Menu: the three-dot Options menu at the top right of the editor, then Code editor.

The editor remembers your choice, so once you’re in Code view, reloading the page keeps you there. That gives you a stable place to work. Before changing anything, copy the full contents of the Code editor into a text file. That’s your rollback if something goes wrong.

Step 2: Eliminate elements one at a time

Now find the block responsible by process of elimination:

  1. Start with the most complex or unusual elements on the page: animations, embeds, sliders, galleries and anything that loads an external file.
  2. In the Code editor, remove one of those blocks. Each block starts with a comment like <!-- wp:plugin/block-name --> and ends with a matching closing comment, so you can cut the whole thing cleanly.
  3. Switch back to the visual editor and see whether the page still freezes.
  4. If it doesn’t, you’ve found the element. If it does, return to the Code editor, restore that block from your backup and try the next one.

Work on a staging copy if you have one, and don’t click Update while you’re testing. You’re diagnosing, not editing.

What it turned out to be

The page used two Lottie animations as part of its design. Lottie animations are lightweight vector animations, loaded from a separate file that the block points to.

Working through the elements narrowed the freeze down to one of the two animations. The other animation on the same page, served by the same plugin, worked normally. That ruled out the plugin as the cause. The problem was specific to that one block: its connection to the animation file was corrupted, or the source file itself was bad. Either way, the visual editor couldn’t render it and hung trying.

The fix: rebuild the element, don’t repair it

Once you know a block’s data or source is damaged, trying to patch its settings is rarely worth the time. The reliable fix was to:

  1. delete the faulty animation block entirely
  2. add a fresh animation block
  3. point it at a new animation source file
  4. recreate the settings so the page kept the same effect and design

The editor loaded normally afterward, and visitors saw the same design as before.

What to take from this

  • A page-specific problem usually has a page-specific cause. If one page freezes and others don’t, look at what’s unique to that page before you look at plugins.
  • The Code editor is your safe room. It lets you work on a page the visual editor can’t open.
  • Elements that load external files are prime suspects. Animations, embeds and media blocks depend on a file or connection that can break independently of the plugin.
  • Rebuild instead of repairing damaged elements. A fresh block with a clean source is faster and more reliable than editing broken settings.

There’s a business side to this too. A page nobody can edit is a page that slowly goes out of date, and for many organizations it’s an important one. The faster you can isolate the actual cause, the less you spend on guesswork, and the less you risk switching off features the rest of the site needs.

If a page on your site won’t open in the editor, or your WordPress site needs ongoing care, see how we approach WordPress development and maintenance or get in touch.