"Leave site? Changes you made may not be saved" on custom taxonomy pages after WP 5.6.1 update

[archon810]

Hi,

We use custom taxonomies extensively, and as of 5.6.1 today, every custom taxonomy page now prompts with "Leave site? Changes you made may not be saved." This has never happened before for custom taxonomies and is now quickly getting really annoying.

I don't see anything obvious in the changelog that would explain it ​https://wordpress.org/support/wordpress-version/version-5-6-1/, but perhaps this is an inadvertent bug related to another change?

P.S. 5.6.1 isn't available in Trac yet, so I'm forced to select 5.6 for now.

[Clorith]

#52442 was marked as a duplicate.

[Clorith]

Possibly related to r50031

[vladytimy]

#52446 was marked as a duplicate.

[davidbaumwald]

#52447 was marked as a duplicate.

[roger995]

Adding my text from duplicate #52447

"Do You Want to Leave This Site? Changes you made may not be saved" Alert notice on leaving updated pages (but not posts) after 5.6.1 update when using classic editor.

All plugins and PHP version up to date. No change when deactivating all plugins and changing theme. Site health status says "good." Goes away when Gutenberg is turned back on. Have read forum posts, but not seeing answer.

Code used for disabling Gutenberg:
add_filter('use_block_editor_for_post', 'return_false', 10);

Thanks

[audrasjb]

Hi there,

I can confirm I am able to reproduce the issue on 5.6.1.

It may be related to changeset [50031].

[audrasjb]

Video capture of the issue

[audrasjb]

Issue is fixed after 50031 is reverted

[audrasjb]

I can confirm it's related to [50031]. I reverted the commit locally and the issue disappeared.

[audrasjb]

Replace empty default value with undefined to avoid false negative in initialCompareData comparison

[audrasjb]

52440.diff fixes the issue on my side.
This first patch is based on the exploration made by @dbtedg in #52450.

[Clorith]

I don't think we should use the classification of undefined here, instead we should confirm that a selector exists before trying to use it in the first place, this would probably make the patch slightly more involved though.

[audrasjb]

#52450 was marked as a duplicate.

[Clorith]

