Migrate editor preferences to new package.

[talldan]

What problem does this address?

The editor more menu is entirely implemented in the edit-post package and not reusable across editors.

The site and widgets editors are duplicating a lot of code to implement more menus, and this seems unnecessary. Much of the options could be implemented in a more generic and reusable way.

What is your proposed solution?

Either migrate the preferences to the interface package or create a new package.

Interface seems a good fit because it already has some similar UI concepts in the sidebar and tabs that it exposes. These are configurable, so migrating the more menu would involve similar work.

The preferences for some editors have now already been migrated to interface, but the plan is to now create a new preferences package, so they'll need to be migrated again.

Update - the new preferences package has now been shipped, and the next step is to migrate the preferences in each of our editors/packages.

---

Status

• Add new @wordpress/preferences package #38873
• Migrate standalone widgets editor to use new preferences package #39084
• Migrate customize widgets editor to use new preferences package #39112
• Migrate post editor feature preferences to use new preferences package #39115
  • Migrate hidden block types (block manager data) to new preferences packages #39132
  • Migrate post editor editorMode to use preferences store and remove localAutosaveInterval preference #39180
  • Migrate post editor preferred style variations to preferences store #39337
  • Migrate post editor panels state to preferences store #39604
• Deprecate interface package's preference APIs #39418
• Migrate site editor to use new preferences package #39158
• Add reusable preferences modal to interface package. #39153
• Migrate interface enableItems data to preferences package #39449
• Migrate navigation editor selected menu to preferences store #39606
• Migrate block editor insert usage to preferences store #39632
• Migrate editor package isPublishSidebarEnabled to preferences store #39707
• Migrate NUX persisted data?
• Move the block manager to block editor package #39672
• Add new preferences persistence API, and save editor preferences in user meta #39795

[noisysocks]

Maybe a seperate issue, but it's not great at all that #31925 duplicates images.js as it's quite a large file. We need to refactor this to a common package or maybe to wp-admin/images/.

[talldan]

Now in a pretty good state for migrating 'feature' preferences to the interface package, with PRs open for every editor that implements these preferences.

What other kind of preferences are there? The only remaining preferences live in the post editor:

Panel preferences

The way these are implemented is already very generic, and it could easily be brought to other editors. It also fits in quite nicely with the remit of the interface package. However, no other editors have any need to implement this, so it might be worth waiting until a use case arises.

Editor mode

This is also very specific to the post editor, and might not be something to migrate to other editors. Though there is a feature request to bring this to the widget editor (#33518).

Block Manager / Hidden Block Types

Very much a feature that is desired in other editors, so this could be refactored, hover I'm not convinced that the interface package is the right option. Interface deals more with UI abstractions, and this is very block specific. It could perhaps be its own package?

Default block style / Preferred style variations

This is in the edit-post store, so it doesn't feel like this feature was implemented in the right way originally—it'll only work in the post editor. Where should it live? Again a very block-oriented feature. An option could be a 'Block Preferences' package that has this and the Block Manager.

localAutosaveInterval

It seems like this is outside the remit of this change. I don't think there's a user facing way to modify this value. I'm not completely sure why it needs to be persisted to local storage. Would be good to understand more about that.

[talldan]

The latest feedback (#24370 (comment)) is to create a new 'preferences' package. I don't really have the bandwidth to handle that, so I'll hand this over to another willing contributor.

[talldan]

Now things are a bit calmer again following 5.9 I'll work on the new preferences package.

[annezazu]

Looks like this work has been completed! I'm going to close this out as a result but let me know if it needs to be reopened.