Editor: preferences not persisting across sessions

[KokkieH]

Quick summary

We've had some reports from users that editor preferences aren't persisting. This includes the Welcome Tour, but also other settings like the Top Toolbar setting and Prepublish Checklist preferences.

The occurrence of the issue appears to coincide with the launch of Gutenberg 13.2.2, which changed from storing editor preferences via a browser cookie, to storing them in the site database.

So far all the reports we've seen are from Windows 10 users, and started after clearing browser cookies or reinstalling the OS. The issue occurs across all browsers and even the desktop app on a particular computer, while preferences save just fine if the same user logs in using a different computer. So it appears to be device-specific.

There's some similarity to #57660, but this feels like a different issue.

p7H4VZ-3CN-p2 is possibly related.

Steps to reproduce

This appears to be affecting random Windows users, with no specific steps to replicate.

One a11n has been able to replicate in p1653532494212969/1653510918.568739-slack-C03UXG192

What you expected to happen

For the Welcome Tour to not reappear once dismissed, and for editor preferences to persist.

What actually happened

The welcome tour keeps coming back, and editor preference don't persist.

Context

Three reports in the forums so far:

• https://wordpress.com/forums/topic/unstoppable-tour
• https://wordpress.com/forums/topic/problem-with-setting-on-the-editor-page/?view=all
• https://wordpress.com/forums/topic/getting-rid-of-prepublish-checklist/?view=all

Simple, Atomic or both?

Simple

Theme-specific issue?

No response

Browser, operating system and other notes

No response

Reproducibility

Once

Severity

Some (< 50%)

Available workarounds?

No but the platform is still usable

Workaround details

No response

[arunsathiya]

• Another report of welcome tour at the bottom left on the editor not going away: 5288361-zen

[arunsathiya]

• Quick note that I can consistently reproduce this issue on WordPress.org sites too, so I created an upstream issue here: Editor preferences not saving as expected WordPress/gutenberg#41676

[thekingsprojects]

• Another user report here: 5290231-zen

They shared browser details (and do appear to be using Win10): https://www.whatsmybrowser.org/b/67OBE

[arunsathiya]

Update to my previous comment here: it's not happening on core, I was testing incorrectly earlier. It's happening just on WPcom.

Also flagged at p1655393301515619-slack-CBTN58FTJ

[kimerlin81]

Welcome tour modal reappearing after being completed and dismissed reported

• Once fixed, please follow up with user in ticket p7DVsv-eD3-p2

[thekingsprojects]

• Another report of the modal reappearing when dismissed, and request for follow-up: 5307692-zen

[darnelldibbles]

The user is experiencing this issue on an Amazon Fire 10, 9th generation

Fire OS 7.3.2.3 /Android 9.

https://wordpress.com/forums/topic/welcome-to-wordpress-pop-up/?view=all#post-3835514

[csonnek]

Looks like there's another older issue tracking this in #57660

[jerrysarcastic]

Also reported in https://wordpress.com/forums/topic/constant-pop-up

Chrome 102/Windows 10

The user would like a follow-up when this is resolved

[st8matrix]

Another user reported the issue here: 5319366-zen

Chrome 100

[danielbachhuber]

@lupus2k did a great job debugging this.

Here's how to reproduce:

1. Open a post in wp-admin in one browser and change a preference.
2. Refresh the page.
3. Open a post in wp-admin in another browser and change a different preference.
4. Refresh the first window and observe that the preference is incorrect.

Gutenberg has some fanciness to make sure that any changes in the second browser are applied to the first browser: https://github.com/WordPress/gutenberg/blob/7d99c49fd267de4c1cccda0224f35a20c8e887f6/lib/compat/wordpress-6.1/persisted-preferences.php#L46-L75

For gutenberg_configure_persisted_preferences(), $wpdb->get_blog_prefix() uses the correct blog ID. However, when the user meta is registered in gutenberg_register_persisted_preferences_meta(), the blog prefix is incorrect: it's referencing public-api.

Thus, serverData isn't ever populated:

We need to make sure register_meta() registers a meta key with the correct blog ID. Once that's done, serverData should be populated as expected.

[creativecoder]

@lupus2k @danielbachhuber Nice sleuthing!

This has been a common problem with the Gutenberg integration for Simple sites. Take a look at the prior art in wpcom-gutenberg-load.php. Unhooking gutenberg_register_persisted_preferences_meta from init and adding it back on another hook like restapi_theme_init may fix the issue.

[creativecoder]

rest_api_switched_to_blog may be a better hook to use, since the issue is with the blog prefix, and not the theme.

[danielbachhuber]

@lupus2k Need any help landing your fix?

[lupus2k]

Sorry, @danielbachhuber, I was AFK until today, I will submit this on the next days 😉

[lupus2k]

I created a PR on Gutenberg to fix this issue: WordPress/gutenberg#50005

[lupus2k]

Created this diff: D108772-code

[lupus2k]

I created a PR on Gutenberg to fix this issue: WordPress/gutenberg#50005

We closed this in favor of @creativecoder suggestion here.
Thanks @danielbachhuber, for noticing this.

[danielbachhuber]

Started a conversation about seeing if we can catch these issues more proactively p1682347976509179-slack-CBTN58FTJ

[lupus2k]

Thanks for catching this @danielbachhuber, it a great idea!

[lupus2k]

We merged the fix (D108772-code) and the problem should be solved

[cuemarie]

@lupus2k @danielbachhuber it appears this issue may have returned. it was reported here: #80852

and I was able to reproduce following your steps above on Simple Site only:

6OkfpM.mp4

Are y'all available to take a look to see if something regressed here?

[cuemarie]

User report from #80852 :

• 6689722-zen

[cuemarie]

@danielbachhuber Would you prefer that we look into this as a new report as well, rather than reopening this one? (If so, I can take care of spinning up that new issue instead!)

[danielbachhuber]

@cuemarie Yes, please. Thanks!

[cuemarie]

📌 ACTIONS

• Closed in favor of new report: [Editor] Preferences are not being saved #80852