The better approach here (sorry, should've mentioned in my initial reply), is likely to check that an element exists before trying to get its value for a comparison, if the element does not exist it doesn't need the comparison check to trigger at all.

This check would likely just need to live alongside line 713 and 724 in autosave.js, see if the selector exists before trying to compare against it.

My main concern with 52440.diff​ was that manually declaring it as undefined may have unexpected side-effects elsewhere in this file.

[codeiq]

+1 on this issue, it is happening on a custom post type page.

6.5.1

[davidbaumwald]

#52453 was marked as a duplicate.

[worldedu]

I am a bit of a dumbo so is there a simple fix like post a new autosave page?

[archon810]

I tried https://core.trac.wordpress.org/attachment/ticket/52440/52440.diff on the same site I've originally reported the issue with (with custom taxonomies), and it didn't fix the issue. I made sure to clear the Cloudflare cache and overwrite the .min file, and that the patched version is loading live correctly, yet the prompt still appears.

[hwk-fr]

Hey everyone!

Found a solution which works with all Post Types:

• Post
• Page
• CPT with Editor
• CPT without Editor

Video showcase: ​https://i.imgur.com/qpMYVc0.mp4

Here is the fix for core developers:

In the file \wp-includes\js\autosave.js. Replace the line Line 713 with:

if ( ( $( '#' + field ).val() || '' ) !== initialCompareData[ field ] ) {

In the file \wp-includes\js\autosave.js. Replace the line Line 724 with:

if ( ( $( '#title' ).val() || '' ) !== initialCompareData.post_title ) {

This will meet the requirements of initialCompareData and fix the issue in all post types.

For webmasters, here is a fix you can apply while waiting for the official patch.
Copy paste the following code in your theme's functions.php file:

<?php
/*
 * WordPress 5.6.1: Window Unload Error Fix
 */
add_action('admin_print_footer_scripts', 'wp_561_window_unload_error_fix');
function wp_561_window_unload_error_fix(){
    ?>
    <script>
    jQuery(document).ready(function($){
        
        // Check screen
        if(typeof window.wp.autosave === 'undefined')
            return;
        
        // Data Hack
        var initialCompareData = {
            post_title: $( '#title' ).val() || '',
            content: $( '#content' ).val() || '',
            excerpt: $( '#excerpt' ).val() || ''
        };

        var initialCompareString = window.wp.autosave.getCompareString(initialCompareData);

        // Fixed postChanged()
        window.wp.autosave.server.postChanged = function(){

            var changed = false;

            // If there are TinyMCE instances, loop through them.
            if ( window.tinymce ) {
                window.tinymce.each( [ 'content', 'excerpt' ], function( field ) {
                    var editor = window.tinymce.get( field );

                    if ( ! editor || editor.isHidden() ) {
                        if ( ( $( '#' + field ).val() || '' ) !== initialCompareData[ field ] ) {
                            changed = true;
                            // Break.
                            return false;
                        }
                    } else if ( editor.isDirty() ) {
                        changed = true;
                        return false;
                    }
                } );

                if ( ( $( '#title' ).val() || '' ) !== initialCompareData.post_title ) {
                    changed = true;
                }

                return changed;
            }

            return window.wp.autosave.getCompareString() !== initialCompareString;

        }
    });
    </script>
    <?php
}

Hope it helps!

Have a nice day.

Regards.

Trac ticket: https://core.trac.wordpress.org/ticket/52440

[mukesh27]

​PR #978 added as per @hwk-fr solution.

[Clorith]

Replying to mukesh27:

​PR #978 added as per @hwk-fr solution.

This looks like a much cleaner approach, checks that the element exists, if not uses an empty string as fallback; 👍 from me

[bartosz777]

@hwk-fr solution works for me. Thank you, sir. I changed those two lines in the code. However, I also had to minify autosave.js and paste the new code into autosave.min.js, since that's the file being used by WP.

[viablethought]

@hwk-fr solution does remove the prompt while leaving after saving on Pages, Posts, and CPT's however, it is removing the prompt entirely, even when you navigate away from a modified page without saving.

[hwk-fr]

@viablethought Did you mean "however, it is removing the prompt entirely" or "however, it is NOT removing the prompt entirely"?

The prompt when leaving a modified page is a feature, not a bug. At least that's what I guess.

[viablethought]

@hwk-fr meaning "however, it is removing the prompt entirely" - if I add new content to a page and don't save it, then navigate away from the page, there is no notification stating that something wasn't saved, which I believe the same prompt was showing when that happened.

[hwk-fr]

@viablethought I also get this, the prompt doesn't appear if I edit the content and leave the page quickly.

It looks like the whole autosave.js script has some issues to retrieve and compare the value in the edit.isHidden() and editor.isDirty() part. Ths script needs some times to correctly initialize. If the user change the content too quickly, the script doesn't take it in account.

It only happens when editing only the content. When changing title or excerpt it always work.

Here is a video showing this behavior: https://core.trac.wordpress.org/raw-attachment/ticket/52440/2021-02-05_17h20_03.mp4

---

Update: It looks like the user has to wait for TinyMCE to entirely load before making a change, otherwise the script doesn't take his change into account. A good visual hint is the dropshadow of toolbar which dispear once the editor is correctly initialized. See screenshot: ​https://i.imgur.com/iE4QrRy.jpg

Anything changed in the content before that dropdhadow disappear won't be taken into account and thus not trigger the prompt. See specific video: https://core.trac.wordpress.org/raw-attachment/ticket/52440/2021-02-05_17h33_40.mp4

Note that behavior can also be seen in the original 5.6.1 code, in the post type "Post" and Woocommerce "Product", without my fix.

[hwk-fr]

WordPress 5.6.1: Original Behavior

[hwk-fr]

Final Fix

[hwk-fr]

This new version include a fix for an another issue and may not be working as it wasn't fully tested. Please refer to the original version for a fully functional fix. See comment:18

---

After @viablethought report of early value validation problem before TinyMCE initialization, also present in the original 5.6.1 version, (See comment:27), I enhanced the original fix:

• Video: WordPress 5.6.1 Original Behavior
• Video: Final Fix Behavior

For Core developers: In the file wp-includes/js/autosave.js:709, rewrite the window.tinymce.each loop to:

window.tinymce.each( [ 'content', 'excerpt' ], function( field ) {
    var editor = window.tinymce.get( field );

    if ( ( editor && editor.isDirty() ) || ( $( '#' + field ).val() || '' ) !== initialCompareData[ field ] ) {
        changed = true;
        return false;
    }

} );

if ( ( $( '#title' ).val() || '' ) !== initialCompareData.post_title ) {
    changed = true;
}

For Webmasters: Here is the Standalone Fix. In the functions.php file, add the following code.

<?php
/*
 * WordPress 5.6.1: Window Unload Error Final Fix
 */
add_action('admin_print_footer_scripts', 'wp_561_window_unload_error_final_fix');
function wp_561_window_unload_error_final_fix(){
    ?>
    <script>
        jQuery(document).ready(function($){

            // Check screen
            if(typeof window.wp.autosave === 'undefined')
                return;

            // Data Hack
            var initialCompareData = {
                post_title: $( '#title' ).val() || '',
                content: $( '#content' ).val() || '',
                excerpt: $( '#excerpt' ).val() || ''
            };

            var initialCompareString = window.wp.autosave.getCompareString(initialCompareData);

            // Fixed postChanged()
            window.wp.autosave.server.postChanged = function(){

                var changed = false;

                // If there are TinyMCE instances, loop through them.
                if ( window.tinymce ) {
                    window.tinymce.each( [ 'content', 'excerpt' ], function( field ) {
                        var editor = window.tinymce.get( field );

                        if ( ( editor && editor.isDirty() ) || ( $( '#' + field ).val() || '' ) !== initialCompareData[ field ] ) {
                            changed = true;
                            return false;
                        }

                    } );

                    if ( ( $( '#title' ).val() || '' ) !== initialCompareData.post_title ) {
                        changed = true;
                    }

                    return changed;
                }

                return window.wp.autosave.getCompareString() !== initialCompareString;

            }
        });
    </script>
    <?php
}

Hope it helps!

Regards.

[viablethought]

@hwk-fr The updated fix works perfectly, much better. Thank you!

[Clorith]

#52456 was marked as a duplicate.

[Clorith]

I'm just going to step in and say that this should be scoped to restoring functionality as it was in 5.6.0, any further enhancements should ideally happen in a separate ticket with a different milestone.

This to ensure we do not introduce untested enhancements, this is key for a reasonably timed update to the issues as being experienced.

[archon810]

@hwk-fr I'm not clear if just the wp-includes/js/autosave.js fix is supposed to work by itself, because it didn't for me. However, after I added the functions.php part, then it stopped prompting. Is that expected?

[hwk-fr]

Replying to archon810:

Yes, that's expected. The wp-includes/js/autosave.js file changes intructions are for core developers. WordPress websites use an another minified file wp-includes/js/autosave.min.js which is automatically generated on release.

This is why I also added a "Standalone Fix" using functions.php for webmasters. I would recommend to stick to it if you're not sure how those minified/unminified files work.

Replying to Clorith:

I agree, two fixes merged into one isn't ideal. If you prefer stick to the original fix, I guess it's fine. I just wanted to tackle down that report from @viablethought too :)

Regards.

[SergeyBiryukov]

Replying to Clorith:

Replying to mukesh27:

​PR #978 added as per @hwk-fr solution.

This looks like a much cleaner approach, checks that the element exists, if not uses an empty string as fallback; 👍 from me

Yeah, this does work as expected in my testing. Thanks @hwk-fr and @mukesh27!

Some notes on testing:

• Use the classic editor, either via the plugin or a filter:

  add_filter( 'use_block_editor_for_post_type', '__return_false' );
  

• Open a page for editing, wait for the editor to complete loading.
• Without making any changes, attempt to reload or navigate away from the page.
• You'll see the "Changes you made may not be saved" dialog.
• The issue only happens on Pages (as they don't have an Excerpt field by default), or any custom post types that don't have a Title, Content, or Excerpt field.
• The issue happens both in 5.7 trunk and 5.6.1.

[TimothyBlynJacobs]

#52459 was marked as a duplicate.

[SergeyBiryukov]

In 50232:

Editor: Correct the check for unsaved content in wp.autosave.server.postChanged().

This fixes improper triggering of the "Are you sure?" prompt when navigating away from the old, "classic" Edit Post screen and there are no changes.

The previous check did not account for Pages or any custom post types that don't have a Title, Content, or Excerpt field.

Follow-up to [50031].

Props hwk-fr, mukesh27, audrasjb, archon810, Clorith, ibiza69, tonysandwich, roger995, bartosz777, viablethought, dbtedg, worldedu, hmabpera, magnuswebdesign.
Fixes #52440.

[SergeyBiryukov]

Reopening for backporting to the 5.6 branch.

[SergeyBiryukov]

Replying to hwk-fr:

I agree, two fixes merged into one isn't ideal. If you prefer stick to the original fix, I guess it's fine. I just wanted to tackle down that other report from @viablethought too :)

Could you create a new ticket for the enhanced fix from comment:28? Thanks :)

[SergeyBiryukov]

#52398 was marked as a duplicate.

[hmabpera]

I used the Standalone Fix above from hwk-fr and it works perfectly.
I assume that the problem will be fixed in Word Press 5.6.2 when I can remove this code.

[archon810]

As you can see from my screenshot, I have copied autosave.js into autosave.min.js and dumped cache, but the prompt was still showing up.

In fact, I just tried the same with ​https://github.com/WordPress/wordpress-develop/pull/978, and I'm still observing the same pop-up on our site. Only the functions.php solution fixes it properly.

So, perhaps the proposed solution works for some, but not all cases? In our case, we add tinymce functionality to 5 elements on custom taxonomy pages, which may or may not be related to the bug. Otherwise, I'm not sure what else it could be.

Here's a screenshot showing the issue and the tweaked autosave.min.js code from PR 978:

Replying to hwk-fr:

Replying to archon810:

Yes, that's expected. The wp-includes/js/autosave.js file changes intructions are for core developers. WordPress websites use an another minified file wp-includes/js/autosave.min.js which is automatically generated on release.

This is why I also added a "Standalone Fix" using functions.php for webmasters. I would recommend to stick to it if you're not sure how those minified/unminified files work.

@SergeyBiryukov @mukesh27 Any ideas?

[SergeyBiryukov]

Replying to archon810:

So, perhaps the proposed solution works for some, but not all cases? In our case, we add tinymce functionality to 5 elements on custom taxonomy pages, which may or may not be related to the bug.

Could you share the code you're using to create those taxonomy pages and add that functionality? That might be helpful in further reproducing the issue.

[archon810]

Replying to SergeyBiryukov:

Could you share the code you're using to create those taxonomy pages and add that functionality? That might be helpful in further reproducing the issue.

Afraid the site code is private and too vast to share easily, but if I could provide you with some specific values or function results from Chrome dev tools, I'd be happy to.

Specifically, why would the autosave.js solution not work while the functions.php one does, and everything was working before 5.6.1? Perhaps you can see a corner case somewhere?

[khoulding]

The functions.php code worked for a staging site which is great. However I have many sites running the new version of WordPress 5.6.1. Does anyone here have an idea of how long this bug might take to fix as another update?

[hellofromTonya]

#52472 was marked as a duplicate.

[hwk-fr]

@archon810

First, I would not recommend to manually edit autosave.min.js. Instead, apply the fix to the original autosave.js file and enable define('SCRIPT_DEBUG', true) in the wp-config.php file to force WordPress to load unminified assets. See ​Debugging in WordPress.

Regarding your report, unfortunately you gave us too much little information. We won't be able to find the source of your problem without being able to reproduce it. I'm not even sure what "Custom Taxonomy Pages" means.

So there's two possible solutions here:

1. Try to find the problem:

• Do not use the "Standalone Fix" in functions.php
• Apply the fix to the JS file and use the unminified autosave.js
• Make sure the browser load the correct version by enabling the "Disable Cache" setting
• Check the browser console
• Check the Page post type, see how it behave
• Register a Test Custom Post Type, see how it behave
• If Page and Test Post Types are working fine, then compare it with your "Taxonomy Pages"
• Check the difference between your "Taxonomy Page" and other working Custom Post Types
• Try to reproduce the "Taxonomy Page" features & specifications on a working Custom Post Type. You said you manually add TinyMCE to 5 elements. Try to add them one by one, and reach the breaking point
• If you can't reach the breaking point, try to disable plugins/theme one by one
• Try to install a fresh WP install with the native theme
• Once you reach the breaking point, investigate it

2. Let us help you:

• Are Page & Test Custom Post Types working? Are you using a Custom Post Type?
• Explain us what do you mean by "Custom Taxonomy Pages"
• Explain and show us what do you mean by "Add TinyMCE to 5 elements"
• Did you use a plugin or a custom code?
• Show us screenshots of the UI, browser console etc... Others devs may see clues you don't see
• Show us some code which would let us reproduce the problem (custom code, custom enqueue)
• Ideally share a step-by-step guide or a standalone code so anyone can reproduce the problem easily (Just like I did with the functions.php code for the fix)

You probably know your own website/code very well, but we don't. We can't just look at the autosave.js file and say "Oh yeah, here is the problem", because the problem can come from anywhere, especially in an environment where external code may interfere (plugins/themes).

As a conclusion, I would say: help us to help you.

Regards.

[gwmbox]

Tested on several sites using the functions.php fix, but it does not work (for me).

Tested on 3 brand new WP test sites just to be sure

[davidbaumwald]

#52479 was marked as a duplicate.

[paaljoachim]

Moved over the comments from: #52398

Multiple comments in this Classic Editor support forum which report similar problems:
​https://wordpress.org/support/topic/save-popup-seen-even-in-page-with-no-changes-made/
I have though also seen it in a Gutenberg page/post. (I believe it has to do with WP 5.6.1)

[MadtownLems]

I ran into this problem on 5.6.1 with a Custom Post Type with no title, body, or excerpt (it's actually Guest Authors from Co-Authors Plus that gets the rich text editor added to the 'description' field though a custom snippet).

Manually applying the changes in 52440.diff to autosave.js (and using $script_debug) resolves it for me.

Please let me know if there's anything else I can do to move this along or help in any way!

[papijo]

Replying to hwk-fr:

This new version include a fix for an another issue and may not be working as it wasn't fully tested. Please refer to the original version for a fully functional fix. See comment:18

---

After @viablethought report of early value validation problem before TinyMCE initialization, also present in the original 5.6.1 version, (See comment:27), I enhanced the original fix:

• Video: WordPress 5.6.1 Original Behavior
• Video: Final Fix Behavior

For Core developers: In the file wp-includes/js/autosave.js:709, rewrite the window.tinymce.each loop to:

window.tinymce.each( [ 'content', 'excerpt' ], function( field ) {
    var editor = window.tinymce.get( field );

    if ( ( editor && editor.isDirty() ) || ( $( '#' + field ).val() || '' ) !== initialCompareData[ field ] ) {
        changed = true;
        return false;
    }

} );

if ( ( $( '#title' ).val() || '' ) !== initialCompareData.post_title ) {
    changed = true;
}

For Webmasters: Here is the Standalone Fix. In the functions.php file, add the following code.

<?php
/*
 * WordPress 5.6.1: Window Unload Error Final Fix
 */
add_action('admin_print_footer_scripts', 'wp_561_window_unload_error_final_fix');
function wp_561_window_unload_error_final_fix(){
    ?>
    <script>
        jQuery(document).ready(function($){

            // Check screen
            if(typeof window.wp.autosave === 'undefined')
                return;

            // Data Hack
            var initialCompareData = {
                post_title: $( '#title' ).val() || '',
                content: $( '#content' ).val() || '',
                excerpt: $( '#excerpt' ).val() || ''
            };

            var initialCompareString = window.wp.autosave.getCompareString(initialCompareData);

            // Fixed postChanged()
            window.wp.autosave.server.postChanged = function(){

                var changed = false;

                // If there are TinyMCE instances, loop through them.
                if ( window.tinymce ) {
                    window.tinymce.each( [ 'content', 'excerpt' ], function( field ) {
                        var editor = window.tinymce.get( field );

                        if ( ( editor && editor.isDirty() ) || ( $( '#' + field ).val() || '' ) !== initialCompareData[ field ] ) {
                            changed = true;
                            return false;
                        }

                    } );

                    if ( ( $( '#title' ).val() || '' ) !== initialCompareData.post_title ) {
                        changed = true;
                    }

                    return changed;
                }

                return window.wp.autosave.getCompareString() !== initialCompareString;

            }
        });
    </script>
    <?php
}

Hope it helps!

Regards.

[papijo]

The Standalone Fix for the functions.php file works fine for me. Thanks!

[desrosj]

5.6.2 RC will be packaged later today. It looks like [50232] has fixed the issue for a number of folks (including myself in my testing). Let's include that commit in 5.6.2, and see about identifying further scenarios as more testing information is identified.

Could you create a new ticket for the enhanced fix from comment:28? Thanks :)

There's also still an open request for a follow up ticket for a more complete fix. @hwk-fr are you able to open that?

[desrosj]

In 50366:

Editor: Correct the check for unsaved content in wp.autosave.server.postChanged().

This fixes improper triggering of the "Are you sure?" prompt when navigating away from the old, "classic" Edit Post screen and there are no changes.

The previous check did not account for Pages or any custom post types that don't have a Title, Content, or Excerpt field.

Follow-up to [50031].

Props hwk-fr, mukesh27, audrasjb, archon810, Clorith, ibiza69, tonysandwich, roger995, bartosz777, viablethought, dbtedg, worldedu, hmabpera, magnuswebdesign.
Merges [50232] to the 5.6 branch.
Fixes #52440.

[yacsha]

The problem is still presented in version 5.6.3 as seen in this video (​https://imgur.com/a/teO3WSA), which I explain below:

1. I use the classic editor in HTML mode and edit the text of a page
2. I add the text: "test edit", then press the Update button and the irritating "Leave Site?" is shown
3. I click on Leave Site and the changes to the page are saved
4. Again I make changes to the page, deleting the text "test edit", but this time I press cancel, and the Update button remains working in a infinite loop
5. I refresh the browser page and verify that my changes were not saved

[SergeyBiryukov]

Replying to yacsha:

The problem is still presented in version 5.6.3 as seen in this video

Thanks for the steps to reproduce! Let's continue the discussion in #52621.