Closed (outdated)
Project:
Webform
Version:
8.x-4.x-dev
Component:
Code
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Issue tags:
Reporter:
Anonymous (not verified)
Created:
12 Sep 2013 at 07:11 UTC
Updated:
28 Nov 2016 at 06:44 UTC
Jump to comment: Most recent
Comments
Comment #0.0
Anonymous (not verified) commentededit
Comment #1
MixologicComment #2
Anonymous (not verified) commentedThis bug still persists for 4.0. Any news? This bug report specifically refers to the email address that the webform submissions are being sent to - that is the field that is not accepting IDN email addresses.
Thanks for everything!
Ed
Comment #3
danchadwick commentedPatches are welcome. :)
Comment #4
MixologicIDN is something that should be fixed in core, not contrib, and as such all issues affected by IDN should have the tag of IDN. please dont unset it again.
Comment #5
danchadwick commented@Mixologic -- Looking through the IDN tags for core, it looks like this has been pushed to D8, and maybe has been partially committed. Since I'm not sure what exactly in webform is causing this, it's hard to tell. If it is hopeless to get a patch into D7, I would consider a contrib patch for webform, but I certainly am not going to research and write this. Thoughts, core issue references, or other helpful background?
If there is no hope for this, we might as well close it as works as designed.
Comment #6
Mixologicbasically there needs to be a pair of functions in core that convert unicode domain names into 'punycode' representations of those domain names. Then contrib modules could all use drupal_ascii_to_idn and drupal_idn_to_ascii everywhere that they handle domain names.
The main core issue that discusses this is here: https://www.drupal.org/node/389278
Without it being in core, it would mean that every module that handles email addresses or domain names (like the domain module) would have to reimplement their own version of the punycode standard in multitudes of ways. I dont think that there is anything *stopping* additional api's being added to d8, especially now that we have semantic versioning, so while I dont think this will make it into 8.0.x, I dont see why it couldnt easily be put into 8.1.x for example.
Comment #7
danchadwick commentedBased upon #6, I think the reasonable course of action is to more this to the webform 8.x queue.
Comment #8
fenstratClosing to clear out the old Webform 8.x-4.x branch. See #2827845: [roadmap] YAML Form 8.x-1.x to Webform 8.x-5.x.