-
Notifications
You must be signed in to change notification settings - Fork 308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rethinking slugs #806
Comments
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. |
+1 for this insight.
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)) |
Slug styles specify how slugs are turned into file and directory names in the URL path. This is roughly based off the design in lektor#809 (comment). As is, this PR fixes lektor#344 and deals with the tricky "global" part of doing lektor#809 properly. It also enables pages with dots in their slugs to be paginated and fixes some issues with the dev server resolving descendants of such pages incorrectly. It is still a prototype, though (I have only done some casual manual testing and yet to write any tests). In addition to a sitewide default setting and per-page setting, we would likely also want datamodels to be able to specify the slug style of their pages and/or their child pages. To stay similar to the current way `slug_format` can be configured, it seems we should also allow datamodels to specify the slug styles of their children, but as mentioend in lektor#806 that behavior is a little strange and worth reconsidering, so this PR doesn't try to implement any such behavior.
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
;slug_format
is child-based;1.
slugify
is applied indiscriminatelyDebatably, slugify should really not be applied in most cases:
_id
? It is, after all, a valid filename since it lives on a filesystem.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-basedThis 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.
The text was updated successfully, but these errors were encountered: