Lektor: Redirects

[ajdavis]

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.

[mitsuhiko]

This also means looking into building for different targets which is not supported yet. I want to figure out how to achieve that. This would tremendously help with staging vs production as well. I will open an issue for this.

[mitsuhiko]

So ideally the way this probably works is that each deploy type sets up a "environment type" and then all enabled deploy types' environment types are built automatically.

Not sure what the build path looks like then. Maybe the build folder contains sub folders for each deploy type and hardlinks on unix for the same files? Maybe differences go into .lektor/envs/TYPE and are copied out on deploy? That seems inconvenient though for script based deploys.

Might need some good ideas there.

This does not just apply to redirects, also to 404 pages and things of that sort.

[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).

[adrianharabula]

Problem with the method above is that it is bloating the root folder of the project with fake page folders that represents just redirects. Also it is not very efficient if you have 3-5 redirects for a single page, as you will have to update redirects from all 3-5 locations.

Jekyll has already a nice way for redirects https://github.com/jekyll/jekyll-redirect-from#usage

[xlotlu]

This is totally doable in a plugin. Also, the jekyll approach seems rather sane (setting the redirects on the target object itself).

I'd say that a plugin is preferred to core, precisely because of the multitude of deployment possibilities. Core shouldn't care about these, unless it also provides an API for alternate redirection-handling backends to hook into.

[goanpeca]

This is totally doable in a plugin. Also, the jekyll approach seems rather sane (setting the redirects on the target object itself).

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

[ajdavis]

FYI, I've migrated from Lektor, feel free to close this ticket if it's not in the project's roadmap.

[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.

[xlotlu]

FYI, I've migrated from Lektor, feel free to close this ticket if it's not in the project's roadmap.

@ajdavis thanks, though this is definitely a nice-to-have so leave it open please. (Unsubscribe maybe?)