I would like to bring up the idea that Friendly Register doesn't like to adhere to the "validation criteria" when doing it's checks. I don't have a clue where to dive into the code to see how it's doing it's validation, but I'm guessing it is purely based off of a search on any existing database entries?

In trying the module out this evening, I noticed that Drupal core specifies validation criteria upon registration: Spaces are allowed; punctuation is not allowed except for periods, hyphens, apostrophes, and underscores.

However, you can enter any combination of letters, numbers, punctuation or characters and it will show the username as being validated. (see attached screenshot) I believe this will make things confusing for new users.

On a side note of this, the proposal has been made to the Password Policy folks, to branch off a 2.x version that will effectively make it's validation calls on a (yet to be designed) "Policy API" module.

The idea is to have the Policy API house all of the validation criteria for username policy registration (module that needs to be written) and password strength criteria (Existing Password Policy module) but allow other modules to tie into the API for validation as well, such as Friendly Register. You might get with the maintainers of Password Policy to see if they are interested in this sort of thing and collaborate efforts if you think it's worthwhile. It might make more sense to create the API module and tie FR into it when compared to proprietary custom validation policies that might not play nice with other modules

----

Finally, I would like to also propose a feature request to add a "warning" message if the username / email doesn't validate. Something along the lines of "Username is invalid: please check the validation rules and try again". In playing with Friendly Register, I've noticed that it's either happy, sad or indifferent, but most of the time happy (usernames) and indifferent (email address) I think a "cautious" might be in order if something is input but doesn't quite validate. Maybe use the upside down yellow triangle sign and only reserve the "Unavailable" red X for the pre-existing database entries.

Thoughts?

CommentFileSizeAuthor
User-account-sandbox7.jpg62.58 KBphilsward

Comments

philsward’s picture

I also just noticed that it will validate if the first character is anything BUT a hash #. That is the only character it seems to validate against.

andrew m riley’s picture

Assigned: Unassigned » andrew m riley

Thanks for the info Phil. I'm going to keep an eye on the submodule for Password Policy. You are correct, the module is pretty much 60% happy, 30% indifferent and 10% unhappy. This is mostly by design due to how Drupal currently validates the fields. The core Drupal validation is pretty open and I've made this module in a similar manor so it matches up (don't want to give false negatives). I do really like the idea of hooking into a contrib module that could be more restrictive though.

I am going to double check on the user name validation that Drupal does to make sure I am in line with that.

philsward’s picture

Sounds good, I think the primary maintainer is very open to the idea of an API approach to allow other modules. Hopefully it works out!

philsward’s picture

Issue summary: View changes

added link to username registration request

andrew m riley’s picture

I'm in the process of adding hooks to allow people to hook up extra modules or write their own validation code.

I'm still working on documentation but the hooks are:

hook_validate_email_address($address)
hook_validate_user_name($name)

Note: The commit above is incomplete

  • Andrew M Riley committed 0cea7eb on 7.x-1.x
    Revert "Issue #1513156: Follow Validation Rules"
    
    This reverts commit...

andrew m riley’s picture

Status: Active » Needs review

Code has been committed. Please give the new hooks a shot from the next development build.

andrew m riley’s picture

Version: 7.x-1.x-dev » 8.x-1.x-dev

Bumping to 8.x for porting now that it's in for 7.x

emilymoi’s picture

Thanks for the hooks. I came here specifically wondering why there weren't any hooks in 1.1. Nice work :)

emilymoi’s picture

Actually just noticed a critical bug in 1.2 that prevents it from working at all. #2494273: Bug in friendly_register.js checks if data.available evaluates to true instead of IS true