Redirects

Add a feature to tell Lektor that one url_path should redirect to another path (either a source path or a url path).

Why does this need to be in Lektor core? Because different publishing targets configure redirects in different ways. On GitHub Pages, for example, only HTML meta-refresh redirects are possible. With surge.sh, the redirects can be listed in a top-level file called REDIRECTS. With Apache, each directory’s redirects are listed in an .htaccess file, and so on.

Since the implementation of redirects varies according to publishing target, publisher plugins need a consistent way to read the list of redirects. Therefore I think redirects should be in Lektor core.

Proposal:

1. Redirects can be listed in the project file:

[redirects]
/foo /bar
/one /two 307  # specify the HTTP code
/old source("new")  # specify a source path which will be urlized

Combining this with “alts” might be a little tricky.

2. The dev server implements redirects when you preview your site.

3. The standard publishing targets implement HTML meta-refresh redirects: at each url path that must be redirected, a minimal index.html is generated with:

<meta http-equiv="refresh" content="0; url=/target/" />

4. You can pass a command-line argument to a publisher, or configuration in the project file, to tell the publisher to use an alternate implementation. For example if you’re SFTPing to an Apache server’s /var/www/, the publisher should generate .htaccess files instead of HTML redirects.

lektor deploy --redirect-type apache

5. Publisher plugins can read the list of redirects and the redirect options and make choices about how to implement redirects.

[jordanlev]

I understand that different build targets handle redirects in different ways, but if the “meta refresh” tag is sufficient, it might be worth documenting this very straightforward method of implementing redirects in the CMS (which doesn’t require any new functionality):

1. Create a new model redirect.ini, with 1 field for the redirect target:

[model]
name = Redirect

[fields.target]
label = Redirect Target
type = url

1. Create a template for the model that does not extend your design layout, but instead only contains this one line:

<meta http-equiv="refresh" content="0;url={{ target }}">

Now you can just add new “pages” of this model type in your sitemap – very simple, and should work 99% of the time (until the more robust feature mentioned in this github issue is implemented).

[xlotlu]

For local assets it makes sense, but sometimes you might want to reditect to an external page because reasons…

I think external redirects and internal redirects are different use-cases.

External redirects seem to me “content items”, which are best served by @jordanlev’s approach above with a custom model.

Internal redirects on the other hand are metadata of existing content. (“This is content that moved around”, or “I want this short url for the current page”). Using a separate model is messy, like @adrianharabula noted, and one could also make the case it’s structurally incorrect – you lose the relationship between the source url and the target node.

If someone creates a plugin that generates simple html files with meta refresh that would definitely be useful. After that proof of concept, it probably would be a good addition to core, with the note that then we’d have to support pluggable backends to generate .htaccess or nginx confs or whatnot.