eleventy
eleventy copied to clipboard
11ty
Case sensitivity of individual `tags` entries
Related docs: https://www.11ty.dev/docs/collections/
Aggregation issue for this!
Specifically, when assigning:
tags:
- JavaScript
tags:
- javascript
Right now the above two documents create two separate entries in the collections object. This causes further issues if you have pagination templates with something like: permalink: /{{ alias.tag | slugify }}/
Both slugify and slug filters change the strings to lower case.
- https://github.com/11ty/eleventy/blob/d082ead95ec6d53a4dfffd901941527bb09fcdb5/src/Filters/Slugify.js
- https://github.com/11ty/eleventy/blob/d082ead95ec6d53a4dfffd901941527bb09fcdb5/src/Filters/Slug.js
This will throw a duplicate permalink error!
My hunch is that it’s obtrusive enough that I think we should slow play this with some kind of configuration API opt-in. Then we can swap the default value of this method with a major release and it will also allow folks to opt-out of the behavior later if they’re relying on it.
Community discussion:
- https://github.com/11ty/eleventy-base-blog/issues/89 has the additional concern of whitespace in the tags.
- https://github.com/11ty/eleventy/issues/2166#issuecomment-1067749664 had some really great thoughts
- This discussion https://github.com/11ty/eleventy/discussions/1461 has the most comprehensive discussion on it
- Wanted to specifically highlight this comment from @johnridesabike about an
onCreateTagnormalization callback https://github.com/11ty/eleventy/discussions/1461#discussioncomment-241545
Like many people I've hit this problem before. I fixed it by manually extracting tags from all my pages and sorting them to show similar tags, before going back in and letting me set which version I want to keep. It was hard.
The problem with doing this automatically is you won't get the case right for display. You need to preserve the user-input version to preserve quirks like McDonalds, acronyms like NFT or anything else that doesn't lend itself to a title filter.
My preference here is a build time warning that identifies clashes and their documents so users can standardise on the version they want to keep.
I've hit this one too before.
If I'm not mistaken, this works if you don't use the slugify filter for your links. Nonetheless I have reasons for flatout directly changing the behavior and not doing it.
- Windows does handle paths case insensitive, so on windows the two paths are the same even without slugify.
- An added config option to opt in would ease transition (like you mentioned)
Since all users already have to handle the current behavior, I think it's okay to use the second option to introduce a new API/config for this.
Had to face quite some times the same kind of trouble, and French authors with their accents never helped 😄 But I believe we are mixing 2 different troubles:
- "lowercasing" & tags: That's impossible and not a good idea. As said before, "Bush/bush" are not the same tag, "javascript/Javascript" could be but not "JavaScript", and in French "été/ete/summer" are clearly different tags again!
- Slugs now: Here is the real trouble. Even if we wanted we could not keep some of the differences.
I could imagine a slug function, warning when transforming a different input to the same result!
I don't have a strong opinion as what should be the default, but I've encountered duplicate permalinks. I've mostly made content updates to fix this, since in my case, they were actually the same thing. It would be nice to have the option either way.
Honestly I always assumed that tags were case-insensitive. The fact that that "HorseBoy" and "horseboy" are considered different tags is confusing for anyone coming from wordpress or some other where tags are case-insensitive. It feels like it would make for more accidents than anything.
Is there an example somewhere of modifying the tags example (https://www.11ty.dev/docs/quicktips/tag-pages/) to slugify the tags before generating the page, or is there something I need to modify in .eleventy.js to change the nature of the collection?
I'll note that whatever solve for this comes, it would be very useful if it could also support fixing tags that need to be .trim()ed, as those will generate the same issue.
