[wp-trac] [WordPress Trac] #41145: REST API permalink queries

[WordPress Trac]

#41145: REST API permalink queries
-----------------------------+-----------------------------
 Reporter:  johnhhorton      |      Owner:
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  REST API         |    Version:
 Severity:  normal           |   Keywords:
  Focuses:  rest-api         |
-----------------------------+-----------------------------
 '''Issue:'''[[BR]]
 In an SPA theme build, it's possible to query a post/page by ID or slug.
 If a user is starting from a single entry point, it's possible to
 explicitly create routes and menus in the JavaScript framework, and have
 them point to other views/resources.  While the page is setup, the front
 end already has all the IDs it needs.

 In a situation where a user navigates a fresh tab to
 website.com/blog/2017/06/(or some other structure), the front end
 framework would have to parse the url to understand what the user is
 trying to do. This is an issue for things like a search page, archives,
 cpts, etc. While it's possible to hard code, or even pass routes at load
 time to the JS framework's routing system and route analysis functions, it
 would be much better to create an alternate method of querying for urls.

 '''Possible solution'''
 In my setup, I solve this by:
 index.php loads for any request
 Front-end uses a wildcard for all front-end routing
 Front-end Passes the current url to a custom rest-api endpoint before
 loading content
 Custom endpoint runs a query on the url provided (sample code below)
 Custom endpoint returns the entire query object back to the front-end
 Front-end converts all received content's anchor tags to <router-link>s
 Front-end determines which view template should be used based on the query
 object
 Front-end passes posts array to the chosen view template
 Front-end displays appropriate template for the content (page, post,
 custom page template, cpt archive, archive, search, 404, etc)

 (repeat for following page requests)

 In this scenario, WordPress is given control of ALL routes and template
 decisions(though templates aren't the baked in controls due to lack of
 customizability). A simple url querying endpoint returns all needed data
 to display a view on initial page load, as well as following page loads,
 using the permalink structure already in WordPress.

 {{{
 #!php
 //Example query before performing additional rest-api controller
 modifications
 global $wp;
 global $wp_query;
 $path = $request->get_param('path');
 $_SERVER['REQUEST_URI'] = $path;
 $wp->parse_request();
 $wp->query_posts();
 $posts = $wp_query->posts;
 //The query could be condensed into a cleaner format
 //Posts are passed through the normal rest-api controller functions
 }}}

 Overall this feature would allow for more simplicity on the front end,
 while letting WordPress keep all of the administrative power it's used to.
 Changes to the back-end wouldn't break any hard coded values in the front-
 end (like I've commonly seen in tutorials).

--
Ticket URL: <https://core.trac.wordpress.org/ticket/41145>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform