This add-on for Broadcast enqueues posts and processes them in the background, which circumvents WordPress and PHP time limits.

Automatic processing is done via AJAX when the user is viewing the post in the editor or in the post overview.

The queue can also be processed via a cron job, see the HTTP processing settings tab. It is recommended that you disable AJAX queue processing and just use HTTP processing.

FAQ

What is the limit?

Queue has been tested with a post broadcast to over 3500 blogs. It took a while (it was left overnight) but it got done.

Also tested with two posts queued to the same amount of blogs: 7000 queued posts.

Why is the queue not being filled?

Perhaps you have selected too many blogs for PHP to handle, together with all of the other post editing data that the server needs to accept. See the PHP max_input_vars setting.

A way to test for this is to use the Send To Many add-on to broadcast the post from the post overview. If the queue fills using Send To Many, then it’s probably the above PHP setting that needs to be modified. Or you can just continue using the Send To Many add-on to broadcast the post.

If you receive an Unable to save Broadcast queue data item error message, try raising your max_allowed_packet Mysql setting.

Why is the queue not being processed properly?

If you find a post is not disappearing from the queue after being processed, it’s probably due to an error during broadcasting.

In order to find out what the problem is:

• disable automatic processing of the queue in the settings
• enable WP_DEBUG
• enable Broadcast debug to browser mode
• manually process the item in the queue

You should see a long debug text. An error message should appear at the end, telling you what is wrong.

If you need help deciphering the debug dump, contact Plainview Plugins.