Make the named frontend routes customisable

[ErisDS]

In core/server/routes/frontend.js there are a number of named routes which use English words including tag, author and page. These need to be abstracted out so that they can be customised for two reasons:

1. translations: when we support i18n properly, we'll want to allow users to translate those words
2. flexibility: if you're running a music blog, you might want the route to be /genre/ rather than /tag/, and perhaps you'd rather the route be /by/ rather than /author/.

At the moment, these routes are hardcoded strings repeated multiple times through the codebase, and depended upon for creating logic elsewhere in Ghost.

This needs to be abstracted out into information that can be used to dynamically build the correct routes and assign the right context.

Notes on refactoring

At present there are effectively 3 main contexts which have a top-level route, and a set of subroutes.

• index - lives at /
• tag - lives at /tag/:tag_slug/
• author - lives at /author/:author_slug/

All three of these have the following subroutes:

• / - the first page of results
• /page/:page_num/ - subsequent pages of results
• /rss/ - the first page of the RSS feed
• /rss/:page_num/ - the subsequent pages of the RSS feed

Also note that at present /feed/ is an alias of the base/index /rss/ route only, when in fact feed should probably be an alias anywhere where rss is used, and should always 301. I can imagine Apps reasonably wanting to specify other aliases for this.

Fundamentally, the main thing we need to achieve is making it possible to replace the words tag, author and page with other words without things breaking, the other information here is intended to paint a bigger picture of what this refactor needs to move us towards.

[mattiascibien]

Could it be an idea to include them in config.js or should them be made in the DB with a UI like tag management one?

[ErisDS]

Eventually we'll move these properties out to the settings or perhaps somewhere else - but for now it doesn't matter - what this issue covers is refactoring the code so that these properties are set in one internal location :)

[mattiascibien]

So I'll give this issue a try. Thanks @ErisDS

[katiefenn]

@mattiascibien @ErisDS I'm interested in taking a fresh look at this if there has been no recent developments.

[mattiascibien]

@katiefenn did not had time to work on this. :( you can have a look.

[katiefenn]

Are hard-coded URLs in themes within the scope of this refactor?

For example, take tag RSS subscription links in Casper:
https://github.com/TryGhost/Casper/blob/master/tag.hbs#L8
The "tag" keyword is hardcoded, and would break if a tag keyword setting were changed to "genre".

It seems a change to the template is, strictly speaking, outside of the scope of Ghost itself. But should I consider how best to expose a keyword setting to theme templates?

[novaugust]

For themes to be able to route to customized front-end urls, ghost is going to need to add a new {{url-for}} helper that looks up these customized routes.
I'd say that's outside the scope of any PR against this issue, but thanks for bringing it up. We'll have to make a new issue for it, and add all the necessary docs to go along with that :)

[ErisDS]

@katiefenn agreed, that's definitely not in the scope of the refactor - also the Casper theme can be updated to use the {{url}} helper to achieve the same thing without hardcoding. I'll update this by way of an example to other themes.

[katiefenn]

@ErisDS @novaugust Thank you for the feedback. I'm getting ready to create another PR (compare), and wanted to first check that the refactor matches what was asked for:

• I've added the route keywords tag, author, and page to the config manager.
• Refactored hard-coded instances of the keywords to build strings using configured keywords
• Added keywords to stub config in unit tests.

There are things which I could use some feedback on:

• Naming of config properties (eg. config.routeKeywords.tag) - could perhaps be simpler.
• Placing keywords in config. I've concentrated on refactoring the hard-coded strings and put the keywords in config for convenience. If there is a better place, I can move them.

[novaugust]

That compare looks sensible to me. It'll probably be easier to get feedback on the PR if you just open it up :)