Problem/Motivation
The main form_alter of this module persistent_login_form_alter() determines _inside_ when it will be applied. This makes it impossible to re-use the function for forms that have a different name scheme.
I created an alternative login form that will be placed inside the main navigation menu with a form ID of 'example_user_menu_login'. To apply the persistent login's form alter on this I have to either rename it, which violates the namespace of the user module.
Proposed resolution
Rename the form alter and use a hook_form_FORM_ID_alter(). This is also better for performance. Any other form that wants to re-use the persistent_login functionality can call persistent_login_form_user_login_form_alter()
| Comment | File | Size | Author |
|---|---|---|---|
| #2 | persistent_login-reuse-form-alter-2934046-2.patch | 893 bytes | sutharsan |
Comments
Comment #2
sutharsan commentedComment #3
gappleI'll have to think about this some more.
As the commented out code indicates, the alteration will also need to be applied to the registration form (and potentially others, per #2863067: Make module compatibile with login substitutes). I think the actual form changes should be moved to a utility function, called by each of the necessary alter hooks.
If Persistent Login implements
hook_form_BASE_FORM_ID_alter(), and your form declaresuser_loginas it's base form, the alterations should be automatically applied.Comment #4
sutharsan commentedOf course, a separate utility function is the better solution. You can even move the utility to a class with static methods.
Can you explain this or give an example in existing code? I currently create a new form that _extends_ the user_login form class and overrides the
getFormId().Comment #5
gappleI've opened an issue against Fancy Login module as an example of using BaseFormIdInterface: #2934251: Implement BaseFormIdInterface in FancyLoginLoginForm
This issue should be resolved with the change commited for #2863067: Make module compatibile with login substitutes