REST API: Add source parameter for types endpoint
#128
Conversation
| // Mark as created so we don't duplicate it | ||
| update_option( 'scf_test_post_type_created', true ); | ||
| } |
There was a problem hiding this comment.
NIT: Delete option on plugin deactivation / uninstall.
There was a problem hiding this comment.
This is actually done here, although there was a typo.
What was missing was deleting the post type itself, which I fixed in the latest commit. Since post deletion is done on plugin deactivation on the PHP side, I've moved deleting the option to the same deactivation hook for consistency.
| if ( null === $this->cached_post_types ) { | ||
| $this->cached_post_types = $this->get_source_post_types( $source ); | ||
| } | ||
| $source_post_types = $this->cached_post_types; |
There was a problem hiding this comment.
In practice, the way the REST API works is that one request corresponds to one fresh execution of the WP stack, including running through SCF_Rest_Types_Endpoint's constructor and down that stack. However, semantically, cached_post_types is an instance property of a class that represents an endpoint, not a request. Here's my concern when I read this chunk:
Is there any scenario (e.g. request batching or sequential rest_do_request calls) where it's possible to process more than one request with the same endpoint instance? If so, this cache will need invalidation. At the very least, it should be source-indexed:
$source_post_types = $this->cached_post_types[ $source ];… but ideally its lifetime should be that of a request.
No?
| // For collection requests, we don't need to add any filter here | ||
| // as clean_types_response will handle removing null values from the response | ||
| // and filter_post_type will handle individual filtering |
There was a problem hiding this comment.
In light of this, why even check for $is_collection? Seems like a distraction, no?
| } | ||
|
|
||
| if ( 'scf' === $source || 'other' === $source ) { | ||
| $scf_types = array(); |
What
/wp/v2/typesREST API endpoint that allows filtering post types by their origin:core(WordPress built-in),scf(for SCF managed types), orotherfor the rest of CPTs./wp/v2/types) and single item (/wp/v2/types/{type}) endpointsWhy
When working on the Command Palette Integration and considering using the REST API to define CPT-related commands, requesting specifically for the CPTs managed by SCF became a need, and it will be needed, too, when implementing DataViews.
In fact, this branch is directly based on #124 and started in parallel, as we both realized we needed to tweak the Types endpoint if we wanted to leverage the API.
How
sourceparameter is not defined, nothing changes.rest_request_before_callbacksfor the single request, returning 404 if the requested type doesn't meet the criteria.rest_prepare_post_typeto filter each post type by source before WordPress prepares it.rest_pre_echo_responseto removenullvalues returned byrest_prepare_post_typein the response array.rest_prepare_post_typefires once per post type, the Post Types belonging to the requested source are calculated in advance inrest_request_before_callbacksand reused throughout the whole request.Testing Instructions
- Make a GET request to
/wp/v2/typesto see all post types- Add
?source=coreto filter for WordPress built-in post types only- Add
?source=scfto see only post types managed by SCF- Try
?source=otherto see post types registered from other sources- Test single post type endpoints like
/wp/v2/types/post?source=core- Try an invalid source value (e.g.,
?source=invalid) to verify validation works- Confirm a 404 error when requesting a post type with the wrong source (e.g., /wp/v2/types/post?source=scf`
- Run PHPUnit tests:
composer test:php -- --filter=Test_REST_Types_Endpoint- Run E2E tests:
npm run test:e2e tests/e2e/rest-api-types-endpoint.spec.tsPotential follow-ups
sourceas a field in the response, as there would be no performance loss.