Roots Discourse

Roots Radio Ep 13 - React w/ Daniel Bachhuber

Originally published at: https://roots.io/podcast/ep13/
Welcome back Daniel! Join us as we talk about A more RESTful WP-CLI, our take on the WP-API drama, and what we are doing with React in WordPress. Subscribe on iTunes or via RSS Listen to Episode 13 Notes: A more RESTful WP-CLI WP-CLI: new Documentation portal, Commands Cookbook, Internal API Redux Karma Enzyme runcommand.io

7 Likes

@chriscarr at al, thanks for the interesting episode. Lots of exciting things to learn about with the WP REST API and React and related technologies. In regards to previewing changes made to data that is served by the REST API, I think the answer is (of no surprise coming from me) the Customizer. For previewing changes to posts/postmeta, the Customize Posts plugin puts all changes made to posts and postmeta into the Customizer dirty state (thus not saved to the DB) and are applied to the Customizer preview via WP filters as normal. It overrides the Preview Changes button on the Edit Post screen to open the Customizer preview instead of opening the normal frontend preview, and it allows you to make additional changes to the post/postmeta in that interface (with the changes synced back to the Edit Post screen). It allows you, finally, to preview postmeta changes, including the featured image and page template.

In regards to the REST API specifically, there is the Customize REST Resources plugin which allows you to customize any REST resources served in Ajax requests in the preview. The Customize REST Resources plugin injects the Customizer state into REST API requests, as normally Ajax requests in the preview are not Customizer-aware. Instead of filtering the underlying post data, this plugin filters the REST API responses themselves, and then pushes changes back during the Customizer save via internal PUT requests.

Lastly, the big win for customizing REST API requests in Core will be when Customizer transactions land, hopefully in this release (4.6). In the proposal, each Customizer session gets an associated UUID which can then be attached to any request made to any part of WP, and the Customizer state would be applied, even for unauthenticated requests. This would even allow you to use the Customizer to preview changes in your mobile apps or on a frontend site served by a headless WP backend, as long as this transaction UUID is passed along with the requests. An initial implementation of the transaction construct can be found in the Customize Snapshots plugin.

1 Like