#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)
Change History (66)
This ticket was mentioned in Slack in #forums by tobifjellner. View the logs.
4 years ago
#7
@
4 years 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
@
4 years ago
Hi there,
I can confirm I am able to reproduce the issue on 5.6.1.
It may be related to changeset [50031].
#9
@
4 years 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.
@
4 years ago
Replace empty default value with undefined
to avoid false negative in initialCompareData
comparison
#10
@
4 years 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
@
4 years 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.
#13
@
4 years 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.
#17
@
4 years 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.
#18
@
4 years 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.
This ticket was mentioned in PR #978 on WordPress/wordpress-develop by mukeshpanchal27.
4 years ago
#19
- Keywords has-patch added; needs-patch removed
Trac ticket: https://core.trac.wordpress.org/ticket/52440
#22
@
4 years 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.
4 years ago
#24
@
4 years 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
@
4 years 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
@
4 years 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
@
4 years 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.
#28
follow-up:
↓ 52
@
4 years 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.
#31
@
4 years 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:
↓ 33
@
4 years 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:
↓ 38
↓ 41
@
4 years 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.
#34
in reply to:
↑ 21
@
4 years 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.
#37
@
4 years 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
@
4 years 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 :)
#40
@
4 years 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:
↓ 42
@
4 years 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:
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 filewp-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:
↓ 43
@
4 years 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
@
4 years 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
@
4 years 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?
#46
@
4 years 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:
- 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
andTest
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
- Let us help you:
- 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.
#47
@
4 years 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
This ticket was mentioned in Slack in #core by hellofromtonya. View the logs.
4 years ago
#50
@
4 years 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)
#51
@
4 years 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
@
4 years 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 thewindow.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.
#54
@
4 years 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?
This ticket was mentioned in Slack in #core by desrosj. View the logs.
4 years ago
#57
follow-up:
↓ 58
@
4 years 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:
- I use the classic editor in HTML mode and edit the text of a page
- I add the text: "test edit", then press the Update button and the irritating "Leave Site?" is shown
- I click on Leave Site and the changes to the page are saved
- 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
- I refresh the browser page and verify that my changes were not saved
#52442 was marked as a duplicate.