search

ryelle / Foxhound

A text-focused blog theme for WordPress (in React)
https://themes.redradar.net/foxhound
349 stars 39 forks source link

Allow arbitrary permalinks #88

Open iandunn opened 7 years ago

iandunn commented 7 years ago

I think Foxhound is an awesome theme and a big step forward for the entire WP theming community, kudos!

It seems like one of the major challenges that still needs to be solved is allowing the user to set arbitrary permalinks. I don't have a solution for that, but I figured I'd start an issue so we can all brainstorm ideas.

I'm guessing the problem is that the JS client doesn't know which endpoint it should query for the data, because the only thing it knows is the URI. Are there any other problems besides that one?

My first thought on the unknown endpoint issue would be something like this:

  1. Setup a custom endpoint which receives a URI as a parameter, e.g., https://example.org/wp-json/foxhound/v1/uri/contact-us or https://example.org/wp-json/foxhound/v1/uri/2017/03/foo-bar
  2. That endpoint can look up the corresponding post/term/author/whatever data, and the appropriate theme template (single, page, archive, etc) using the same functions that WP does when it processes requests server-side.
  3. The endpoint could prepare the data using the corresponding API controller
  4. The endpoint could tell the client which template to use by sending a custom HTTP header, like X-Foxhound-Template

Another idea would be to have client make a request to https://example.org/wp-json/foxhound/v1/uri/contact-us/json or https://example.org/2017/03/foo-bar/json directly, and let WP do the normal work of looking up the data/template on it's own, but then have Foxhound hook in at template_redirect or earlier and prepare the data using the appropriate API controller, then output it with wp_send_json(). I'm guessing this would be slower than the custom API endpoint, but I haven't tested that.

I haven't tested either of those ideas, so there could be big holes in them, but hopefully it's enough to start a discussion that leads to something.

iandunn commented 7 years ago

I guess a third idea would be to try and mirror the functionality of WP::parse_request() in JavaScript, but that seems fragile and not future-proof.

cr101 commented 7 years ago

@iandunn Either the first or the second idea are worth considering. Ideally you don't want to recreate existing core functionality of WordPress in JavaScript.

iandunn commented 7 years ago

Possibly relevant:

iandunn commented 6 years ago

cc @danielwrobert, this is the issue we talked about last week.

#42465-core may be helpful here.