Preferences persistence - mark modified property as not readonly in schema

[talldan]

What?

Changes a user meta _modified schema property (used for persisting preferences) to not be readonly.

Why?

As mentioned here, it shouldn't be readonly - #39795 (comment)

The property is updated in a PUT request, so that means it shouldn't be read only.

This doesn't seem to change anything in terms of the actual user experience. Possibly this schema is only used for docs and the readonly aspect has to be implemented separately.

Testing Instructions

Test that persisted preferences still work:

1. Login to WordPress using the same user in two different browsers (e.g. chrome and firefox)
2. Edit a post in each browser
3. Change a preference in one browser (e.g. enable Top Toolbar)
4. Reload the page on the other browser

Expected - the preference change should be reflected (e.g. top toolbar should be enabled)

[noisysocks]

This doesn't seem to change anything in terms of the actual user experience. Possibly this schema is only used for docs and the readonly aspect has to be implemented separately.

I think that's true cc. @TimothyBJacobs

[TimothyBJacobs]

We should also remove context from the _modified property since the same value is defined for the entire schema.

This doesn't seem to change anything in terms of the actual user experience. Possibly this schema is only used for docs and the readonly aspect has to be implemented separately.

I think that's true cc. @TimothyBJacobs

More or less. Top level readonly properties get removed from the args description, but it isn't really a complete api.

https://github.com/WordPress/wordpress-develop/blob/d47a44ab68c8afc413b7f7b63ffd89498d213031/src/wp-includes/rest-api.php#L3245

[talldan]

We should also remove context from the _modified property since the same value is defined for the entire schema.

Thanks for spotting that, I've pushed a commit to remove it 👍