Strange behaviour into "Categories" creation pages #355

Let's make that readable. Now if only someone could explain what is meant here:

What steps will reproduce the problem?

• When we create a new category from the "Categories" back-office page, all entries are sanitized (spaces changed to dashes, uppercases changed to lowers) but this is not affected into the individual page (creation of an individual article category).
• Is that is normal, intended for some raisons?

What is the expected output? What do you see instead?

• Maybe the same traitment into the individual page context.

What version of the product are you using? On what operating system?

• Latest stable version 4.5.4.

Please provide any additional information below.

• none needed.

This has been partially fixed in later versions than 4.5.4 but still one inconsistency remains:

1. Create new Category called Tangerine Dream.
2. Edit that category. Note that its name has been sanitized to tangerine-dream (lower case, hyphens added).
3. Alter the name to Tangerine Dream and Save the changes.
4. Edit the category again. Name is now Tangerine-Dream (mixed case, hyphens added).

The hyphenation is re-applied, but lower case is not enforced on the Category edit panel. Not sure if this only affects capitalization or if other character sequences might need to be escaped.

It's just capitalization. During create there's a call to strtolower, which isn't done when saving an edited category. I'm not sure if this is a bug or by design (it gives the user freedom to have uppercase category names, while defaulting to lowercase)

I'm not sure either! Maybe we just leave this alone and close the issue. It's already inconsistent with other places that generate URL ornaments anyway:

• Section panel forces sanitisation + lower case when editing.
• Write panel sanitises + lower-cases on Publish (if url_title is auto-generated from the article Title) but doesn't sanitise the url_title at all upon subsequent edits: just urlencodes (I think, although that might be on output only).

But it's probably not that big a deal. There are probably other URL-based quirks elsewhere: Users? Files?

• Users: pretty much allows any input for both the login and the real name, but it does appear to be properly escaped/encoded everywhere.
• Files: uses sanitizeForFile during upload.
• Write: does sanitize url_title on subsequent edits, but only if it hasn't been customized and the article isn't live yet. Also it only sanitizes if the permalink_title_format pref is set.

Some consistency would be nice:

• always sanitize?
• force lower case (which probably doesn't work on UTF-8 chars with bit 8 set)?

This looks tricky. Most db servers use case-insensitive collations by default, so, say, Category1='aNiMaLS' db query matches animals category which is thus accessible via ?c=aNiMaLS URL. But internally core caches some data, to avoid multiple db calls. Say, sections data is stored in $txp_sections array of $name => $data pairs. When txp sees ?s=aRTiCLeS URL, it checks whether $txp_sections['aRTiCLeS'] is set and issues a 404, since the section is actually named articles (lowercase).

Dunno what's the best way to make things consistent between db and php storage.