Add the content write abilities through the REST API - #1026
Draft
jorgefilipecosta wants to merge 6 commits into
Draft
jorgefilipecosta wants to merge 6 commits into
jorgefilipecosta wants to merge 6 commits into
Conversation
The read abilities only ever dispatched GET. Extract the dispatch and error handling into one place and add POST and DELETE on top of it, so the write abilities can reach the same endpoints.
Content_Rest resolves a post type's REST route, exposes a post type that abilities can see but REST cannot, and puts the global post context back afterwards. The write implementations need all three, so move them out of the read implementation instead of copying them.
Creates, updates and deletes posts through the posts endpoint, so the capability checks, sanitization and side effects stay with the controller. The written post is read back through the read implementation, which keeps one field mapping for both directions.
…lete Registers them from the read ability's register(), where the placeholder comment said a write ability would go. The permission callbacks gate on the post type being exposed to abilities and on the caller's capability for the post; everything past that is the posts controller's own checks. The output reuses the read ability's post field definitions, so a written post is reported the same way a queried one is.
The endpoint is the only implementation, so the tests assert both halves: the mapping this plugin owns, and the controller behaviour it inherits and must pass on — the refusal to assign another author, an unparseable date, an already trashed post, and a post type that does not support trashing.
✅ WordPress Plugin Check Report
📊 ReportAll checks passed! No errors or warnings found. 🤖 Generated by WordPress Plugin Check Action • Learn more about Plugin Check |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## try/core-read-abilities-rest-backend #1026 +/- ##
==========================================================================
+ Coverage 81.12% 82.11% +0.98%
- Complexity 3069 3140 +71
==========================================================================
Files 126 128 +2
Lines 12007 12352 +345
==========================================================================
+ Hits 9741 10143 +402
+ Misses 2266 2209 -57
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Content_Write and Content_Write_Rest read as the native/REST pair the read ability has, and there is no such pair here: the endpoint is the only way these abilities write. One class says that without a docblock having to.
This file contains hidden or 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
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.
What?
Adds
core/content-create,core/content-updateandcore/content-delete, the write counterparts tocore/content-query. They have one implementation: the REST posts endpoint.Stacked on #931 — it added the REST-backed read implementations, and this reuses that machinery.
Why?
The write paths are where the checks matter: capabilities, sanitization, slug uniqueness, revisions,
rest_insert_*. The posts controller already does all of it, so calling it is less to get wrong than a second copy. No native implementation this time.How?
Content_Write.phpPOST /wp/v2/<rest_base>,POST /<id>,DELETE /<id>callsPost_Type_Route.phpContent_Rest.phpRest_Backend.phppost()anddelete()besideget()One class, one implementation. There is no native/REST pair here — nothing reaches
wp_insert_post()or its siblings directly.Registered from
Content::register(), where the placeholder comment said a write ability would go. The permission callbacks gate on the post type being exposed to abilities and on the caller's capability for the post; everything past that is the controller's.An update sends only the fields the input names, so it leaves the rest alone. A delete trashes by default and reports
{ deleted, post };forcedeletes permanently, and the post is read while it still exists. Written posts are reported by reading them back throughContent_Rest, so one field mapping serves both directions.Two helpers on
Contentbecame public (get_exposed_post_types(),get_post_properties()) so both sides gate on the same post types and report the same fields. Both are marked// Plugin:.Testing
24 tests in
Content_WriteTest.php. They assert the mapping this plugin owns and the controller behaviour it must pass on rather than swallow — the refusal to assign another author, an unparseable date, an already trashed post, and a post type that does not support trashing.Use of AI Tools
AI assistance: Yes
Tool(s): Claude Code
Model(s): Claude Opus 5
Used for: The abilities, the REST mapping, the tests and this description were drafted with Claude Code and iterated against the suite in a local
wp-envenvironment. I reviewed and edited the result, and I take responsibility for it.Changelog Entry