Closed richardhj closed 5 years ago
Sounds reasonable to me. Other opinions @terminal42/pilots ?
Do we need the COLLATE
setting? Because we don't really know the default collation, we just don't want it to be binary, right?
Do we need the COLLATE setting? Because we don't really know the default collation, we just don't want it to be binary, right?
I cannot answer this.
I just rethought the 255 char limit. When someone decides to uninstall mailusername
he will probably get problems when all usernames get truncated to 64 chars, didn't he?
yeah, but not increasing it would not really be a solution either, because they can enter longer emails than usernames can support…
Do we need the COLLATE setting? Because we don't really know the default collation, we just don't want it to be binary, right?
@aschempp Your concern still present?
Maybe it would rather be correct to *limit e-mail to 64 chars like the username is? By just setting maxlength
?
Will do.
Do we want to change the database length? This could potentially result in data loss. My idea was to only limit the input length 😇
This is what I did :) The length of the username is 64
as per Contao default. I added a soft limit for the email as well.
why the $GLOBALS['TL_DCA']['tl_member']['fields']['username']['sql'] = "varchar(64) COLLATE utf8_general_ci NULL";
then?
Emphasis on the "ci". We want the email to be case-insensitive.
Ah, very well then 👍
It is a well-discussed topic in the Contao community and I wonder how it didn't get onto GitHub. In all projects with mailusername users cope with problems according the case-sensitive email address. Some users lock out of their account. So I propose to treat the username as case insensitive by altering the sql definition. The modified sql definition will