frontity / docs

Frontity Docs/Guides

Home Page:https://docs.frontity.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add documentation for the 3xx Redirections

michalczaplinski opened this issue · comments

Feature Discussion: https://community.frontity.org/t/301-redirects-stored-in-wordpress-database/3032/

Pull request: frontity/frontity#601


We have added support for 3xx Redirections that are stored in the WordPress database. Such redirections can be added for example via the popular Redirection plugin.

Until now, Frontity was not able to handle such redirections because they are not exposed in the REST API. Thus, if for example a post slug has changed, Frontity would not be aware of that change and just return a 404 when trying to fetch the "old" post.

The general mechanism of how we solved it is this: Frontity makes an additional request to the WordPress "front-end" in order to check if there exists a 3xx redirection. For example, let's assume our site is https://mywpsite.com. If we try to fetch the post with slug /old-post, but it returns a 404, then Frontity, makes a request directly to https://mywpsite.com/old-post to see if there exists a 3xx redirection to a new post.

The API exposed to the user is just a single property: state.source.redirections which can have one of the following values:

  • "no" - Does not handle the redirections at all. This is the default.

  • "404" - Only send the additional request to the WordPress instance if the original request has returned a 404 error. This is the scenario described above.

  • "all" - Always make an additional request to the WordPress instance to check if there exists a redirection. This means that for every single actions.source.fetch() there will be a parallel request to the WordPress server that is fired "just in case" the actions.source.fetch() returns a 404. If the actions.source.fetch() is successful, the result of fetching the redirection is discarded. If actions.source.fetch() fails, Fronity waits for the response from fetching the redirection and if that is successful, uses it's result.

  • string - A string that contains a regex pattern. The string must start with "RegExp:". This pattern will be matched against the current route and if matched, Frontity will make an additional request to the WordPress instance to check if there exists a redirection. Note that the shorthand character classes will have to be escaped, so for example instead of \d, you will need to write \\d.

  • string[] - An array of strings, which can contain the "404" value as well as any number of strings starting with "RegExp:/" which represent regular expressions. An additional request will be sent to Wordpress to check for the redirection if any of the regular expressions match the current route. If the array also contains a "404", an additional request will also be made if the original request has returned a 404 error.

Some example valid values are:

  • "no"
  • "all"
  • "404"
  • "RegExp:/some-post/(\\d*)"
  • "RegExp:/post-(\\w*)/(\\d*)"
  • ["404", "RegExp:/some-post/", "RegExp:/another-post"]

Although the default setting for this is "no", I think our recommendation should be "404", so maybe it makes sense to add it to our official themes. WordPress creates a redirect automatically by default when you change the slug of a post or a page, and this use case would be handled with the 404 option. That's why I say I think it should be our recommendation.

Btw, I explained more about this in the demo video.

FYI: @michalczaplinski will write down a Final Implementation to sum up everything related to this feature. Michal, could you please post the link here once it is ready?

Closed due to #282 and frontity/api-reference#28 being merged