Backport block editor persisted preferences #3219
Conversation
| @@ -294,6 +294,9 @@ function wp_default_packages_scripts( $scripts ) { | |||
| case 'wp-edit-post': | |||
| array_push( $dependencies, 'media-models', 'media-views', 'postbox', 'wp-dom-ready' ); | |||
| break; | |||
| case 'wp-preferences': | |||
| array_push( $dependencies, 'wp-preferences-persistence' ); | |||
| break; | |||
There was a problem hiding this comment.
Don’t think this case is necessary as script-loader-packages.php contains everything needed for WordPress to know that wp-preferences depends on wp-preferences-persistence. This switch is for dependencies that can’t be derived from the package.json.
There was a problem hiding this comment.
I don't think it can be derived from the package.json.
The two packages intentionally have no coupling, as one has WordPress specific code and the other doesn't.
There was a problem hiding this comment.
Oh! I see. And we want it so that when wp-preferences is enqueued it automatically has a persistence layer set up. OK then 👍
src/wp-includes/user.php
Outdated
| 'type' => 'object', | ||
| 'properties' => array( | ||
| '_modified' => array( | ||
| 'description' => __( 'The date and time the preferences were updated.', 'default' ), |
There was a problem hiding this comment.
| 'description' => __( 'The date and time the preferences were updated.', 'default' ), | |
| 'description' => __( 'The date and time the preferences were updated.' ), |
src/wp-includes/user.php
Outdated
| @@ -4951,3 +4951,44 @@ function wp_is_application_passwords_available_for_user( $user ) { | |||
| */ | |||
| return apply_filters( 'wp_is_application_passwords_available_for_user', true, $user ); | |||
| } | |||
|
|
|||
| /** | |||
| * Register the user meta for persisted preferences. | |||
There was a problem hiding this comment.
Can we give a little context to what "persisted preferences" means? e.g. mention that the block editor uses it.
There was a problem hiding this comment.
I've updated the comment, let me know if you think that looks ok.
Co-authored-by: Colin Stewart <79332690+costdev@users.noreply.github.com>
@costdev Thanks for your review. I'm definitely happy to contribute some tests, but I may need some advice on the best strategy. Is there an easy way to unit test something like the addition of the meta attribute? |
|
@talldan I'd do something like this (untested): public function test_should_register_persisted_preferences_meta() {
wp_register_persisted_preferences_meta();
$actual = get_registered_metadata( 'user', 1, 'wptests_persisted_preferences' );
$this->assertNotFalse( $actual, 'The expected meta key was not registered' );
$this->assertSame(
array(
// Copy the array contents from source.
),
$actual,
'The metadata did not have the expected value'
);
}P.S. This was typed on mobile, so all indents are spaces and need to be converted to tabs. 🙂 |
|
Submitted refresh PR including unit test in #3253. |
|
Closing in favor of PR #3253 which applies this PR and adds tests. |
|
Newer version in PR 3253 was committed via https://core.trac.wordpress.org/changeset/54182. |
Description
Backports the persisted preferences feature from Gutenberg (introduced in WordPress/gutenberg#39795).
Removes the old block editor preferences persistence system.
Testing
Expected: Preferences should be retained (e.g. Top Toolbar should still be on) despite local storage being cleared
Trac ticket: https://core.trac.wordpress.org/ticket/56467
Props noisysocks costdev
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.