(Not sure if this should be filed here or in the Email Field queue. Glad to move it over there if it's more appropriate.)
When using the email field type for fields created using the Email Field module a validation error occurs when saving content that causes the value not to be saved.
This looks like it's being caused by the value of the items that are being returned and fed to the validation function. The function expects to get back an item with an 'email' index ($item['email']) and is instead getting an item with a 'value' index ($item['value']) which is causing it to choke.
This only happens when using the email field type, using the default text field type everything goes through fine.
"Notice: Undefined index: email in email_field_validate() (line 32 of /path/to/drupal/sites/all/modules/email/email.module)."
Comment | File | Size | Author |
---|---|---|---|
#10 | email_html5tools_conflict-1482482-10.patch | 1.23 KB | dboulet |
#7 | email_html5tools_conflict-1482482-7.patch | 1.24 KB | idflood |
#4 | email_html5tools_conflict-1482482-4.patch | 1.18 KB | idflood |
Comments
Comment #1
mraichelson CreditAttribution: mraichelson commentedActually, now that I look a bit closer. This difference in what's being captured ('value' vs 'email') is causing the submitted values to get shot into the void on save, edit, etc. as well. Glad to work towards a patch, but I'm not sure which module it should be aimed at.
Comment #2
minorOffense CreditAttribution: minorOffense commentedWhatever defines the email field widget should be updated to support the email field type. Each widget can limit its use on particular field types. If the email field widget says it can work with the Email Field type, then it should support the field's data format.
At least that's my two cents.
Comment #3
ericduran CreditAttribution: ericduran commentedMoving this up to critical since it's been opening for a while now.
Comment #4
idflood CreditAttribution: idflood commentedHere is a little patch that checks if 'email' or 'value' should be manipulated. I've only tested this patch with email fields and it seems to be working. It should be the smallest way to fix this but I'm not sure if it's the best solution.
As said in #1, the problem is that the 'email' field type use 'email' instead of the standard 'value'. Changing this would lead to something cleaner I think at the cost of a slightly bigger patch to the email module. Patching the email module instead of html5_tools would also certainly make some existing setup break on update.
Comment #5
ericduran CreditAttribution: ericduran commentedThis is still using $element['value']. I'm ok with this patch so I'll commit it as soon as the form_error is fix.
Comment #6
Sk8erPeter CreditAttribution: Sk8erPeter commentedWhy not rather adding it to Email Field's issue queue?
I just created an issue there: http://drupal.org/node/1782394
EDIT: I'm really sorry, this is REALLY rather related to HTML5 Tools, you were right!
It also messes up validation: after enabling HTML5 Tools, email_field_validate() doesn't work well anymore, which means that on a browser which doesn't support HTML5 (like IE8), the user can input an invalid email address without a problem.
The reason: the
$items
array's key gets changed, as it can be seen in hook_field_validate()'s implementation in email.module:BEFORE enabling HTML5 Tools:
http://i.imgur.com/eZuos.png
AFTER enabling HTML5 Tools:
http://i.imgur.com/TqaNS.png
It's really bad because this way the field doesn't get validated well.
Comment #7
idflood CreditAttribution: idflood commented@ericduran: Nice catch, here is a reroll of the patch with the form_error fixed.
I think it may be better to commit this fix as soon as possible and open a new issue for the problem found by @Sk8erPeter about the field_validate() if it still exists with this new patch.
Comment #8
ericduran CreditAttribution: ericduran commentedK, I'll fixed this tonight.
Comment #9
ericduran CreditAttribution: ericduran commentedPatch looks good now.
Comment #10
dboulet CreditAttribution: dboulet commentedThe patch in #7 wasn’t working for me. I’ve modified the patch slightly to always use the 'email' key when an email field type is used.
Comment #11
dman CreditAttribution: dman commentedI've tried this patch here. It seems that the email.module field is just not compatible with the emailwidget at all. You can't just change the name of the field storage column and hope it works. Data doesn't save, even if we remove the validation problem.
Need to also either capture the save and load process (hardly worthwhile) or change this end to use the email.module method.
Looks like email.module doesn't want to change to use 'value' like the rest of the world, and it would be radical special cases to add support for its id into this module. Not impossible, but would be some duplication in places.
Right now, patched or not, these two modules don't play well together.
Comment #12
idflood CreditAttribution: idflood commentedI tried the patch in #10 and it works well on my test, the value is saved and validated via php. I will try to play with both module a little more to see if I can reproduce the issue described by dman in #11.
Comment #13
dman CreditAttribution: dman commentedI am trying to solve issues on a site that's well-through development and has a number of other modules doing things that may be affecting stuff.
I'll see if my problem can be replicated on a cleaner system...
Comment #14
Sutharsan CreditAttribution: Sutharsan commentedIt is indeed a nuisance that email modules does not play by the same rules as may others do. However changing email module's data structure (as dman suggested) in the middle of the D7 cycle will make many people unhappy. All custom code using email data in templates and custom modules will break. Make one exception, add good documentation in the code and we can close this issue.
#10 patch looks good and works. This is RTBC to me.
Comment #15
jstollerI applied the patch from #10 to HTML5 Tools 7.x-1.2, running on Drupal 7.22, with Email Field 7.x-1.2. Prior to the patch the email field data would not save and I got a validation error, as detailed in the issue summary. After applying the patch I was able to save my node without any errors and I confirmed that the data was saved as expected.
This is most definitely a critical error and is impacting a popular module, with over 90k installs. Please consider committing this patch soon.
Comment #16
hass CreditAttribution: hass commentedComment #17
gmclelland CreditAttribution: gmclelland commentedI was getting the same error and the patch in #10 worked for me.
Comment #18
bleen CreditAttribution: bleen commentedCommitted ... thanks all.
http://drupalcode.org/project/html5_tools.git/commit/11e0c28
Comment #19
hass CreditAttribution: hass commentedI would name $target = $type
Comment #20.0
(not verified) CreditAttribution: commentedPunctuation is a good thing.