WP-API
WP-API copied to clipboard
WP-API
Accessing presentational data through WP-API
Core has presentational functions like post_class() which are dynamic basic on context. They're also not really "resources" that you'd expect to be able to manipulate through WP-API.
- What are all of the functions that would fit in this classification?
- Is it the responsibility of WP-API to return this data? If so, how should it?
cc @jacklenox
From the perspective of building themes that use the REST API, here are the things that I'm currently having to hack a bit:
permalink_structure– I have to runget_option( 'permalink_structure' )to establish what the user's permalink structure is and either shove this somewhere in the document or pass it to my JS usingwp_localize_script()body_class()– Similar to above but becomes more of an issue when user is navigating from page to page to post etc. I'm experimenting with WebSockets for back and forth communication between my SPA theme and the server. However this would ideally be somehow accessible via the REST APIpost_class()– As discussed and similar to above. I've currently modified the REST API itself for my testing as per #621
A few other notes at this stage. It would be really handy to be able to GET posts by slug as well as ID. The WordPress.com REST API allows you to do this. It's a fairly important feature if you want your theme to support any permalink structure. At the moment I have to have a bit of server-side/JS hackery going on, or a double AJAX request that first runs url_to_postid().
If one could get the permalink structure from the REST API, and one could query for posts/pages by slug, what I'm currently hacking on would be much simpler.
If we can get body_class() and post_class() in, that would be fantastic. I'm also open to suggestions of other ways to achieve what it is I'm trying to do.
I'm assuming that people agree that a theme that uses the REST API shouldn't need any specific configuration.
@jacklenox You can get get posts by slug, that's what I am doing here with my Express app that I threw together the other day using the JSON API.
https://github.com/whyisjake/Wired-Express/blob/master/routes/index.js#L69-L83
Of note, it would be great if this was a top level endpoint.
@danielbachhuber I think that exposing post formats would be important, like any other taxonomy.
@whyisjake Ah, that's a nice workaround. Nice. But agreed, it would be great if it was a top level endpoint.
I also agree on post formats.
A theme should supply this as added data. If I have external app I would have no need for a post class.
As noted, you can add fields to the endpoints, but if every theme is going to do it, we might as well add it.
What about adding another context here like theme that returns extra things you may need to know? Feels like this fits into the context system nicely.
As regards the permalink structure, we might be able to achieve this in other ways; for example, adding a new /json/ endpoint similar to /feed/. You could then intercept any local request and add /json/ to the URL. Internally, these would just load the posts view with the query set to the main query. I've considered this approach in the past, and the plan was to leave it to a plugin, but might be worth having in core.
something like define post_class true or another method in theme to add presentational data
+1 on "It would be really handy to be able to GET posts by slug as well as ID." I'm with @whyisjake, filter[name]=whatevs (or .name('whatevs') with the node WP api client module) is by far the most commonly invoked function on the production site we're running on the API... but then you do need to posts[0] or _.first(posts) to render it.
Let's keep this issue focused on presentational data (e.g. body classes and whathaveyou). I've created a new issue for getting resources by slug #642
It's a fairly important feature if you want your theme to support any permalink structure.
I'd just like to mention on this note that we might be able to run these through WP instead (and WP::parse_request), but WP isn't designed to be re-entrant, so we'll undoubtedly run into issues here if we support it through batch requests (and we should if it exists).
We're going to punt deciding this one for now. Themes can register extra data they need for posts for now, and we can look at codifying this later.
One thing I wanted to add, hopefully usefully, is that while body_class and post_class are presentational, they are functionally required for many WordPress plugins to work correctly. The default classes added by WP are often leveraged by plugins for contextual styles and scripts, so if there's any idea that we could or should be able to write compatible themes using the WP API we would need this data somehow.
