On previous Drupal projects I've had the requirement to provide some sort of confirmation email to email addresses entered into an Email (module) field.  These were typically fields like "Work Email" or "Secondary Email".  I had written a few small custom modules to handle these cases but found myself repeating the same thing. I knew that this could be useful as a contrib but never got around to it.

I recently had a requirement to confirm email changes to the user account email (e.g. $user->mail). I went to my goto module for this situation, the Email Confirm module. But this time I decided to dive deeper into what Email Confirm was actually doing... and it looked fairly straight forward.  I was hoping that I could possibly extend this module to be used with an Email field, but that ended up not being the case.

So I decided to take the plunge and create the Email Field Confirm module. Boy was I in for a ride...

The Email Confirm module only works with the User entity which happens to have the $user->data property / db table. The module makes use of this to avoid any schema changes and retains the relationship of the new email address to the user account. I had started out down a similar path but came to realize this wasn't going to work for entities other than the User entity.  Node entities do not have the data property and I couldn't rely on other entity types to have it.  This is the point that I realized this was not going to be a simple module.

Time to really sit down and figure out what this module needed to do.

My goal was to allow for any new email address added to an Email Field to be (optionally) confirmed. A field can be reused on multiple entity types and bundles so I need to allow for configuration at the field instance along with storing any pending email address data down to the specific entity instance (e.g. entity_id). I also noticed that the Email Confirm module would stash the new email address away until it was confirmed so I added that to my list of desired features for Email Field Confirm.

Just tell me what it does already!

Features

At a high level, it met the goals I was after. A confirmation email will be sent to any new email addresses that have not already been confirmed by the same user elsewhere (e.g. another Email field) on the site. A field instance can optionally be configured to save the new email address with the entity or keep the original email address until the new one is confirmed.

This works on both single-value and multi-value Email fields, however there are some limitations with the multi-value field.

With multi-value fields it has proven more difficult to accurately identify what the original email value may be have been. I wasn't able to easily identify if the end user was changing an email address vs. just removing and adding another. It is also easy to re-order the values of a multi-value field so relying on the $delta wasn't helpful.

So with single-value fields we have the capability to retain the original email address until the new email address is confirmed. We also have the option to notify the original email address that a change has been made.

​

Some other notable features include:

• Ability to resend a pending non-expired confirmation email.
• Configure if the acting user (e.g. the user adding the email address) or the entity author/owner is responsible for confirming the email address.
• Hooks for email confirmation and expiration. This module actually makes use of these to handle updating / revering single value email fields to the new or original value.
• Rules integration -- with events similar to the aforementioned hooks.
• Permission to bypass email confirmation. (typically for trusted roles.)
• Permission to manually confirm any email address. (typically for administrative roles.)
• Configurable confirmation and notification emails with token replacement.

Beta Release

There is currently a beta release available for download on the Email Field Confirm project page. It has been pretty stable so far. Besides having more sites use the module and report back and defects or feature requests, I hope to get some automated testing (most likely Behat) in place.

• drupal-planet
• email field