Persist user's editor preferences to database rather than local storage

[aduth]

Related: #14512

The data module includes a persistence plugin which can be used by data stores to persist state values to browser storage.

https://github.com/WordPress/gutenberg/tree/master/packages/data/src/plugins/persistence

In the block editor, this is used in a few stores to persist preferences (e.g. toolbar placement, "new user experience" tips, etc).

Due to the transient nature of browser storage, this persistence is not as sticky as it is expected to be, including: switching browsers (unique storage between browsers), or using private browsing tabs (storage cleared between sessions), or the same user across a network of sites (storage unique by domain).

Proposal:

Preferences should be persisted as user meta. Given the WordPress-agnostic nature of the @wordpress/data module, this should be implemented in such a way that another environment could substitute their own (assumed asynchronous) persistence mechanism.

Specific details:

• Add a new option onChange to the plugin interface (Edit: This should not be necessary, see Persist user's editor preferences to database rather than local storage #15105 (comment))
  • Called when persisted value is set
  • Assigned in WordPress where currently opting in to the plugin
• Implementation of the onChange should communicate with the users REST endpoint, updating using the meta field
  • It will be required to register this meta as exposed to the REST API to be able to interact with it (show_in_rest)
• To populate the persisted value for use in the browser, it could be done with an inline script registered server-side to read from the user meta and assign to localStorage with the value on the storage key used by the persistence module

[aduth]

There may need to be some additional consideration here for how preferences persist across sites in a network of sites (multisite).

The current localStorage persistence is detrimental, but in some cases taken for granted:

• As noted in the original comment, if a multisite uses subdomains for a site, and since localStorage is distinct by hostname, preferences will not persist across sites in the network for the same user.
• In some cases, however, this might be a desired effect. For example, the "enabled blocks" preference might warrant being distinct by site in a network, since some sites might require certain blocks that other sites may not.

Relevant Slack conversation (link requires registration):

https://wordpress.slack.com/archives/C02QB2JS7/p1553102329709300

[swissspidy]

For example, the "enabled blocks" preference might warrant being distinct by site in a network, since some sites might require certain blocks that other sites may not.

The *_user_option() functions allow storing things per user per site, FWIW.

[designsimply]

Adding my vote to make it easier to turn off tips per user instead of per site!

Also noting another case where a "sticky" setting was requested for images to keep their size setting once set (and until it's changed again) in #8663.

[aduth]

In #15800, I explore a relatively simple implementation which leverages the user settings cookie, existing utils script methods for operating on this cookie, and a substitute storage implementation for the data persistence plugin. While it does not work as-is for reasons described in the pull request, it is appealing in its simplicity and reuse of existing features.

[aduth]

The *_user_option() functions allow storing things per user per site, FWIW.

Separately, I was exploring what options might exist for syncing settings to and from the REST API. get_user_option would be a nice option from the PHP, but it is not directly exposed in the REST API. That said, considering its implementation, it might be possible to emulate a similar behavior using custom meta fields registered to be exposed on the user endpoint (by emulate, I effectively mean prefixing the key with the "blog prefix" as necessary).

[aduth]

Add a new option onChange to the plugin interface

• Called when persisted value is set
• Assigned in WordPress where currently opting in to the plugin

A revision to the original proposal: The persistence plugin already offers a mechanism to substitute the default getter / setter behaviors:

https://github.com/WordPress/gutenberg/tree/master/packages/data/src/plugins/persistence#storage

It defaults to localStorage, but can accept any object which implements its own getItem, setItem functions.

[jorgefilipecosta]

Hi @aduth,
It seems the direction we will follow is using a rest endpoint and store settings user meta.
I wonder though if it still makes sense to use local storage. What is the advantage of using local storage when compared to using a just local state in the data module plus a rest endpoint request?
I guess local storage may be useful for offline mode, but I'm not sure having a specific local storage mechanism for the settings is valuable. I think when implementing an offline mode, we will need some generic mechanism that works with any endpoint used on the editor, and at the time settings can use that mechanism.

[aduth]

@jorgefilipecosta While I don't know that I considered it too closely, I think it's fair to say that (as you mention) we don't really need the localStorage data storage if we persist to a settings endpoint, especially if the data is made available immediately upon page load (using preloaded/bootstrapped endpoint data, which we already support).

To clarify however, the persistence plugin API merely imitates the localStorage interface with its setItem and getItem, but it doesn't require that it actually is localStorage. The actual interface is of the "Web Storage API", which is not limited to localStorage.

[aduth]

An alternative implementation using the REST API users endpoint meta field is proposed at: #19177

[noisysocks]

Related: https://core.trac.wordpress.org/ticket/48139

[talldan]

Renaming this issue as it seems folks have a hard time finding it.

Closing #28971 as a duplicate.

[yolinfl]

I'm interested in this thread because I'm having severe issues with Wordpress, like I can't add new users, and changes of admin (block)settings are not saved.
After struggling for 4 days with the Wordpress theme and my browsers (cache), I was pointed to this post.
What is the status right now?
Are the plugin/persistence files still solve the problem?

Thank you,
Yolanda

P.s. see my post at
https://generatepress.com/forums/topic/my-block-settings-are-not-saved/#post-1895391

[talldan]

@yolinfl This proposal won't solve your problem with adding users.

It will help save your block manager options more permanently. At the moment if you clear your browser storage they'll be lost.

[yolinfl]

Hi Talldan,
Thanks for your reply.
How can I save my block options more permanently?

[talldan]

Oh, I thought I just mentioned that 😄 . At the moment editor preferences are saved in your browser local storage, so you have to not clear your browser local storage. I'm not sure if the browser you're using does this automatically, it might be that you have your security settings at the highest level and this happens as a result.

For an actual solution, I don't know that there is one, it might be worth looking at what plugins provide.

In the longer term there is work happening to solve the problem, work has recently commenced again on the change to save preferences to the database - #19177. I imagine the hope is for this to be in WordPress 5.9 and sooner in the Gutenberg plugin.

[yolinfl]

Thanks Talidan!

[sabernhardt]

As reported on Trac 55253:

Every time WordPress updates, it changes the edit screen mode to FULLSCREEN.

[maddisondesigns]

Three years and this still hasn't been fixed

[talldan]

This is now being worked on in #39795. It won't make WordPress 6.0, but I'll try to land something for 6.1.

[maddisondesigns]

Thanks for the update @talldan. Good to hear it's making some progress.