Hi,
Thanks for your very nice module !
Unfortunately, I am not able to send emails for the moment:

  1. I have a display with a 'Global: views send' field.
  2. In this display, I select one or more rows (see ps#1 attached), and I click on 'send e-mail' button.
  3. On the next page, I fill fields and I click on 'next' button (see ps#2 attached).
  4. Then I come back to the first page, with an error message (see ps#3 attached): "Please select at least one item".

I have updated VS from rc1 to rc2: same issue.
Thanks for your help !
Best

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

hansfn’s picture

Version: 7.x-1.0-rc1 » 7.x-1.0-rc2
Status: Active » Postponed (maintainer needs more info)

The "Please select at least one item" error happens to me as well from time to time. It seems to be a general Views issue (since the selection is lost). For me the problem goes away if I do something ... like clearing the cache, logging out and in again or just using a different view.

If you are unable to make the problem go away, you should check if the same view is giving you the same problem if you a VBO field to the row. (Do you get "Please select at least one item" if you try to run a VBO action?)

brulain’s picture

Thanks for your answer.
I have just tried a lot of things: clearing caches, changing user, create a new view, ... without any success :-(
It works fine with a VBO action 'send e-mail', no error message.
NB: if I remove pager (all items displayed), VS doesn't display the settings page but comes back on the same page (no checkbox is checked and no error message).

hansfn’s picture

Hm, then we have some work to do ... Which version of Views do you use (and Drupal)? Can you make the simplest version of your view that still has this problem, export it and attached it to this issue?

brulain’s picture

FileSize
68.29 KB

I use Drupal 7.19 and Views 7.x-3.5
The views export is attached.
Thanks in advance !
Best

hansfn’s picture

Status: Postponed (maintainer needs more info) » Closed (duplicate)

Hm, this seems to be a duplicate of #1885984: View max rows > Undefined index: step in views_send_form_submit . I think the problem is the number of rows in your view. Could you verify the problem goes away if your view returns say 20 rows (in total).

PS! I'll look more at this since I now got two reports about this problem ...

hansfn’s picture

I just tested with 100 users/rows in a view - no problem. It might be server specific.

Anyway, your exported view is not very useful. I asked for the simplest version of the view that still exhibits the problem. Your view has extra pages and most importantly uses several fields that is specific to your site. Clone your view, and the start removing stuff, verifying that the problem still exists and then add an export of the simplified view.

One more question: When it fails, do you select many rows or just a few from the view. If you select many/all, try selecting one or two. Does it make any difference?

brulain’s picture

FileSize
11.18 KB

Attached a simplified view, with the same problem.
I have selected 1, 2, 3, 4, 10, 70, ..., all rows and it always fails.
As I wrote before, when I remove pager and displays all items, the VS page doesn't appear: I directly come back to the first page after clicking on the 'send e-mail' button, without any message.

hansfn’s picture

Assigned: Unassigned » hansfn
Status: Closed (duplicate) » Active

Reopening because of another report in #1914190: message: Please select at least one item..

PS! Since I can't reproduce this, it would be very nice with FTP and Drupal access to a test site.

Bigbozz’s picture

FileSize
3.58 KB

Here the simplest version of the export view with the error message.
Perhaps that is useful in the search for a solution.

NOTE: I've the same problem as Brulain have: local site with too much confidential information...

brulain’s picture

Sorry, the test site is a local site...

litzastark’s picture

@hansfn, I've just sent you a message with login credentials to the test site where I'm encountering this error. It's an extremely basic view that returns very few rows at the moment. Let me know if you have any questions or if there's anything I can do to help!

hansfn’s picture

Component: Miscellaneous » Code

I'm working with litzastark to track down why the selection is lost. Stay tuned ;-)

hansfn’s picture

It seems my communication with litzastark has stopped ... While waiting maybe someone of the other posters in this thread can test something for me.

Since the problem is the validation (of the selection), you could try to disable it and see if your views works after all. In views/views_send_handler_field_selector.inc rename the function "views_form_validate" to for example "views_form_validate_DISABLED". (You might need to flush the Drupal cache afterwards - go to "admin/config/development/performance".)

Bigbozz’s picture

I've done what you've ask. I've changed line 52 in DISABLED and flushed the caches.

I doesn't get the message now. But the only thing what happens is that the page reload.
And I haven't got any mail... Also my logs doesn't say that a mail has been sended.

Maybe it is not the validation. Maybe he doesn't remember which adresses he must send a mail.

Another strange thing is that I've on the first page (mailinglist) a button 'Send email' and on the second page (write the email) the button 'Next'. Should that not the other way round? Maybe is it a part of the problem???

hansfn’s picture

Thx for the feedback, Bigbozz. So you are really loosing the selection. It's not an error in the validation (as I hoped). I still can't reproduce this myself, but I'm willing to spend the necessary time to fix this - if I get my hands on a server exhibiting the problem. What version of PHP are you using? What is the OS of the server.

PS! The buttons are correct.

brulain’s picture

@hansfn
The production site's configuration is: Red Hat - Apache 2.2.22 - PHP 5.3.16

Bigbozz’s picture

My version of PHP is 5.3.2-1ubuntu4.18. And the OS is Apache. My theme is Pixture Reloaded.

When I go to the second screen (create the mail) then the page will be reload completely.
Normally he doesn't do that and reload he only the content of the page. It looks like a restart/rebuild of the website instead of loading the page...

Another thought of mine is: Can it maybe happend when I've not the correct views-settings?

hansfn’s picture

@brulain: PHP 5.3.16 shouldn't be a problem.

@Bigbozz: PHP 5.3.2 is a little buggy, but ... Check the permissions in Drupal - the role for your user needs "'mass mailing with views_send". You should get a warning if there is a permission issue, but check it anyway.

Bigbozz’s picture

I am the webmaster so that must not be the problem. But I've tried it with no result.

When I check the box 'Remember these values for the next time a mass mail is sent.', he doesn't remembered that the next time. So I think it's not only that he can not remember the adresses, but he forgets also what settings have been set. Perhaps goes something wrong in the action when you click on the 'continue'button? (Or say I something stupid now?) :)

hansfn’s picture

When I check the box 'Remember these values for the next time a mass mail is sent.', he doesn't remembered that the next time.

This happens because the validation of the selection is before the code that stores (remembers) the values for next time. In other words, the values are only remembered when a message is successfully sent.

brulain’s picture

I have just replaced my test site (local) with the production site, and VS works fine...
The local configuration is OSX 10.6.8 and MAMP 2.0 (with PHP 5.3.6)

Bigbozz’s picture

What does the system differently than before? What is changed that it works fine now?
Because using MAMP to let the module work isn't perfect but it can lead to the solution.
In my case, I must first handle MAMP before I can use it... (sorry, I'm a noob) :)

brulain’s picture

FileSize
220.73 KB

Nothing has changed, except the platform.

  • Production (issue): Shared server with Red Hat, Apache 2.2.22 and PHP 5.3.16.
  • Local (OK): Macbook Pro with OSX 10.6.8 and MAMP 2.0 (included PHP 5.3.6)

See printscreens attached for PHP info.

hansfn’s picture

I'm sorry, but all of this doesn't help me. I need (S)FTP/shell access and Drupal access to a site where it doesn't work. I want to fix this ...

brulain’s picture

OK hansfn, I send you an email.

ezheidtmann’s picture

Title: VS simulates a loop... » Cannot proceed to confirmation page due to error "Please select at least one item" [was: VS simulates a loop...]

I'm also experiencing this bug. It shows on PHP 5.3.3 on CentOS 6.3 but does not show on 5.3.10-1ubuntu3.5 on Ubuntu 12.04. I can't give you access to the server, but I can send as many traces or debug statements as you could want.

hansfn’s picture

Title: Cannot proceed to confirmation page due to error "Please select at least one item" [was: VS simulates a loop...] » Cannot proceed to confirmation page due to error "Please select at least one item"
Priority: Normal » Critical

Thx for the offer, ezheidtmann - I have just spent much time doing the same with brulain, making very little progress ... I can send you a version of VS with some dpm statements, but so far I haven't found any info explaining why the selection is lost. It is clear that selection is lost (when going to the confirmation page).

There is a very similar issue for VBO (on Drupal 6): #361871: VBO loses selection with caching module Please read that issue. (Views Send is using much code from VBO.)

brulain’s picture

I have changed 'max_allowed_packet' value on my local MySQL.

If it is less than or equal to 3M, clicking on the 'send e-mail' button redirects to a blank page, without any error in the logs (PHP, MySQL and Drupal). If it is greater than 3M, it works fine.

I have just asked to the provider he increases this variable on the production site (actually 1M). I hope he will...

brulain’s picture

The value 'max_allowed_packet' was increased to 32M on the production server.
Now, VS works fine ;-)

Bigbozz’s picture

:( the provider wouldn't raise my 'max_allowed_packet'. Is there an other solution?
maybe can the use of the 'max_allowed_packet' be reduced? I hope so...

Bigbozz’s picture

Is there nobody who have a solution? :S
It is important for my site but I've not the knowledge...

hansfn’s picture

Status: Active » Closed (works as designed)

Since the solution is to increase max_allowed_packet in MySQL and your provider wouldn't do that, there isn't much we can do to help you.

You could try to make the View simpler in some way (or change the content types used in the View) and see if that decrease the query size. There might be some good tips in the MySQL documentation too.

Bigbozz’s picture

Hurray! It works! The last update was enough to let it work.
Thanks a lot for the help. This module is great!!! :D

Rosamunda’s picture

Version: 7.x-1.0-rc2 » 7.x-1.x-dev
Status: Closed (works as designed) » Active

Hi there,
I have the same problem. MySQL isn´t an issue (I´ve increased max_allowed_packet in my VPS account).
I´m trying with a very simple view: A filter that search usernames, and the view shows just the email address. I´m trying to send a single email.
I´ve checked the logs, and I´m getting 2 different errors:

Warning: preg_match() [function.preg-match]: No ending delimiter '.' found in file_scan_directory() (line 2044 of /home/prueba/public_html/includes/file.inc).

Notice: Undefined index: file_managed in views_handler_field_field->access() (line 127 of /home/prueba/public_html/sites/all/modules/views/modules/field/views_handler_field_field.inc).

Any insight? Thanks for your help!!

hansfn’s picture

The two entries in the log aren't errors, and they aren't related to the Views Send module. Sorry, I can't help you. PS! What is your max_allowed_packet?

Rosamunda’s picture

Status: Active » Closed (works as designed)

Oh I see, but the page that shows the error is the send email view page. I´ll search in the views queue.
After reading that #32 worked fine with 32M, I´ve set it the same way.

I just needed this to send welcoming emails to every member of an OG group. I´ve managed it using VBO.

Thanks!
Rosamunda

torrance123’s picture

Component: Code » Documentation
Issue summary: View changes
Status: Closed (works as designed) » Active

I'm reopening this and changing to 'documentation'.

We had this same issue and after 3 hours of digging it came down to the cache_set call failing for the form (but not for the form_state, which was successful). The exceptions are being ignored so I had to capture them myself:

SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.Exception thrown...

And the solution to this error is to increase the innodb_log_file_size size in mysql, in our case all the way up to 128M.

So for those of you for whom the maximum packet size wasn't this issue, then it's possible this is the issue instead that's causing your form to lose state midway through.

This requirement should probably be documented somewhere, along with the maximum packet size too.

xjustyx’s picture

I still have this error, it worked to me until 1 week ago, sunddenly I have it again, and its not a server fault because in my last week version of the system I dont have it, its giving me cracy trying to solve it, are there any other reason of this issue?
Thanks a lot.

xjustyx’s picture

Component: Documentation » Code
hansfn’s picture

Component: Code » Documentation
Status: Active » Closed (fixed)

@torrance123: Thanks a lot for providing information about the innodb_log_file_size setting.

The project page now documents the two fixes known for this issue - see under "Known issues".

@xjustyx: The important thing is the setting of max_allowed_packet and innodb_log_file_size. What are they? Have you increased them sufficiently? Are you logging errors in MySQL? And so on.

xjustyx’s picture

I have 2 versions of drupal in my domain, one of then send views work properly but the other dont, so i dont think that max_allowed_packet or innodb_log_file_size are wrong, i have no logging errors in MySQL so i dont know what to do..

hansfn’s picture

That is a wrong conclusion. Unless the two Views in your two Drupal installations are identical, it might very well be that max_allowed_packet and/or innodb_log_file_size are too low. It's the size of the View - number of fields, rows and so on that is causing problems.

Before posting again, try the suggest fix under known issues - increasing ...

xjustyx’s picture

I have the same view in both servers, because its a backup one from the other,I tried changing those values a month ago.
The last version of the system work properly and the other dont.

hansfn’s picture

There is a difference. You need to find it to solve the problem. There isn't much I/we can do - sorry.

scotwith1t’s picture

i think the Known Problems section on the project page needs an update. The issue referenced there no longer exists and we ran into the max_allowed_packet issue on our server and didn't notice this because it was talking about "select at least one option". I think the project page should just more generically say that if you run in to MySQL errors with this module to ensure the max_allowed_packet value is at least 8M (in our case it required 16M, even testing just sending to one recipient (WTH?!?!)). If someone could update the project page I think that would be helpful to all who may try to use this module. Thx!

hansfn’s picture

Hi, scotself.

The link to issue 1905104 in the "Known issues" section was missing a slash. It's fixed now (and it is linking to this issue). In addition I have modified the wording. Better now?

scotwith1t’s picture

Perfect. Thanks @hansfn and thanks for a great module!

cebab54’s picture

I have this problem, but cannot find the fixes that you refer to above
This happens with the 7.1.6 and 7.1dev versions
It certainly isn't fixed, yet with Admin rights as UUID 1, the problem is not there, it only affects authenticated users with a role that permits use of Views Send.

hansfn’s picture

Status: Closed (fixed) » Postponed (maintainer needs more info)

The page with known issues has moved to the Drupal 7 specific documentation.

Anyway, this is a completely new variant of the issue and is clearly related to permissions. (If you have read the complete thread, you'll see that the problem most of the time is related to the database.) There isn't much I can do without much more information: Is there any errors in the log, does it work for other users if you give their role all permissions (test by creating a new role), do you use other Views related modules and so on.

cebab54’s picture

I am now getting a White Screen instead of the screen reverting to the View select screen whether the User has Admin rights or not.

cebab54’s picture

OK fixed the WSOD by tweaking PHP settings

Have also checked the max_allowed_packet and that is set to 256Mb

Can confirm this is not a Permissions issue as the issue is definetely now affecting the UUID 1 and those users with Admin rights over Views Send

Additionally I now see that none of the options are saved after clicking on NEXT to send the e-mails and the screen simply returns to the User/email address selection screen, which I have tried simplifying to no avail.

cebab54’s picture

I have now tracked down the problem. It is to do with Tokens and tweaking the depth to 2 rather than the previous 3 setting (the default is 4) has fixed the problem.

hansfn’s picture

Status: Postponed (maintainer needs more info) » Fixed

OK, I'm happy that you tracked it down. (For other readers: This problem is listed among the known issues.) Closing the issue again.

Status: Fixed » Closed (fixed)

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