Fancy yourself some challenging architectural puzzles? Have we got the ticket Created for both bug reports and feature development on the bug tracker. for you!
We’d love your help 🙂 Read through and comment on the issues linked below as you have time. Then, if you’re available, join the next REST API office hours for a rousing conversation: Thursday, April 26 at 17:00 UTC
- Category, tag, and taxonomy controls don’t respect the correct capabilities
A user should be able to set terms on a post if they have
assign_terms, and can create new terms if they have
assign_terms for a non-hierarchical taxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies., or
edit_terms for a hierarchical taxonomy. However, capabilities are evaluated at runtime which means we can’t use them declaratively in Gutenberg. It would be nice if there was some existing REST paradigm we could incorporate.
- Support for automatically iterating paginated resources in core-data
Gutenberg has a new
withSelect() could pull paginated data into scope for us. For context on why infinite scroll isn’t appropriate, read this thread.
- Link modal suggestions only include posts when they should also include pages
REST is explicit about separating our data model into their appropriately shaped endpoints. This is why
wp/v2/posts doesn’t also include Pages, Events, etc. One common use-case in WordPress is search, where the results can list multiple entities. We should produce a
wp/v2/search endpoint exclusively for searching across models.
- Abysmal response time when fetching pages to be listed in page attributes
_fields= parameter landed in WordPress 4.9. However, WordPress still generates every field and then filters it out. Ideally, the fields wouldn’t be generated in the first place when the parameter is used.
Even more curious? Dive into the entire Gutenberg REST API milestone and all Trac tickets tagged ‘rest-api’.