WordPress 7.0 Gutenberg Editor Is Blank? Here’s the One-Snippet Fix for the isSavingPost Error

TL;DR: WordPress 7.0 changed when the core/editor data store gets registered. Several popular plugins — Kadence Blocks and Rank Math among them — call wp.data.select('core/editor').isSavingPost() inside subscribe callbacks without null-checking. Those callbacks now fire before the store exists, throw a TypeError, and prevent Gutenberg from finishing initialization. Your block editor renders as a blank white area. Drop the PHP snippet at the bottom of this post into Code Snippets (or your favorite custom-code plugin) and the editor comes back.

The symptom

You update to WordPress 7.0. You go to edit a post or page. The screen loads, the admin sidebar shows up, but the editor area itself is just empty whitespace. No blocks, no toolbar, no sidebar. Maybe you see a flash of UI and then nothing. Saving via “Quick Edit” still works, and the front end of the site is fine — but the block editor is dead.

If you open your browser’s developer console, you find an error like this:

TypeError: Cannot read properties of undefined (reading 'isSavingPost')
    at .../kadence-blocks/dist/post-saved-event.js
    at .../wp-includes/js/dist/data.min.js

Or this one:

TypeError: Cannot read properties of undefined (reading 'isAutosavingPost')
    at .../seo-by-rank-math/assets/admin/js/gutenberg.js
    at .../wp-includes/js/dist/data.min.js

You may see both, repeating in a loop. The exact file names will depend on which plugins you have installed, but the pattern is the same: undefined followed by isSavingPost or isAutosavingPost, and the stack trace leads into wp-data subscribe and emit calls.

If you’ve landed here by pasting one of those error strings into Google, you’re in the right place.

What’s actually broken

The block editor stores its state in WordPress’s data layer at wp.data. Plugins that want to know when a post is being saved — to fire analytics, refresh schema markup, push notifications, whatever — subscribe to that store and check the editor state on every change:

wp.data.subscribe(function () {
    var editor = wp.data.select('core/editor');
    if (editor.isSavingPost() && !editor.isAutosavingPost()) {
        // do the thing
    }
});

Notice what that code assumes: that wp.data.select('core/editor') always returns something. For years it has, because the core/editor store was registered very early in the editor bootstrap, before any subscriber could possibly fire.

WordPress 7.0 changed the bootstrap order. The core/editor store still gets registered, but slightly later than before. In the brief window between “subscribers start firing” and “store is registered,” any subscriber that calls select('core/editor') gets back undefined. Then .isSavingPost() throws a TypeError on undefined, and the error bubbles up through the subscribe loop.

That alone wouldn’t necessarily break the editor — errors in subscribe callbacks are usually swallowed. But because the error happens inside the data layer’s emit loop during initial editor mount, it interrupts the mount process. The wp.editPost package never finishes setting itself up, and you’re left with an empty #editor div.

Why this hits Kadence and Rank Math specifically

Both plugins have the same code pattern: subscribe to wp.data, call select('core/editor').isSavingPost() (or isAutosavingPost()), do something with the result. Neither null-checks the return value of select(). Other plugins that use the same pattern will exhibit the same crash on WP 7.0 until their authors ship null-safe versions.

This is not really Kadence’s fault or Rank Math’s fault. The code worked correctly against every previous version of WordPress. The fault, if there is one, is shared between WordPress (for changing init order without a heads-up) and plugin authors (for not defensively coding around an undefined return value). Either side could fix it. In the meantime, your editor is broken.

The fix

The clean fix would be: wait for Kadence and Rank Math to ship updates. The pragmatic fix is to patch the root cause yourself, in one place, for all affected plugins at once.

We do that by wrapping wp.data.select with a tiny shim that returns a safe stub object when core/editor is queried before it’s ready. The stub answers false to all the “is the post saving?” questions, which is the correct answer when there is no editor yet.

Here’s the snippet. Drop it into Code Snippets or any “add custom PHP” plugin and activate it.

