WP editor backups
I'm seeing a new issue regarding browser backups of blog posts and other WP content. Whenever I update any content, I see the message: "The backup of this post in your browser is different from the version below." https://screencast.com/t/Bn1Ha1Pg
I am working in Firefox on a Mac.
#3 Updated by Boone Gorges over 2 years ago
I'm assuming that you're talking about https://bmcccetls.commons.gc.cuny.edu/. If I'm incorrect about that, please provide a link to some content that demonstrates the issue.
I played on this site with a handful of test pages and could not reproduce the issue. Looking around the web, it appears that this might happen because of text that's been copied and pasted into the browser, specifically if the text contains certain non-printing characters. See eg https://wordpress.org/support/topic/the-backup-of-this-post-in-your-browser-is-different-from-the-version-below-8/. If you can share the link to a specific piece of content, I can look at the source to see if there are any such characters.
Another thing you might try is clicking through on the notice to see if you can identify the difference between the copy that WP has saved in the browser and what's on the server. This might help provide a hint as to why this is happening.
#4 Updated by Gina Cherry over 2 years ago
Yes, that is the web site. As I mentioned, I've seen this issue on all content on the site. I've tried updating multiple random events, all with the same result. I also saw this on a draft blog post that I'm working on: https://bmcccetls.commons.gc.cuny.edu/?p=3306&preview=true. The content for the post was not copied and pasted into the browser (at least not by me); it was generated through a Gravity Forms submission.
Unfortunately, clicking on the notice does not give you the option to compare the two versions; it simply restores the backup. I tried this on the draft blog post referenced above and as far as I can tell, there is no difference between the draft and the restored version.
This started happening about a week ago, so it does seem like something changed...
#5 Updated by Gina Cherry over 2 years ago
I read through the link you shared and am now wondering if this is a theme-specific issue. A few people reported seeing this bug on Woo Commerce. The CETLS site uses Woo Canvas. I was not able to reproduce it on the BMCC Open Pedagogy site, which uses Customizr
#6 Updated by Boone Gorges over 2 years ago
- Status changed from New to Reporter Feedback
Thanks for the link and additional details, Gina.
After some experimentation, I've narrowed down the issue as related to the Rich Text Excerpts plugin. It's putting some dummy content into the TinyMCE text area for the Excerpt, which is causing the autosave check to fail for that field. See https://community.tiny.cloud/communityQuestion?id=90661000000Ms2iAAC for more information on a related TinyMCE issue. If the Rich Text Excerpts plugin is disabled, and the Excerpt is repopulated (so as to remove the hidden markup), the notice appears to go away.
I don't see that other users have reported this issue with the plugin, so it could be that something specific about the Commons or the BMCC CETLS site is triggering the error. https://wordpress.org/support/plugin/rich-text-excerpts/ In any case, the plugin doesn't appear to be actively maintained, so I'm unsure that it'd be possible to get a fix in, even if we were able to identify the proper fix.
All this being said, the notice should be harmless, so I think you can safely avoid it.
#8 Updated by Boone Gorges over 2 years ago
- Status changed from Reporter Feedback to Staged for Production Release
- Target version set to 1.15.11
I couldn't find another plugin that does this, on the Commons or otherwise. CCing Scott in case I missed something.
I spent a little time trying to address the underlying bug. I don't 100% understand the root cause, but I was able to hack something together that mostly fixes it. https://github.com/cuny-academic-commons/cac/commit/d5693277985310e4c1ef393a94b38b0f7c392230 It's not pretty but it seems to work for most workflows, by deleting the dummy div when it gets stored in localStorage. This'll be part of the release on Tuesday.