Queue

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.

If you are using the Gutenberg Block Editor, either refresh the editor in order to get the queue to process or go back to the post overview. Another alternative is to 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.

Unable to save Broadcast queue data item

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

Queue breaking

Some hosts, HostGator for example, have been known to break the queue.

Symptom: Queue works, then stops working. Can be made to temporarily work again by uninstalling and then reactivating the add-on.
Diagnosis: The cleanup command (OPTIMIZE TABLE) is breaking the data or item tables.
Solution: Prevent database cleanup by adding the following to your functions.php: add_filter( ‘broadcast_queue_clean_queue’, ‘__return_false’ );

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.

Videos

Screenshots

: Broadcast meta box showing the queue is ready

: Broadcast meta box showing the queue being processed

: Overview of posts in queue

: HTTP cron processing settings

: General settings

: Posts settings

: Retry settings

Notes

HTTP processing

During a call to the HTTP process URL (preferrably by a cron job) the items in the queue will be processed until either of the following limits are reached:

The items per process limit it hit.
There is less than 25% of the PHP maximum execution time left.
The average time to broadcast an item so far in the process exceeds the PHP execution time left.

Ensure that your PHP time limit is smaller than your cron interval. If not, then you will get incomplete broadcasts with the linking left in a broken state.

If you find that the queue is not processing your very large posts (lots of images that need to be copied, for example) then set the items per process setting to just 1 post.

If you want the queue to be processed even faster, ask your webdev to write a looping script that wgets the HTTP processing URL. Like this, for example:


#!/bin/bash

while ( true ); do
        wget -q -O /dev/null https://SERVERNAME.COM/wp-login.php?broadcast_queue_process=YOUR_UNIQUE_KEY
        sleep 2
done

Start the script on the server (perhaps using supervisor?) and disable ajax processing of the queue, since it is no longer needed.

Keep queued posts

When queuing a post, any old items in the queue related to this post are purged.

So if a post is being broadcasted to 100 blogs, and then the post is requeued without the queue having finished, all old items are removed before the new 100 items are placed into the queue.

Menu access

This snippet shows how to control access to the queue menu.

Retries

If you wish to limit how many times a post is processed in the queue, perhaps as a way to detect memory or timeout errors, change this setting. Usually, Queue will try and process and reprocess until it works.

If the limit is reached, the admin will receive an e-mail explaining the queue process error.

Where to buy

This add-on is a part of the following packs:

Article features

This add-on is featured in the following articles:

Comments

Jayesh says:

2017-08-24 at 09:29

Hi There,
Is there any API or option by using we can process particular? post first if it is at end in queue?

Reply
1. Edward says:
  
  2017-08-24 at 09:55
  
  No, not currently. If you need something broadcasted immediately, use the Broadcasting API.
Kyle says:

2019-10-29 at 16:33

Is there a setting somewhere that I’m missing that will allow me to provide access to the Queue for any user role I choose? Trying to allow a custom role to access it but am currently unable to do so.

Reply
1. Edward says:
  
  2019-10-29 at 16:43
  
  I’ve added a snippet that shows how to provide access to the queue menu. Does that solve your problem?
Amanda McCoy says:

2020-08-18 at 00:29

I’m trying to publish many posts (up to 1,800) to one blog rather than 1 post to many blogs. Does this plugin help with that?

Reply
1. Edward says:
  
  2020-08-18 at 08:09
  
  The add-on you’re looking for is probably Send To Many – but the Queue will also help you avoid timeouts when broadcasting.

Broadcast

by Plainview Plugins