Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Just a word to inform that I started working on the port of this module to D8.
I don't say it's going to be quick but if you want to work on it too, please ask :)
Issue fork multiple_email-2489232
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #1
duaelfrComment #2
mbovan commentedHey! Are you still working on the port? Do you have a link to sandbox/github repo?
Comment #3
duaelfrI'm not working on it anymore. I think I started too soon, so ran into a lot of issues. Plus, I started to write a blog post series to explain how to do, so it took me even more time.
I just pushed my work in the 8.x-2.x branch so if you want to continue, do not hesitate. Again, it's quite old and it's never been over. Don't expect it to "work" on 8.1.x :)
Comment #4
geek-merlinMy gut feeling is that this is more of a complete rewrite than a straight port if we want to leverage the D8 blessings.
Comment #5
drummD8 core has an email field type. I'm not sure if it can confirm email addresses or not. Multiple email could move to extend a multi-valued email field on user entities.
Comment #6
geek-merlinYah, i did not wrap my head completely around this, but even making the core email field multiple may be feasible.
Comment #7
manuel.adanFor the upcoming D8 version, the email_confirmer module might be useful. It makes the hard work for any other module that needs email address confirmation as is the case with this one.
Comment #8
pasqualleComment #9
avpadernoComment #10
jonathanshawI created a Drupal 8 module similar to this called 'Alternative User Emails'. It's not as ambitious as this module, but it' might be good enough for 90% of use cases: https://www.drupal.org/project/alternative_user_emails
Comment #11
volegerHow to contribute to the 8.x version?
Can maintainers define the development branch and enable testing?
This will help to provide some contributions using the separate issue forks.
Comment #12
duaelfr@voleger
Thanks for stepping up!
I renamed the 8.x-2.x branch to 2.x, quickly rebased it on latest 7.x-1.x then pushed and created the dev release and enabled some tests.
Comment #13
volegerGreat, thanks.
Comment #15
volegerUpdated the tests by converting them to Functional tests and replaced deprecated function calls in tests.
The next step is to convert hook_menu implementation to routing configuration and update all hook implementation to the compatible implementations (check if they implemented propely).
Comment #16
volegerCan be test enabled for the 2.x branch? Also regarding compatibility with semver the development branch better to rename to 2.0.x.
Then switch the target branch in the merge request to the new branch before removal 2.x branch.
Comment #18
davisbenI'm working on a project where I need this functionality, so I took a stab at finishing up this port. It's not 100%, but it's a good chunk of the way there.
Comment #19
davisbenComment #21
duaelfrNothing shocked me in the code so I merged the MR.
Thanks a lot for all the work here!
@davisben do you think you covered enough to make a first alpha release? What's remaining to do on this port?
Comment #22
davisbenIt should be in good shape for an alpha. The UI could probably use some cleaning up, but I think all the functionality has been accounted for. I've been using it for a couple months, but I'm just one person with a limited use case.
Comment #23
duaelfrI'll make a release then.
Thanks again a lot for sharing your version with the community!