(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)."

Comments

Actually, 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.

Whatever 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.

Priority:Normal» Critical

Moving this up to critical since it's been opening for a while now.

Status:Active» Needs review
StatusFileSize
new1.18 KB

Here 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.

Status:Needs review» Needs work

+++ b/html5_tools.moduleundefined
@@ -107,13 +109,15 @@ function html5_tools_field_widget_form(&$form, &$form_state, $field, $instance,
   form_error($element['value'], $error['message']);
}

This is still using $element['value']. I'm ok with this patch so I'll commit it as soon as the form_error is fix.

Why 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.

Status:Needs work» Needs review
StatusFileSize
new1.24 KB

@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.

K, I'll fixed this tonight.

Status:Needs review» Reviewed & tested by the community

Patch looks good now.

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new1.23 KB

The 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.

Status:Needs review» Needs work

I'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.

I 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.

I 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...

Status:Needs work» Reviewed & tested by the community

It 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.

Version:7.x-1.1» 7.x-1.2

I 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.

Version:7.x-1.2» 7.x-1.x-dev

I was getting the same error and the patch in #10 worked for me.

Status:Reviewed & tested by the community» Fixed

I would name $target = $type

Status:Fixed» Closed (fixed)

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

Issue summary:View changes

Punctuation is a good thing.