I’m running phpList 3.2.7 with Safari 1.0.03 on a MacBook Pro. Because of limitations imposed by my hosting service (19 messages per minute), I have the following settings in config.php:
Those settings now keep me within the 19/minute limit; however, after each batch of 8, phpList stops sending messages. I’ve waited for as much as 8 hours without the next batch being sent.
The only solution I’ve found was to select “process the queue”. The next batch is processed and phpList simply waits after it is done … requiring a series of manual selections of “process the queue” to get the entire job out.
Is there a way to automatically process the next batch after a batch has been sent and the appropriate time period has expired?
I am trying to eliminate the multiple progress messages that are sent following the processing of a batch.
Here is the setting in my config.php file:
with batch processing enabled, and run in small batches,
selecting 1 will result in many progress reports being sent
selecting 0 will eliminate those reports
define (‘SEND_QUEUE_PROCESSING_REPORT’, 0);
This newbie thanks you for your help.
hi, Your batch size is 8, and the period is 10 minutes (600 seconds).
Your delay between each emails is 10 seconds, so that would indicate about 6 or 5 emails per minute.
you might want to set your batch size to 5, and the period to 60, and see how that works.
define (‘SEND_QUEUEPROCESSINGREPORT’, 0);
to 1 to get the reports
define (‘SEND_QUEUE_PROCESSING_REPORT’, 0); already exists in my config.php file.
However, I notice that my command includes underscore characters between the words and your sample does not. I’ll try removing the underscore characters and see how that works.
It’s not clear how making smaller batches will cause the system to process subsequent batches, rather than wait, however, I’ll try modifying the batch size and period as you suggest and see what change that produces.
Thanks again, for the suggestions.
@Arlo141 The config value does have underscores, but the forum software uses underscore to indicate italic formatting. Use the code button < /> to enter chunks of php or html.
I’ll put the underscores back in to the command in the config.php file. Does it matter where this command goes in the config.php file? I couldn’t find any reference to it in the original file, so I simply added this command in the same area as the other batch processing commands.
My two problems remain:
Changing the settings to batch size to 5, and period to 60 still processes the first batch and then ceases … waiting for me to manually “process the queue” before further messages get sent. I was impatient initially and manually re-processed the queue at 1-hour intervals … then, I waited and even after 15 hours subsequent batches didn’t get processed unless I manually processed the queue.
with define (‘SEND_QUEUEPROCESSINGREPORT’, 0); I still get progress messages telling me the job has started, a message following each batch (i.e., the initial batch as well as the ones I manually process) and a message telling me the job has been completed. I assume the “start” and “completed” messages are routine but it would be nice to get rid of the messages following each batch … especially since the limits of my service provider call for me to work with a large number of small batches.
Does anyone have suggestions for either issue?
You still appear to be mis-spelling the setting name. As I suggested use the code button < /> when for php and html
The start and completed emails are enabled on, I think, the Finish tab when composing a campaign. So if you do not want them then disable them there.
Thank you again, Duncan. I appreciate your time and your advice.
the send_quque_processing_report command is spelled correctly in the config.php file … I rushed too much when I copied it into my message. The command in the config.php file is:
Where should this command go? Is there a particular location or sequence for it within the config.php file?
Thank you again.
It can go in the config.php file, I’d put it near the top.
Don’t forget the semicolon at the end of the line.
Thank you, Dan.
I’ve moved the command to just before the batch processing information in the “Queue and Load management” section of the config.php file.
#with batch processing enabled, and run in small batches,
#selecting 1 will result in many progress reports being sent
#selecting 0 will eliminate those reports
I do have the semi-colon at the end.
I’m rewarded by receiving a processing report at the end of each completed batch, or whenever a full batch cannot be sent because limits are exceeded.
I’ve checked and this is the only send queue processing report command anywhere in the file.
It would be really great to eliminate these messages. I am severely limited in the number of messages I can send before my service provider blocks the account and the multiple processing reports count toward the message limits. That makes it more than an inconvenience – it starts to cut into the functionality of phpList for our use.
Any thoughts will be greatly appreciates.
As an update to the issue of processing report messages …
Accepting that these messages would continue, I attempted to reduce the number of those messages by increasing the batch size thereby reducing the number of batches. I changed the settings (to keep within the 19/minute and 100/hour limits imposed by my service provider) from:
The processing reports mysteriously quit arriving (except for the “campaign has started” and “campaign has ended” messages – and those messages aren’t the problem). All of this result with no changes at all to the define(‘SEND_QUEUE_PROCESSING_REPORT’, 0); command line!
I’m not sure if phpList is somehow locked into sending the processing reports for batches of 5 or so (there are notes about “When you have batch processing enabled, and run in small batches …”, but there’s no indication of what constitutes a “small batch”). Perhaps the messages quit because I increased the batch size; perhaps they quit because I established a significantly greater batch period; perhaps there’s another explanation. Regardless, the messages have now disappeared and I’m a much happier camper, since those administrative messages count toward the rather small limit imposed by my service provider.
Just in case this outcome is helpful to anyone …