Problem/Motivation

Following the upgrade to 3.0.x, (I think it might be related to this upstream change) - custom preferences are no longer persisted since data.plugins.persistence.__unstableMigrate() is now a noop.

And potentially the #3402817: Override registerCoreBlocks() with the gutenberg/overrides dependencies pulling in certain dependencies before the data persistence has been configured.

Steps to reproduce

Turn off Fullscreen mode and refresh the page.

It previously persisted the fullscreen preferences in your local storage. However it currently doesn't, forcing the page to always be in fullscreen mode.

Proposed resolution

Update the library dependency hierarchy ensuring that the data persistence plugin is loaded before the block editor is initialized. Or otherwise find out which breaking API change needs to be addressed.

Remaining tasks

Investigate and provide MR.

User interface changes

Minimal. But existing UI customizations should be persisted where relevant.

CommentFileSizeAuthor
#9 3414998-updating-failed.png27.71 KBmarcofernandes

Issue fork gutenberg-3414998

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

codebymikey created an issue. See original summary.

codebymikey’s picture

codebymikey commented
Related issues: +#3402817: Override registerCoreBlocks()
codebymikey’s picture

codebymikey commented
Issue summary: View changes

Found the real upstream issue https://github.com/WordPress/gutenberg/pull/39795.

It seems https://git.drupalcode.org/project/gutenberg/-/blob/a699656a/js/data.js#L7 is now a noop.

In particular, this change, where the local settings are now stored in the database rather than local storage.

The equivalent API in Drupal would be PrivateTempStore.

The question is whether we should update the logic such that we keep persisting data in localStorage or in the database

marcofernandes’s picture

marcofernandes commented

I think we would first fix storing the preferences to localstorage and then create a feature request to move to the database.

codebymikey opened merge request !93

codebymikey’s picture

codebymikey commented
Status: Active » Needs review

Provided a fix maintaining storage within localStorage, and if we need to persist the user preferences in database, then that can be done using the UserData service later.

Additional reference for the API: https://www.webomelette.com/storing-user-data-such-preferences-drupal-8-...

  • codebymikey committed d6963fc7 on 3.0.x 
    Issue #3414998: Custom preferences are no longer persisted
codebymikey’s picture

codebymikey commented
Status: Needs review » Fixed
marcofernandes’s picture

marcofernandes commented
Status: Fixed » Needs work
StatusFileSize
new 3414998-updating-failed.png27.71 KB

Noticed now that this is appearing after this change:
Updating failed

marcofernandes opened merge request !101

marcofernandes closed merge request !101

marcofernandes opened merge request !102

marcofernandes closed merge request !102

marcofernandes opened merge request !103

marcofernandes’s picture

marcofernandes commented

For now, I reverted the code at api-fetch.js that caused the issue. Preferences are still persisted.

marcofernandes’s picture

marcofernandes commented
Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.