Using periods "." in login name (username)
Permalink 3 users found helpful
Hey all,
Just updated one of my clients from 5.3.x to the newest 5.4.0.5. I guess in that time, username rules have changed, though because now when they try to add new users under the naming convention [first-name].[last-name], the system throws up an errors saying that letters and numbers are the only characters allowed. This was not the case for 5.3.x versions of Concrete because they have over 600 users in the system who are setup with first-name.last-name and they would prefer not to change everyone now. They are using C5 for an employee portal.
I am curious why this changed? I am also curious if something will break if I overwrite this behavior (which I have already done).
I was able to fix the issue by removing validation.php in concrete/helpers/concrete/validation.php and adding a copy of the file to the helpers/concrete/ folder. I copied the original file and only modified one line from:
to:
(note the addition of the period "." in the preg_match expressions.
The only problem I came across with my solution is that if I left both the original validation.php and the new validation.php intact, they threw up a "cannot redeclare class" php error. So, I renamed the system's validation.php to validation-old.php and everything worked correctly. Is there a better way to do this? Is there a reason why usernames should not have periods?
Just updated one of my clients from 5.3.x to the newest 5.4.0.5. I guess in that time, username rules have changed, though because now when they try to add new users under the naming convention [first-name].[last-name], the system throws up an errors saying that letters and numbers are the only characters allowed. This was not the case for 5.3.x versions of Concrete because they have over 600 users in the system who are setup with first-name.last-name and they would prefer not to change everyone now. They are using C5 for an employee portal.
I am curious why this changed? I am also curious if something will break if I overwrite this behavior (which I have already done).
I was able to fix the issue by removing validation.php in concrete/helpers/concrete/validation.php and adding a copy of the file to the helpers/concrete/ folder. I copied the original file and only modified one line from:
public function username($username) { $username = trim($username); if (strlen($username) < USER_USERNAME_MINIMUM) { return false; } if(USER_USERNAME_ALLOW_SPACES) { $resp = preg_match("/[^A-Za-z0-9 ]/", $username); } else { $resp = preg_match("/[^A-Za-z0-9]/", $username); } if ($resp > 0) { return false; } return true; }
to:
public function username($username) { $username = trim($username); if (strlen($username) < USER_USERNAME_MINIMUM) { return false; } if(USER_USERNAME_ALLOW_SPACES) { $resp = preg_match("/[^A-Za-z0-9. ]/", $username); } else { $resp = preg_match("/[^A-Za-z0-9.]/", $username); } if ($resp > 0) { return false; } return true; }
(note the addition of the period "." in the preg_match expressions.
The only problem I came across with my solution is that if I left both the original validation.php and the new validation.php intact, they threw up a "cannot redeclare class" php error. So, I renamed the system's validation.php to validation-old.php and everything worked correctly. Is there a better way to do this? Is there a reason why usernames should not have periods?
Ditto your comment - in my opinion you should be allowed "." or "-" i.e. "Mary-jane"
yes, I also had the same problem with the '.', had to hack the code. this is very common practice in larger companies.
Yeah, I have a user with a hyphenated name, and I don't think she's overly fond of her user name having the two names pushed together.
It would be great if I could use dashes or hyphens in usernames.
It would be great if I could use dashes or hyphens in usernames.
Anyone else involved in the development know the answer to this?
I'm wondering as well - I have a lot of members with things like -= username =- that I would prefer to import with their real name...
I'd be curious as well, though for what it's worth the correct way to implement an override is to add helpers/concrete/validation.php which should extend the original, like such:
defined('C5_EXECUTE') or die("Access Denied."); class SiteConcreteValidationHelper extends ConcreteValidationHelper { public function username($username) { $username = trim($username); if (strlen($username) < USER_USERNAME_MINIMUM) { return false; } $resp = preg_match("/[^A-Za-z0-9-._]/", $username); if ($resp > 0) { return false; } return true; } }
I'm having trouble getting that working in 5.6.0.2. I always get something like:
Warning: require_once(/opt/mount/html/updates/concrete5.6.0.2/concrete/helpers/concrete_validation.php): failed to open stream: No such file or directory in /opt/mount/html/updates/concrete5.6.0.2/concrete/core/libraries/loader.php on line 279 Fatal error: require_once(): Failed opening required ...
Any clues?
Warning: require_once(/opt/mount/html/updates/concrete5.6.0.2/concrete/helpers/concrete_validation.php): failed to open stream: No such file or directory in /opt/mount/html/updates/concrete5.6.0.2/concrete/core/libraries/loader.php on line 279 Fatal error: require_once(): Failed opening required ...
Any clues?
It does work correctly with 5.6.0.2. What you need to do is copy the entire validation helper into /helpers/concrete/validation.php and the modify the appropriate function.
I also escaped the - with a \ since it's used for ranges and I wasn't sure that would work.
I also escaped the - with a \ since it's used for ranges and I wasn't sure that would work.
