Fixed Option ID duplicate check needs to be case-sensitive

tyteen4a03

Well-known member
If you attempt to change the casing of Option IDs (e.g thisismyid to ThisIsMyID), the system will tell you that that ID is already in use.

So far I can reproduce this behaviour in Option IDs and Addon IDs, I think it's universal.
 
Strings are considered case insensitive by MySQL, so to properly 'fix' this, you'd have to do a lot of table editing. Not saying this couldn't be improved (see which phrase you are editing and see if the IDs match and just switch to newIdSyntax), but mentioning why its happening.
 
Strings are considered case insensitive by MySQL, so to properly 'fix' this, you'd have to do a lot of table editing. Not saying this couldn't be improved (see which phrase you are editing and see if the IDs match and just switch to newIdSyntax), but mentioning why its happening.

Google gives me this:

Code:
SELECT * FROM `table` WHERE BINARY `column` = 'value'
 
Google gave me something different (defining things as Binary in the table). It may prove troublesome in the code, but then again variables in PHP are case sensitive. Personally, I think the way it works now is correct because it can cause ambiquity:

superCoolAddonPaypal and supercooladdonpaypal

Do they refer to the same thing or something else entirely? But I do agree you should be able to change case and not have it yell at you.
 
Google gave me something different (defining things as Binary in the table). It may prove troublesome in the code, but then again variables in PHP are case sensitive. Personally, I think the way it works now is correct because it can cause ambiquity:

superCoolAddonPaypal and supercooladdonpaypal

Do they refer to the same thing or something else entirely? But I do agree you should be able to change case and not have it yell at you.

I would assume they are treated differently because they allow capital letters. No point allowing two cases without being able to differentiate between the two.
 
I would assume they are treated differently because they allow capital letters. No point allowing two cases without being able to differentiate between the two.

They would be treated differently. :) I think XenForo properly makes these case insensitive to avoid ambiguity (do I want the all lowercase on-off option or the camel case one?). I think your bug more or less relates to the fact that it won't let you change the case after the initial creation. If that's the case, the field shouldn't be editable.
 
Just moving this to a future version. It's reasonable to fix itself, but it starts exposing other issues related to phrases so it needs a careful pass on the schema.

As it's easy enough to workaround (rename from xyz to xyz1 then to XYZ), we'll look at this in the future.
 
Just moving this to a future version. It's reasonable to fix itself, but it starts exposing other issues related to phrases so it needs a careful pass on the schema.

As it's easy enough to workaround (rename from xyz to xyz1 then to XYZ), we'll look at this in the future.

Is this fixed in 1.2.0 Beta 2?
 
Top Bottom