Rethinking slugs

[xlotlu]

There are a number of issues with slugs in their current embodiment, I'll list them here and discuss them in detail afterwards:

• slugify is applied indiscriminately, even to a manually-set _slug;
• we don't have a simple way of generating slugs from fields;
• we don't support a per-model slug strategy, slug_format is child-based;
• there's no way to specify whether a record should be rendered as a directory or as a file;
• slugify isn't configurable, to e.g. allow uppercase or unicode characters.

1. slugify is applied indiscriminately

Debatably, slugify should really not be applied in most cases:

• we second-guess the user's choice by slugifying a manually-set slug - this is silly, the user knows better than an automated script. A side-effect is that it's impossible to use upper-case slugs (see Switch to slugify breaks slugs using .html #795, which has been closed).
• should it really be applied to _id? It is, after all, a valid filename since it lives on a filesystem.
• should it be applied to slugs generated from slug_format? It's not much different from second-guessing _slug.

2. Can't generate slugs from fields

Perhaps the most likely application for slugifying is to turn a field, e.g. title, into a slug. This is particularly useful for multi-language sites.

We currently don't support this in a straightforward way: while it's possible to use a custom slug_format for children, I think to actually accomplish this task would also need to install lektor-slugify.

3. slug_format is child-based

This makes little sense for people coming from other frameworks, and from a data-structure standpoint too, as it forces the parent model to be aware of the children's fields.

slug_format should be model-driven instead, and we should consider if the current behaviour is desirable (to be able to override it on a per-parent basis).

4. Can't specify if a record should be rendered as a directory or as a file

This is captured in #344. In appearance it isn't directly related to slugifying, but it does touch the same code-path.

Currently it is kinda messy: if the slug contains a dot and what comes after it doesn't contain whitespace, then it's considered to be a file.

5. Make the slugify behaviour configurable

This is already captured under #668 (and #795). Ideally it would be fixed along with the other issues above.

[nixjdm]

I think it's worth pointing out that right now getlektor.com's lektor-tags config ini file uses lektor-slugify to get case sensitive slugs for tags. I think this is an interesting example, since it is using it in an ini file, and not a normal template. I think there's some overlap between this issue and #805.

[xlotlu]

I think it's worth pointing out that right now getlektor.com's lektor-tags config ini file uses lektor-slugify to get case sensitive slugs for tags.

+1 for this insight.

I think this is an interesting example, since it is using it in an ini file, and not a normal template. I think there's some overlap between this issue and #805.

And a good case-study too, in deciding whether one prefers

url_path = {{ this.parent.url_path }}tag/{{ tag|slug(lowercase=False) }}

or

url_path = "{}tag/{}".format(this.parent.url_path, slug(tag, lowercase=False))