Only user email field works

Which module do you use for the "cck email field"?

[...] when I run the operation and view the report, I'm seeing the field as empty

What do you mean? This sounds like the email field is empty in the View itself.

PS! Maybe attach an export of your view to this issue.

OK, so by report you mean the log entry generated by Views Send when a message is sent by cron.

Are you sure this isn't just a problem with the logging? You see, Views Sends is validating the e-mail addresses (and empty isn't allowed). You should at least test with setting the formatting of email field to plain text - no link - in the view.

PS! Which packaging date do you have in views_send.info?

I finally was able to reproduce it. (I should have done it earlier.)

Fixed in commit e7c1cd6 (hopefully).

Please confirm so I can release 6.x-1.0-alpha2 (with this fix).

I installed your new commit and still have this problem.

Which version is that? You need to be precise. Your problem, with no validation error, but empty e-mail logged, can't happen ... Or is there a new problem?

OK, but does it still log with an empty e-mail address? I guess so.

Anyway, it just struck me that you might be using Views 3? If so, that could explain a lot. Views Send hasn't been tested with Views 3 (on Drupal 6). If you aren't using Views 3, you need to export your view and attach it here (as I suggested earlier). I just can't reproduce this.

I hadn't really looked at it before now. It looks OK, but different from mine. I wonder what version of VBO you are using. (I'm using 6.x-1.13.) Maybe that is the problem ... There was a major change in VBO and Views Send doesn't work with older versions of VBO. Should have thought about that long time ago.

PS! I'll be on vacation the first two weeks of July. In case I don't see your reply before I leave.

I'm experiencing the same as described in #14 above. I know php mailer is working, sending in plain text (no mime mail).

I'm not sure how to look and see the address as it is 'seen' by the code - are there extra characters in it somehow? Is the validator too aggressive, and maybe misreading the address as invalid (they look good to me...).

-dave.

I'm still on vacation - sorry. (This module didn't "move" for a very, very long time before I stepped up to maintain it so 20 days is nothing, seriously.)

PS1! You are using the latest VBO, right?

PS2! I have experienced wrong number of selected rows reported myself, but very seldom. I assume you have cleared the cache?

I have an update, but not a real solution yet:

The issue is when the function '_views_send_get_from_views_result' is called (from the 'views_send_mail_action_validate' function).

The _views_send_get_from_views_result function does a substr check on the name of the email field selected, but this check assumes a certain naming convention. The assumption breaks when the field in question is a CCK field.

Longer explanation: The function looks at the name of the field, looking first to see if it starts with the string 'field_'. My field passes this test. However, the function then assumes that this will map to a field that starts with the string "node_data_field_text_'. My field does not match this string. The field I'm trying to access is 'node_data_field_email_field_email_value', which is an array. The actual email address is deeper in the array, at node_data_field_email_field_email_value[0]['value'].

I hacked the module a little to look explicitly for the name my CCK email field is passing, and it looks like it is returned to views_send_mail_action_validate correctly (whereas before only an empty string was returned). Then something else fails, and the page blows up. I can't tell at this moment why that is.

I have to set this aside for now, but I wanted to put this info into the thread. Hopefully it can help fix the problem.

-dave.

Thanks a lot for your feedback - really! However, first I must correct you, when you say that

... this check assumes a certain naming convention. The assumption breaks when the field in question is a CCK field.

The check definitely breaks for the email field (as you have shown), but it works for many/all of the "standard" CCK fields - I had tested "integer", "text" and "user reference". I was hoping that the pattern I had found was valid for all CCK fields, but you have proven me wrong.

I'll handle the most popular CCK fields first - like the email field - but I can't promise anything before the beginning of August. I'm still on vacation and family is always first ;-)

hansfn:

Fair enough: I should have been more specific and said 'the convention break on certain CCK fields". I didn't mean to come off as harsh - I know I couldn't have written your module. :)

Thanks for looking into this, and I'm glad I could offer some feedback that might help. And yes, family is first.
Cheers.
-dave.

@daveX99: No offense taken. I just wanted to get the facts right.

By the way, I probably also couldn't have written this module. I'm just trying to move it forward after some great initial work by others.

@daveX99: OK, I tested with a Email Field field and it just works. Are you sure you are using the D6 version of the module (and Drupal 6)?

PS! I keyed the field as field_email in the content type and in _views_send_get_from_views_result I have "node_data_field_text_field_email_email" as expected.

The warning is fixed - see #1668834: Warning on Status Report.

What version of Views and VBO do you have after the upgrade? I assume the upgrade didn't fix your problem?

What type of field is field_1atestmail? (It's not an Email Field field.)

Since everything just works for me and not for you, markroma78, I think you need to install the Devel module and use a special version where I have inserted dpm statements to see what is going. (Send me your email address to hansfn@gmail.com so I can send you such a version.)

I made a little chance in line 904 om views_send.module

FROM
$views_value = $views_result->{'node_data_field_text_' . $field};

TO
$views_value = $views_result->{'node_data_field_' . $key . '_' . $field};

I all so changed line 320 to fix a problem with Tokens

FROM
$token_values[] = $context['row']->{'node_data_field_text_' . $field_key};

WITH
$token_values[] = $context['row']->{'node_data_'.$field_name.'_'.$field_key};

First, thanks a lot for posting a fix and contributing. However, that fix breaks it for me. Could you please post which version of Views and VBO you are using (like I asked you too)? We need to determine why it works for me in all tests I do and not for all users.

Views 6.x-2.16
Views Bulk Operations (VBO) 6.x-1.13+18-dev (2012-aug-03)
Views Send 6.x-1.0-alpha2

Thx for the info. I'll look closer at your suggest change on Sunday. Hopefully, I can make it work for both of us :-)

OK, I looked closer at it today, and the change breaks tokens for me. Could you do two more things for me to help me discover why Drupal behaves different for us. (We have the same version of the modules.)

1) Install the Devel module (if you don't have it already), and insert
dpm($context['row']);
on line 320 of views_send.module. (Clear all chaches.) After submitting a message, you should get some output. Post it here - with code tags around it.

2) Export your view and attach it here.

Thx for your help.

I have attached a screenshot of det Devel output and at textfile with the exported view.

Thx a lot! It seems I have to make the (ugly) work-around I was hoping to avoid. Luckily it's an easy fix that I'll write (and commit) later today.

One final question - what version of CCK do you use. There must be something different between our setups ...

Content Construction Kit (CCK) 6.x-2.9
Token 6.x-1.18

I just installed Views_send on a very old Drupal 6 site with a lot of modules activated and it worked fine, with the two code-modifications :-)

Hopefully fixed in commit 21b1863.

Please confirm so I can release 6.x-1.0-alpha3 (with this fix).

Since 6.x-1.x-dev now contains the commit above it should be easy to upgrade and confirm if my fix is any good. Looking forward to your feedback, styrbaek and markroma78.

I'm so sorry that you had to wait so long. But I haven't activated the function that mails me when the threat was updated.

I have tested the 6.x-1.x-dev and it seems to work fine.

Thx for reporting back. The fix was insufficient - I finally understand what is going now. (I think) I have fixed this properly in my latest commit (e3f4aac).

There will be a beta1 release shortly with this fix - just need confirmation in another bug report.

This is now confirmed fixed in #1758746: _email being suffixed / field_email_email contains 1 invalid E-mail addresses from a total of 1 selected..