Gutenberg, REST API, and you

Fancy yourself some challenging architectural puzzles? Have we got the ticketticket Created for both bug reports and feature development on the bug tracker. for you!

As you may know, GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ uses the WordPress REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. as a bridge between the land of JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/. and land of PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher. There were a whole host of conceptual challenges in translating WordPress internals to REST — and even more we still haven’t solved!

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 taxonomyTaxonomy 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() JavaScript APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to fetch data from the REST API. Problems like this and this could be readily solved if 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
  A _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’.

Thanks!

#gutenberg, #rest-api