Tags with capital letters cannot be listed

[tchebb]

So there I was, adding tags to my records. These tags in particular listed the web technologies used for a given portfolio entry, so naturally I used the correct capitalization of each technology (PHP, Ruby, Bolt, WordPress, etc). The admin panel was perfectly happy to let me enter these tags, and even gave suggestions with the correct capitalization. After I finished adding the tags, I went to see how it looked, and, much to my surprise, I was shown the error Content for 'technologies/PHP' not found.

It appears that Bolt treats tag names as slugs and consequently passes them through makeSlug() as part of getContentByTaxonomy(), downcasing them in the process. So /technologies/PHP was equivalent to /technologies/php, which, of course, didn't exist.

I can think of a few ways to make this less confusing, but none are optimal. The first is to lowercase all tags in the admin panel. This removes all confusion about valid names and lets Bolt keep treating tag names as slugs, but, as in my case, there are times when capitalized tag names are desirable.

The second way is to stop treating tag names like slugs and search for the tag exactly as it appears in the URL. This is sub-optimal in a couple ways: first, I assume there's a reason that slugs have the constraints they do and that removing those constraints would cause all sorts of problems. Second, the user could create multiple tags of the same name with different capitalization and they wouldn't be linked together, causing more confusion (although this can be done now; anything other than lowercase names just won't work).

The last way is to convert tag names to slugs to be used in the URL but to also keep track of the properly-capitalized name in the database. Each tag would have a canonical capitalization, and the admin panel would automatically correct any non-canonical capitalization. This wouldn't have the problems of either other solution, but would require extra infrastructure in the backend (I don't know how much) and also, ideally, an interface for the user to change the canonical capitalization of an existing tag.

Any of these solutions would be better than the current behavior, which displays a confusing and unhelpful error message to the user with no warning.

[bobdenotter]

With "categories" we already do something like this, in the DB: the 'slug' field has a sluggified version, while 'name' has a value that can have capitals and spaces. We should expand this to tags, IMHO.

Then, you can use 'PHP' as a tag, but the generated URL will stil be lowercase, as it ought to be: /technologies/php

If we made that change, that would solve your issues, right?

[tchebb]

Yeah, that solution would be ideal. I haven't dug into the Bolt code very much, so I wasn't sure how much work it would be to implement something like that. I assume there would have to be a new interface in the admin panel for letting users set a tag's 'name' with proper capitalization, since the tags aren't all predefined in taxononomy.yml.

[bobdenotter]

I don't think it will be that much work.. From the top of my head, it can be split in the following:

• Make the frontend controller (taxonomy() in src/Bolt/Controllers/Frontend.php) accept both 'php' and 'PHP'.
• Make the frontend controller search for the case-insensitive version (ie 'php', even if called with 'PHP'), and have it search in the db for the sluggified version.
• When editing a page and storing it, change the current behaviour to store the user-supplied version in the 'name' column and a sluggified version in the 'slug' column.

I assume there would have to be a new interface in the admin panel for letting users set

At first I think that's not needed. you said the backend already picks up the version with captialisation like you first supplied, so that should keep it from getting messy.

[tchebb]

Without a dedicated interface for it, there would really be no way to change a tag's capitalization short of untagging every record with that tag and retagging with the new capitalization, though, if I'm understanding this correctly. That seems like it would be a very frustrating limitation.

[bobdenotter]

Well, the same goes for "categories" and "groupings".. You can change them in the .yml, but you can't easily change the values of already created records. I fully agree that this would be a nice thing to have, but it isn't just because of these proposed changes alone that we would want to have it. :-)

[tchebb]

Fair enough. :) Apart from that, then, your proposed solution would resolve the problem fully. Thanks for your quick responses!

[bobdenotter]

Keeping #868 open, but closing this issue as part of our "spring cleaning", because there hasn't been any activity on this for a while now. If you feel this issue is still relevant, feel free to open it again.