6.x-3.x changes

ahem ^^

sure, i will... but only if you turn on verbose error output on your development machine ;-P

earnie,

Using: v6.x-3.0-alpha1
Reason: 6.x-2.3 almost worked but without save all selected meant we would have to page through more than 800 pages to send the emails! The 3.0-alpha1 does work to address that issue. :)

Not sure if this is the right place to post this, but I wanted to give my insight and experience of your module.

First off, great work on this. We hope to use it on www.shrinktheweb.com as our bulk mailer.

The selection/saving/etc is a bit clunky but it does work and is very flexible. Excellent!

We only needed to make a minor modification to always exclude based on a certain profile field (unsubscribe) which is part of the 1-click unsubscribe I just finished building. Aside from that, it worked right out of the box. Excellent!

The bummer was when we tried to send to our 12,000+ user base and ran into a max time exceeded after a bunch of emails were sent. Now we don't know who got the email and who didn't. I tried looking for the right place to put a set_time_limit ( 10000 ) ; but couldn't find the right place. Any ideas?

Ideally, the emails should be broken out and sent individually (so that the user's email could be on the To line, which would be better for passing spam filters), but since no other contact module does this; I'm guessing it is a drupal limitation, no?

Second best would be to break the send out into batches (but that could differ based on server settings), so it would need to be an option with a configurable number (100 as a good default). I would write the patch myself but I'm not familiar with the protocol on doing so. :-/ I have seen the same thing in the module named mass_contact using the field mass_contact_recipient_limit and that works well. Mass_contact was a great module but ended up not working for us for a different reason that we could not overcome without significantly rewriting the module.

Again, great work and I'm hoping you can assist us. We would really love to use your mod b/c it will save a lot of time. Otherwise, we're back to the drawing board and probably will have to write out own but this one is so close. Ack.

Thanks!

-The Brandon

If you want to use your method of set_time_limit, you need to add it to the submit handler for the advuser_multiple_email_confirm form in the forms/advuser_multiple_email_confirm.inc file. I would be more inclined to use set_time_limit(30) in the foreach loop before the drupal_mail() call but if you want to use the large block of time then it would go before the foreach statement at line 114.

As a quick stop-gap to allow us to use this module now, I think I'll give this a try and report back. I am indifferent as to where/how to put the code but I didn't realize the 30s on the foreach loop should achieve the same result. In looking at the code, I don't see how the set limit (30) will work b/c the default is already 30s and we're not really affecting anything there. I must be missing something?? Otherwise, the high setting at line 114 will be what I try next. However, I would prefer to do it your suggested way if the lower limit will work the way you intend. I just don't want to test it with live emails and this critical announcement. I need the highest probability that this will send out to all, to avoid complaints. ;)

As I have already stated I do plan to use batch processing to accomplish the multiple send. But still each account will be loaded individually to prevent the mail from looking like spam. I may look at a cron hook method to allow the user to select the users, format the mail and then at a cron scheduled time, do the mail

That is great that it breaks out each email separately and now it makes sense why it hits that limit quickly.

While "a bit clunky" (I see it as different from normal style) as you say it does work. It allows for the freedom to add and subtract easily from the selections and I have given enough warning to prevent you from accidentally destroying your selections by adding or removing filters.

It does work and takes little time to figure out, so I would agree that making it "less clunky" is a lower priority. I wasn't suggesting to change anything in that area in this release.

Thanks for the quick insight! I am excited that this module may work for us. I wouldn't be opposed to "sponsoring" some of the development too, if it helps speed things along and gives back to the community.

Cheers,

Brandon

Nevermind... I see from the php function:

When called, set_time_limit() restarts the timeout counter from zero.

That's what I was missing ;)

Here are my test results:

I went with the set_time_limit(30) inside the foreach loop right before the drupal_mail command. I would give the line number but mine is a little off because I also added a custom footer to each email.

It appears that all the emails did send but I got the following error:

Unable to send e-mail. Please contact the site administrator if the problem persists.

but also the following message:

The users have been mailed.

I had test accounts on both ends of the spectrum (low number and recent) and since both got emails, I imagine that it did send to all.

Best regards,

Brandon

I bet #699858-21: Integrate with the Token module for email token substitution. should go here.

Ok. Sorry.

We are probably the most "power user" of those using this mod. As such, I have some observations:

Note: We send approx 17,000 emails at-a-time currently (and that grows quickly each month).

1. We have noticed that the memory usage is becoming a problem. We are getting out of memory error messages (or just a white screen of death if error reporting is turned off). We have had to continually bump up the global PHP memory limit to accommodate but that is a very temporary solution because with nearly a thousand concurrent users at any given time, that seriously impacts the memory usage on our server. The ideal solution is for this script to allocate and utilize memory on-the-fly as determined by the number of emails. That way, we could leave the default PHP memory for all users lower and just have the adv user allocate more as needed for that run.

2. When dealing with this many emails, it is annoying to scroll down past 17,000 emails (perhaps THIS is the cause of the memory issues mentioned above) that are listed out in order to get to the place where we type out the message. Ideally, this list should be a collapsible field (collapsed by default), placed below the form fields, or put on a separate page if you want to verify who will be emailed.

Thank you,

Brandon

Regarding my previous comment: Is there any interest in making this module useful to larger users? If not, please let us know soon, so that we may explore alternatives.

Without some basic mods to memory usage in the code, this module becomes useless at high volumes.

We are not opposed to sponsoring a fix to this limitation.