Redirects can't override the / index view

[pushred]

There's sometimes a use case where it's desirable to temporarily replace a site's home page with an entirely different page or perhaps just a promotional variation of the page that is served on a different route.

One way of accomplishing this is to name the page that would otherwise be the index something other than index.hbs, and reserving the / route for a redirect that directs traffic there or elsewhere. This avoids the possibility of serving duplicate content, by giving the home page an otherwise permanent home. It's also possible to add triggers in the context with a preprocessor that activate for different ranges of time.

Redirects are a simpler way of achieving this that come with built-in scheduling by way of 302 redirects. I have some concern with the idea of a permanent 301 redirect at /, it's unclear what impact that may have on SEO. It's difficult for us to test this however as many of our sites have domains featuring prominent keywords, i.e. keithurban.net and bonjovi.com, that are linked to from all over the net. We could setup a site with a more obscure domain and see how it performs when crawled, but this issue is inconsistent with the rules for redirects otherwise so it seems fair to support it.

Given this redirects.json

[
    {
        "from": "/",
        "to": "/view1"
    }, {
        "from": "/view1",
        "to": "/view2"
    }, {
        "from": "/section/view1",
        "to": "/view1"
    }
]

• /view1, /view2, and /section/view1 have matching views
• /view1 overrides the view and redirects to /view2
• /section/view1 overrides the /section/index.hbs view and redirects to /view1
• / does not redirect to /view1

[pushred]

@krackydile says redirects that specify /index work.

[Fauntleroy]

It looks like this is due to the fact that routes aren't assigned in any particular order; setupViews and setupRedirects fire one after the other and are both async. Right now it looks like setupRedirects wins every time, so a potential solution is to just place setupRedirects in a callback after setupViews completes.

This would, in effect, make sure any routes set in redirects.json override normal routes.

[Fauntleroy]

So after looking at this more closely the REAL problem is that when pages are created, they check for existing routes and manually remove them from the stack, while warning the user. I should probably rethink the way routes are assigned and create a more cohesive approach (with fancier warnings and everything)