Feeds mapper for email field

Link field mapper is here: #623444: Port FeedAPI Mappers: link. Rerolled as patch without link mapper.

I wonder whether we shouldn't handle email mapping in content.inc. It appears to be only another field type like 'text' - correct?

Forgot to mention - you can use cvsdo to add a new file to a read only CVS repository.

"however the email field is provided by the Email Field module"

Doesn't make a difference. content.inc is included as soon as content module is present and email depends on content module.

"It also handles it's fields differently (it's not [0]['value'], it's [0]['email'])..."

That would be reason enough...

Leaving this on NW, there should be a minimal test for email field in order to commit this. Can be modeled after the content mapper tests.

Tested the patch of #1 and everything works fine.

I've added a minimal unit test. However,

$this->assertCCKFieldValue('email', 'user1@example.org');

doesn't work like it should, and I didn't directly find out why. I could do a raw DB check though?

#5: It's so great to see tests :-)

Use $this->show() or $this->show('node/[nid]/edit') to figure out what the UI displays. show() will create a warning that prints the test site's current screen or the screen of the path you specified to the test log.

+1 on patch #1

Fixed up the test so it passes.

Patch in #8 works fine for me.

thx twistor. everything works as excepted

Committed, thank you

http://drupal.org/cvs?commit=452114

I don't see a .dev version available but the patch in #8 worked on the beta10 version, thanks twistor!

Seems like this hasn't been ported to D7 version.

Here is an initial patch (no tests).

Reopenning for D7 version.

#15 patch working for me on 7.x 2.0 Alpha 2

emk

patch in #15 works for me with 7.x-2.0-alpha2
Thanks!

Works for me for patch in #15 works for me with 7.x-2.0-alpha2 but not in 7.x-2.0-dev (not a big surprise i guess), i get a PHP Fatal error: Class name must be a valid object or a string in /.../modules/feeds/includes/FeedsConfigurable.inc on line 60.

#15 Works for me with feeds 7.x-2.x-dev (2011-Jan-15) and email 7.x-1.0-beta1.
I'll report this in the email-issue queue, too.
IMO releasing this patch can be done in either module. I think the priority in email will be higher.

#15: feeds_email.patch queued for re-testing.

On this issue #914210: Mapper for user password (for feeds) they say that there is no feeds_test and that's why it is failing testing. Since other people have already tested this patch manually I'm marking again as RTBC.

I tried the patch from #15 and it worked great in D7, thanks jackbravo for sharing it with us and I hope this gets included

Tested. Patch #15 works nicely.

Patch #15 did the trick for me too.

Works for me too!

Seems to be working for me too but should feeds be supporting every field? Seems like it might be better for the fields to include their own Feeds integration.

Where does the patch go? I tried it in /feeds and /feeds_import, and and I do not see it.

I have an existing Feed Importer that I need to add this field to.

Thanks much!

+1 to this

@gidgetk (#30), the file email.inc goes in feeds/mappers, so the path is .../modules/feeds/mappers/email.inc . You can find in on this line in the patch: "+++ b/mappers/email.inc".

@presleyd (#29), indeed, this mapper should go in the email module (which is also the opinion of maintainer). The filename should then be modules/email/feeds.email.inc
These pending issues should be resolved first, before having a definitive solution:
#1224836: modulename.feeds.inc files are not automatically included
#1139676: feeds_alter doesn't support hook_module_implements_alter, hook_hook_info and hook_hook_info_alter

@johnv, but the currrent patch can be adapted to work well on Email module right away, doesn't it? it seems quite ok.

@franz, indeed, the current patch is OK and working fine.

Let's move it over then.

Patch on #15 works if applied to Feeds, we just need to port it to Email module.

#15, rolled against email 7.x-1.x-dev

I suggest to update the Patch on #15 to the newest D7 Recommended releases or Development releases.

#36 worked great! Thank you

I'm willing to commit Feeds support, but here some minor coding style issues:

+++ b/email.module
@@ -463,3 +463,49 @@ function email_content_migrate_instance_alter(&$instance_value, &$field_value) {
+        'description' => t('The @label field of the node.', array('@label' => $instance['label'])),

I guess it works for other entity types as well ;) Same for "@see FeedsNodeProcessor::getMappingTargets()"

+++ b/email.module
@@ -463,3 +463,49 @@ function email_content_migrate_instance_alter(&$instance_value, &$field_value) {
+ * When the callback is invoked, $target contains the name of the field the
+ * user has decided to map to and $value contains the value of the feed item
+ * element the user has picked as a source.

We could document all parameters in a doxygen way, I'm not familiar with feeds.

+++ b/email.module
@@ -463,3 +463,49 @@ function email_content_migrate_instance_alter(&$instance_value, &$field_value) {
+      $field['und'][$i]['email'] = $v;

We can use the constant LANGUAGE_NONE for 'und' as long as it is language independent.

I used the patch in #36 in a separate module and it worked just fine!

Too bad it has 1 code style issue that's keeping it from being commited.

the patch in #36 worked for me.

The patch in #36 works fine here, too.

The attached patch is a reroll of #15, with the following modifications:
- suggestions from #39 taken into account, except for "'description' => t('The @label field of the node.'" , because this is how all all other mappers document it.
- Oops, I see I forgot to rephrase "@see FeedsNodeProcessor::getMappingTargets()"
- It is now in a new file email.feeds.inc (so maintainer does not need to see this intrusion to often :-) )

The new filename does not need to be in .info file. Recent dev-versions of Feeds have learned how to discover this file themselfes.

#43 works for me, thanks!

I tried #43 against the latest dev and even after running update (nothing to update) and clearing cache, the email field never showed as an option for the field mapper. Using Drupal 7.12

@kthull, do you use lates -dev of Feeds?
If not, you need to add the following line to email.module.

include('email.feeds.inc'); 

@johnv, not the latest -dev for feeds...using 7.x-2.0-alpha4. I'll try the latest -dev first, then if that doesn't work, I'll add the code to email.module. Thanks!

Nice! #43 worked with the latest feeds -dev. Thanks @johnv.

#43 works! Thanks!

patch in #43 worked for me.

#43 patch works - thanks johnv

#43 works - lets get this committed. Thanks!

Better title.

#43 patched and Feeds imported my content :)

BTW - The Drupal community is awesome. "Theres a module for that" is only closely followed by "There's a patch for that" :) Love you guys!

Josh

#43 works fine. Thanks!

the latest -dev of the module does not have the line of code in include the .inc file

just to be clear; this is 7.x-1.x-dev taken from the project page dated Nov 10, 2011?

ahh.. sorry.. i mis-read.. need latest Feeds OR that line added.. which really should just be latest Feeds; not good to fix in 2 places

this is the same patch as #43, re-rolled to be applied not from within /feeds/mappers, but /feeds, which is the standard, and also necessary for those of us that use drush make profiles for our site builds.

thanks for the patch!!

of course i forgot to attach it...

Shiraz Dindar: this patch is for the Email Field module, not for Feeds.
Patch in #43 is still RTBC.

Committed patch from #43. Thanks to everyone involved in this issue!

Am not positive whether to reopen this issue or create a new issue for this...

The email mapper code committed above was inherited from standard feed mapper code, including its bug that when mapping empty values for a field, the field label still shows on the node. That bug applies here -- empty email addresses will render an empty email field label when viewing the node. They're near complete on the fix on that for feeds (see http://drupal.org/node/1107522).

This patch applies the relevant part of the patch in #37 from the above issue to the email feeds mapper here. Empty email values no longer generate email field labels after import on node view.

Shiraz

Here's the fix for the bug reported above.
#2095197: Improve Feeds integration.