// Workaround for WP 7.0 + plugin compatibility bug.
// Kadence Blocks 3.7.4, Rank Math 1.0.271.1, and possibly others call
// wp.data.select('core/editor').isSavingPost() inside wp.data.subscribe
// callbacks without null-checking. In WP 7.0 the core/editor store
// registers slightly later than these subscriber callbacks first fire,
// so they crash and prevent wp.editPost from mounting — leaving the
// Gutenberg editor blank.
//
// Fix: inject a JS shim right after wp-data loads. It wraps
// wp.data.select so that select('core/editor') returns a safe stub
// (all bool getters return false) until the real store is registered.
// Every plugin's subscribe callback then succeeds and Gutenberg can
// finish mounting.
//
// Safe to remove once Rank Math and Kadence ship null-safe fixes.

add_action('admin_enqueue_scripts', function () {
    $shim = <<<'JS'
(function () {
    if (!window.wp || !wp.data || !wp.data.select) return;
    var origSelect = wp.data.select;
    var safeStub = {
        isSavingPost:              function () { return false; },
        isAutosavingPost:          function () { return false; },
        didPostSaveRequestSucceed: function () { return false; },
        didPostSaveRequestFail:    function () { return false; },
        isCurrentPostPublished:    function () { return false; },
        getCurrentPostId:          function () { return 0; },
        getEditedPostAttribute:    function () { return undefined; },
        isEditedPostDirty:         function () { return false; }
    };
    wp.data.select = function (name) {
        var result = origSelect.apply(this, arguments);
        if (name === 'core/editor' && !result) return safeStub;
        return result;
    };
})();
JS;
    wp_add_inline_script('wp-data', $shim, 'after');
}, 1);

That’s the whole fix. Roughly fifteen lines of JavaScript wrapping one function.

How to apply it

If you don’t already have a code-snippet plugin:

1. Go to Plugins → Add New, search for Code Snippets, and install the one by Code Snippets Pro (it has millions of installs and is free).
2. Activate it.
3. Go to Snippets → Add New.
4. Title the snippet something memorable — “Fix WP 7.0 Gutenberg blank editor” works.
5. Paste the PHP block above into the code editor.
6. Click Save and Activate.
7. Reload your block editor. It should mount cleanly.

If you already use a different custom-code plugin (WPCode, Snippet Manager, a child theme functions.php, a must-use plugin), drop the same PHP wherever you normally drop PHP. There’s nothing fancy about the hook.

How to verify it worked

Open any post or page in the editor. You should see the full Gutenberg interface — toolbar, block canvas, settings sidebar — instead of a blank area. In your browser’s developer console, the isSavingPost and isAutosavingPost errors should be gone (or at least no longer repeating in a loop).

If your console still shows errors after the snippet is active, check:

• Is the snippet actually saved and activated? (The toggle in Code Snippets needs to be on.)
• Does the snippet’s “Location” allow it to run on admin pages? (For Code Snippets, “Run everywhere” or “Only run in admin area” both work.)
• Are you on WordPress 7.0+? (On older versions this snippet is harmless but unnecessary.)

When to remove it

This is a workaround, not a permanent solution. Pull the snippet (or just deactivate it) once both of these are true:

• Kadence Blocks ships a version that null-checks wp.data.select('core/editor') before calling methods on it. Watch their changelog.
• Rank Math ships the same fix in their Gutenberg integration. Watch their changelog.

If you’re using other plugins that exhibit the same crash, leave the snippet in place until they’re patched too. It costs essentially nothing to keep running — it adds about half a kilobyte of JavaScript to every admin page load and wraps one function call.

A note on the bigger picture

Major WordPress releases occasionally make breaking changes to internal APIs that plugins have been quietly relying on. When that happens, the visible damage is concentrated in plugins that didn’t write defensively. This isn’t unique to WP 7.0 — the same pattern played out with the block editor introduction in 5.0 and with widget block conversion in 5.8. The fix is almost always the same shape: patch the surface where the contract changed, then wait for plugins to catch up.

If you found this post because your site is broken right now and you needed it fixed before your client meeting in twenty minutes, good — that’s why we wrote it. If you’re a plugin developer looking at this, please add a null check on wp.data.select() returns. Future you, and a lot of WordPress users, will thank you.

Need help with a WordPress site that’s misbehaving after an update? Get in touch — we untangle this kind of thing for small businesses.