View Issue Details

IDProjectCategoryView StatusLast Update
0015365phpList 3 applicationDocumentationpublic21-06-18 13:05
ReporterThorsten Albrecht Assigned To 
Status resolvedResolutionfixed 
Product Version2.10.10 
Target Versionnext major 
Summary0015365: Wrong description of MAILQUEUE_BATCH_PERIOD in config file
DescriptionThe description of MAILQUEUE_BATCH_PERIOD is wrong.

It says: "MAILQUEUE_BATCH_PERIOD define the length of one batch processing period, in seconds (3600 is an hour)"

This is not true. Instead, it defines the waiting time between two batches.

E.g., I am using the following settings:


What happens is that I am sending 10 mails per batch and the web interface waits for 1 second before reloading and sending the next 100 mails.

TagsNo tags attached.


child of 0015464 resolvedmichiel Include new configuration options and update explanatory text in config.php 


12-11-09 13:02


batch-phpList_arrows.gif (41,258 bytes)   
batch-phpList_arrows.gif (41,258 bytes)   

Thorsten Albrecht

10-12-09 18:04

reporter   ~0050800

Just to add: in README.batches the description of the variable mentioned above is already correctly documented:

"To process in batches, you can configure two variables:

MAILQUEUE_BATCH_SIZE - the size of a batch

MAILQUEUE_BATCH_PERIOD - the time to wait until running the next batch (in seconds)

Please correct the description in config.php because it confuses everybody.


12-04-10 15:22

administrator   ~0050882

well, in a way you're right that it's confusing, but then at the same time it's not as you state.

the fact that phpList waits batch time to reload is irrelevant. It could reload later or sooner, that doesn't matter. The main thing is that it will not send any more emails even if the queue is run again.

You will probably notice some message saying:

This batch will be X emails because in the last "MAILQUEUE_BATCH_PERIOD" seconds (MAILQUEUE_BATCH_SIZE - X) have been sent.

So, the MAILQUEUE_BATCH_PERIOD does actualy really enforce that amount in that time frame.

Thorsten Albrecht

30-04-10 16:59

reporter   ~0050986

Hello Michiel,

the fact is that the default value of 3600 for MAILQUEUE_BATCH_PERIOD made me think that it is impossible to use phpList. I took me some weeks to recognize that when I set MAILQUEUE_BATCH_PERIOD to a much lower value (e.g. 1) everything worked fine.

Example: I am sending a newsletter monthly to about 6000 recipients. My current settings are:

Those settings work for me perfectly. After sending 100 mails, the system pauses for 1 s, the browser reloads, and the next 100 mails are sent.

I do not understand your explanation:

"So, the MAILQUEUE_BATCH_PERIOD does actualy really enforce that amount in that time frame."

This cannot be true because I define a time frame of 1 s (!) and everything works. There is nothing being "enforced"; in that 1 second nothing happens at all. Only the browser reloads, and the next batch begins.

To your second statement:
"the fact that phpList waits batch time to reload is irrelevant. It could reload later or sooner, that doesn't matter. "

This is not irrelevant for me. I have a cgi timelimit for php scripts of 6 min, so it is very important for me that phpList reloads immediately after sending the number of mails defined in MAILQUEUE_BATCH_SIZE. In my case, the 100 mails have been sent after about 60-90s. If I would let MAILQUEUE_BATCH_PERIOD on the default value of 3600 I would run into the timeout of my server. (This happened the first weeks when I started with phpList. I nearly deleted the whole system because of this problem.)

BTW For me there seems to be no sense of MAILQUEUE_BATCH_PERIOD at all. If it would work I would set it to zero.

Best regards,



06-08-10 13:13

reporter   ~0051067

The confusion seems to lie in that MAILQUEUE_BATCH_PERIOD seems to define TWO variables: 1) the time during which a maximum number of posts as defined in MAILQUEUE_BATCH_SIZE can be sent; and 2) the time after one batch is run before another batch is run.

I too have MAILQUEUE_BATCH_PERIOD set to 1 second, with MAILQUEUE_BATCH_SIZE at 40. The batch is processed in 1-3 minutes, and I run processqueue by cron every 4 minutes for the few hours it takes to get through all of our subscribers. (Batch processing does not reload on my system.)

So indeed, the MAILQUEUE_BATCH_PERIOD in this case seems to be irrelevant, and setting it to 1 second effectively gets it out of the way.


27-09-10 09:21

reporter   ~0051095

Perhaps (I don't know) the value MAILQUEUE_BATCH_PERIOD is being used for multiple things?

If that is the case, should it not be broken apart and new constants added - e.g.

MAILQUEUE_BATCH_PERIOD_SENDING (active sending period)
MAILQUEUE_BATCH_PERIOD_PAUSE (breathing space between batches)
MAILQUEUE_BATCH_PERIOD_LIMIT (the period minimum for the maximum sends)

Would clear the whole thing up nicely, and heavily reduce support requests in the forums.




29-04-11 12:05

administrator   ~0051198

I agree it will be better to split it out into multiple configs, and that should be done in the dev versions.

I've added some more explanation in the config for now, identifying this "dual function"

Thorsten Albrecht

30-04-11 09:02

reporter   ~0051251

Hello Michiel Dethmers,

thank you very much for correcting this issue.

Your explanation you added for MAILQUEUE_BATCH_PERIOD in revision 2663 is a _little_ bit clearer now. But the default value makes no sense when running phplist in a browser where the system is being reloaded after sending MAILQUEUE_BATCH_SIZE mails. Please set it to 1 or 10; or at least: add some different example values (e.g. 1 for running in a browser, 100 for running via commandline). Why should I let my server wait for 100s? Does it need recreation? No. The batch should be finished as soon as possible!


Thank you very much for clarifying this very, very, unimportant issue after 17 months I reported it. I think I was the only one on this planet having this sort of problem and of course, nobody else but me had any difficulties of running phplist in a browser. (Just to let you know: The forum is full of people who did run into this problem and who gave up frustrated. I nearly gave up, too.)

Now, phplist is running since 1,5 years for me, fine. I appreciate very much that you developed the system. But in the meantime when I had to solve the problems stated above (and about 10 other problems, too) I wished many times I had bought a commercial system with a good support - and no free system with a main programmer/contributor who finally reacts after 17 months and is not easy reachable by mail. This installation with phplist will definitly be the first and last installation in my life. For the time I had to invest to correct several issues (e.g. reporting this issue) I could have bought 10 commercial mailing systems with professional support.



30-04-11 12:34

administrator   ~0051253

I've added some more explanation

I'm sorry to hear you have such grief against phpList. Yes, indeed, those are sometimes the side effects of working with systems that are run by volunteers sacrificing their family life for some people they will never know, never meet or receive any money from. Things are not done against deadlines.

I still appreciate you taking the time to report this, which helps the community. If you want convenience, then Open Source is probably not your best choice, and indeed commercial systems will provide a better service. If you like, you can try phpList hosted, which has it all set up, without the need to even look at the config file.


01-10-13 21:02

administrator   ~0052298