WordPress.org

Make WordPress Core

Opened 9 months ago

Closed 8 months ago

Last modified 6 months ago

#52440 closed defect (bug) (fixed)

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

Reported by: archon810 Owned by: SergeyBiryukov
Milestone: 5.6.2 Priority: high
Severity: normal Version: 5.6.1
Component: Editor Keywords: has-screenshots has-patch commit fixed-major
Focuses: Cc:

Description

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.

Attachments (8)

bZZK5su[1].png (4.9 KB) - added by archon810 9 months ago.
68d093af867971356f89110c07fc0576.mp4 (2.3 MB) - added by audrasjb 8 months ago.
Video capture of the issue
77d835c8537fd91e87349aaadc3ffea3.mp4 (1.3 MB) - added by audrasjb 8 months ago.
Issue is fixed after 50031 is reverted
52440.diff (663 bytes) - added by audrasjb 8 months ago.
Replace empty default value with undefined to avoid false negative in initialCompareData comparison
2021-02-05_17h20_03.mp4 (1.7 MB) - added by hwk-fr 8 months ago.
2021-02-05_17h33_40.mp4 (1.2 MB) - added by hwk-fr 8 months ago.
2021-02-05_19h23_28.mp4 (1.9 MB) - added by hwk-fr 8 months ago.
WordPress 5.6.1: Original Behavior
2021-02-05_19h21_41.mp4 (1.5 MB) - added by hwk-fr 8 months ago.
Final Fix

Change History (66)

@archon810
9 months ago

#1 @SergeyBiryukov
8 months ago

  • Milestone changed from Awaiting Review to 5.6.2
  • Version changed from 5.6 to 5.6.1

#2 @Clorith
8 months ago

#52442 was marked as a duplicate.

#3 @Clorith
8 months ago

Possibly related to r50031

This ticket was mentioned in Slack in #forums by tobifjellner. View the logs.


8 months ago

#5 @vladytimy
8 months ago

#52446 was marked as a duplicate.

#6 @davidbaumwald
8 months ago

#52447 was marked as a duplicate.

#7 @roger995
8 months ago

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

#8 @audrasjb
8 months ago

Hi there,

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

It may be related to changeset [50031].

@audrasjb
8 months ago

Video capture of the issue

@audrasjb
8 months ago

Issue is fixed after 50031 is reverted

#9 @audrasjb
8 months ago

  • Keywords needs-patch has-screenshots added
  • Priority changed from normal to high

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

@audrasjb
8 months ago

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

#10 @audrasjb
8 months ago

  • Keywords has-patch needs-testing added; needs-patch removed

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

#11 @Clorith
8 months ago

  • Keywords needs-patch added; has-patch needs-testing removed

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.

#12 @audrasjb
8 months ago

#52450 was marked as a duplicate.

#13 @Clorith
8 months ago

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.

#14 @codeiq
8 months ago

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

6.5.1

#15 @davidbaumwald
8 months ago

#52453 was marked as a duplicate.

#16 @worldedu
8 months ago

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

#17 @archon810
8 months ago

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.

https://i.imgur.com/Ua4B6Kp.png

#18 @hwk-fr
8 months ago

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.

Last edited 8 months ago by hwk-fr (previous) (diff)

This ticket was mentioned in PR #978 on WordPress/wordpress-develop by mukeshpanchal27.


8 months ago

  • Keywords has-patch added; needs-patch removed

#20 follow-up: @mukesh27
8 months ago

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

#21 in reply to: ↑ 20 ; follow-up: @Clorith
8 months ago

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

#22 @bartosz777
8 months ago

@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.

This ticket was mentioned in Slack in #forums by hwk-fr. View the logs.


8 months ago

#24 @viablethought
8 months ago

@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.

#25 @hwk-fr
8 months ago

@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.

#26 @viablethought
8 months ago

@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.

#27 @hwk-fr
8 months ago

@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.

Last edited 8 months ago by hwk-fr (previous) (diff)

@hwk-fr
8 months ago

WordPress 5.6.1: Original Behavior

@hwk-fr
8 months ago

Final Fix

#28 follow-up: @hwk-fr
8 months ago

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:

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.

Last edited 8 months ago by hwk-fr (previous) (diff)

#29 @viablethought
8 months ago

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

#30 @Clorith
8 months ago

#52456 was marked as a duplicate.

#31 @Clorith
8 months ago

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.

#32 follow-up: @archon810
8 months ago

@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?

#33 in reply to: ↑ 32 ; follow-ups: @hwk-fr
8 months ago

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 other report from @viablethought too :)

Regards.

Last edited 8 months ago by hwk-fr (previous) (diff)

#34 in reply to: ↑ 21 @SergeyBiryukov
8 months ago

  • Owner set to SergeyBiryukov
  • Status changed from new to reviewing

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.
Last edited 8 months ago by SergeyBiryukov (previous) (diff)

#35 @TimothyBlynJacobs
8 months ago

#52459 was marked as a duplicate.

#36 @SergeyBiryukov
8 months ago

  • Resolution set to fixed
  • Status changed from reviewing to closed

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.

#37 @SergeyBiryukov
8 months ago

  • Keywords commit fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backporting to the 5.6 branch.

#38 in reply to: ↑ 33 @SergeyBiryukov
8 months ago

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 :)

#39 @SergeyBiryukov
8 months ago

#52398 was marked as a duplicate.

#40 @hmabpera
8 months ago

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.

#41 in reply to: ↑ 33 ; follow-up: @archon810
8 months ago

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: https://i.imgur.com/BbpPfKr.png

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?

#42 in reply to: ↑ 41 ; follow-up: @SergeyBiryukov
8 months ago

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.

#43 in reply to: ↑ 42 @archon810
8 months ago

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?

#44 @khoulding
8 months ago

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?

#45 @hellofromTonya
8 months ago

#52472 was marked as a duplicate.

#46 @hwk-fr
8 months ago

@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
  1. 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.

Last edited 8 months ago by hwk-fr (previous) (diff)

#47 @gwmbox
8 months ago

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

Last edited 8 months ago by gwmbox (previous) (diff)

#48 @davidbaumwald
8 months ago

#52479 was marked as a duplicate.

This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.


8 months ago

#50 @paaljoachim
8 months ago

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)

Last edited 8 months ago by SergeyBiryukov (previous) (diff)

#51 @MadtownLems
8 months ago

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!

#52 in reply to: ↑ 28 @papijo
8 months ago

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:

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.

#53 @papijo
8 months ago

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

#54 @desrosj
8 months ago

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?

#55 @desrosj
8 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

This ticket was mentioned in Slack in #core by desrosj. View the logs.


8 months ago

#57 follow-up: @yacsha
6 months ago

  • Summary changed from "Leave site? Changes you made may not be saved" on custom taxonomy pages after WP 5.6.1 update to Leave Site windowsappears when you save a post using the classic editor, after WP 5.6.1 update

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

#58 in reply to: ↑ 57 @SergeyBiryukov
6 months ago

  • Summary changed from Leave Site windowsappears when you save a post using the classic editor, after WP 5.6.1 update to "Leave site? Changes you made may not be saved" on custom taxonomy pages after WP 5.6.1 update

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.

Note: See TracTickets for help on using tickets.