Post types REST API: add revisions support to view context #56624
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ramonjd
added
[Type] Enhancement
ramonjd
force-pushed
the
add/revision-supports-to-post-types-response
branch
from
1673b54 to
f4c6cdc
Compare
7 tasks
|
This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress. If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged. If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack. Thank you! ❤️ View changed files❔ phpunit/class-gutenberg-rest-post-types-controller-test.php ❔ lib/compat/wordpress-6.5/rest-api.php |
|
Size Change: -22 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
In what circumstances would a user who can't edit posts in a post type be able to use revisions for that post type? |
@TimothyBJacobs I'm glad you dropped by 😄 I was having a few doubts about this one. It's more about the information we want from In Gutenberg there's a call to https://github.com/WordPress/gutenberg/blob/trunk/packages/core-data/src/entities.js#L300 At this stage it'd be also great to know if a post supports revisions so we can opt to prepare the reducer to handle incoming revisions. To answer your question specifically, there are not yet circumstances in which a user can use revisions for posts for which they have no privileges. It's primarily about the information available to the application at bootstrap time. I could have been clearer about this point in the PR. There are other options:
cc @youknowriad who will have a better idea than I What are your thoughts on a more orthodox approach to this? |
Thinking about this again, then perhaps it's way to go? We could handle the 404/403s in the resolvers. The only downside is that all 
|
That's totally fine IMO, it's just an internal state. |
|
I'll close this one off and put up a PR tomorrow to get rid of the hardcoded supports array and just rely on the server checks. Thanks, everyone! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In progress...
What?
This PR adds
supports.revisionsto the post type objects returned byWP_REST_Post_Types_Controllerand the following routes:/wp/v2/types/wp/v2/types/post_typeThe default context for these routes in 'view'.
This allows us to remove the hardcoded
POST_TYPES_WITH_REVISIONS_SUPPORTconstant in Core Data entities.Why?
Supports information is only available in the "edit" context. See WP_REST_Post_Types_Controller::get_item_schema().
The Block Editor's Core Data package fetches post types using the view context, but also needs to know about revisions support (since #54046).
So far, we've been duplicating post type revisions support in a
POST_TYPES_WITH_REVISIONS_SUPPORTconstant.Revisions is being integrated into the Block Editor UI (example), and therefore, there is a argument that
supports.revisionsbelongs to the "view" context.It's not appropriate to fetch the post types with
context=editbecause users who do not have edit access to the post types may be using the editor.How?
rest_prepare_post_typefilter to modify the response only in the view context and only when the post supports revisions.No other supports information is added.
The path to Core migration could be to modify
get_item_schema()and allow the fieldsupports => array( 'revisions' => true )in view context always when the post type supports revisions.This PR does not extend the controller in this way, opting for
rest_prepare_post_typeout of convenience.TODO
supportsPaginationinto theentity.supportsconfig in entities.js. See Revisions: add new selectors to fetch entity revisions #54046 (comment) Probably a good follow up to this PR.Testing Instructions
Check that
getRevisionsworks for supported post types.Example:
See the test descriptions in #56353 for other supported post types.
Run the tests!
npm run test:unit:php:base -- --filter Gutenberg_Test_REST_Post_Types_Controller