Email field widget type causes validation error when used with Email Field module

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.

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

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.

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

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

Patch looks good now.

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.

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

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.

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.

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

Committed ... thanks all.

http://drupalcode.org/project/html5_tools.git/commit/11e0c28

I would name $target = $type