Whatever a custo install profile does, the installer forces the user_email_verification setting to TRUE regardless in its configure form submission callback. The .install files for profiles run before this configuration form, so it is not possible to fix this from there. It might be possible to add a custom submission callback after the core one for the configure form, but hacking around core because it overwrites what an install profile set is not a good idea.

Instead let's look up, whether there was a setting already stored (but still default to TRUE, if not). If there was, restore that setting later. We could complicate this code a bit more if wanted. If $user_email_verification is FALSE, none of the variable_set()s are actually useful (both of them will set to FALSE a value which is already FALSE). That would add 4 more lines of code, and this only runs once in the installer, so I think code brevity above runtime wins here.

CommentFileSizeAuthor
#4 installer-email-verification-752814-4.patch1003 bytesDavid_Rothstein
install-email-verification.patch1.02 KBGábor Hojtsy
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

The fact that we do this variable munging at all here seems like a total hack, probably dating back to Drupal 2 or thereabouts :) Is it really necessary at all? I can't see why it would be.

I think we should try just deleting those variable_set()'s and see what happens...

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

Haha, uid1 will get an email and be required to validate his account before being able to log in?

Gábor Hojtsy’s picture

Gábor Hojtsy
he/him
Primary language Hungarian
Location Hungary
CreditAttribution: Gábor Hojtsy commented

A safer hack could be to munge with global $conf instead of setting the variable permanently.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
FileSize
installer-email-verification-752814-4.patch1003 bytes

We can simply remove it, as in the attached patch.

I've tested this with the standard install profile, as well as with the standard install profile modified to set variable_set('user_email_verification', 0);. Everything works fine in both cases.

There is further cleanup we can do in this area of the code (all the $form_state['old_values'] stuff is weird and no longer necessary either...) but that can be saved for another issue.

Status: Needs review » Needs work

The last submitted patch, installer-email-verification-752814-4.patch, failed testing.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented
Status: Needs work » Needs review

#4: installer-email-verification-752814-4.patch queued for re-testing.

JacobSingh’s picture

JacobSingh CreditAttribution: JacobSingh commented
Status: Needs review » Reviewed & tested by the community

Yeah, this looks right to me. We don't get affected by verification because we sending status => 1 into user_save, we're not submitting the form or anything. Maybe that's a legacy bit of code from a drupal_execute or a bad API?

Dries’s picture

Dries CreditAttribution: Dries commented
Status: Reviewed & tested by the community » Fixed

Committed to CVS HEAD. Thanks.

David_Rothstein’s picture

David_Rothstein CreditAttribution: David_Rothstein commented

The further cleanup I mentioned above ($form_state['old_values'] and such) now has a patch here:
#790832: install_configure_form_submit() unnecessarily mangles the $form_state array

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.