WordPress 6.1 introduces a new system for managing preferences in block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. editors. Prior to 6.1, user preferences (like Top toolbar or Fullscreen mode) were only persisted via browser local storage. This resulted in users losing their preferences when they cleared browser data, with their preferences confined to the individual browser instance.
With 6.1, WordPress is adopting a new system for editor preferences. They will be stored server side in user meta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. in addition to the browser’s local storage. This change means they will now be retained when clearing local storage, and can be used across multiple browsers or computers.
Continuing to use local storage as a secondary way to persist preferences adds a layer of redundancy for situations where a user is offline, or the network (versus site, blog) request to save preferences in user meta is interrupted.
The previous preferences implementation
WordPress previously used a @wordpress/data persistence plugin for the purpose of persisting its preference data. From 6.1 on, WordPress will no longer use this preferences system and will switch to a new system.
Plugins were also able to use the data plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for persisting any plugin related preferences. This will continue to work as before, but will still only use browser local storage.
The new preferences system
The new system is implemented in the @wordpress/preferences package. This package implements a centralized store for any preference data, and can be used by plugins.
The APIs that are relevant to plugins are straightforward to use:
// Set defaults for any preferences on initialization.
// A new user's preferences will have these values.
// Default values are not persisted.
wp.preferences.setDefaults( 'my-plugin', {
preferenceA: 1,
preferenceB: false,
} );
// Update preference values. These values will be persisted.
wp.preferences.set( 'my-plugin', 'preferenceA', 2 );
wp.preferences.toggle( 'my-plugin', 'preferenceB' );
// Read preference values.
wp.preferences.get( 'my-plugin', 'preferenceA' ); // 2
wp.preferences.get( 'my-plugin', 'preferenceB' ); // true
The 'my-plugin' value is called a scope, and the preferences system uses this to partition data.
Documentation:
Props @bph and @webcommsat for review
#6-1, #dev-notes, #dev-notes-6-1
