Batch & Multisite

Batch processing

Batch processing breaks a large sync into chunks so it cannot time out halfway through. Instead of one request trying to move everything, the job is queued and worked through in pieces, with progress reported as it goes. You can leave the page and come back to it.

A job is Pending, Processing, Completed, or Failed, and a job that partly failed reports completed with errors rather than a plain success. Failed jobs can be retried, and a retry resumes from where the job stopped instead of starting again. Old job records are pruned automatically after about a week.

On multisite there are network-level screens for the batch dashboard, jobs, schedules, settings, and activity, so a network admin can see and manage work across subsites in one place. Element-level batching goes one level finer and processes individual Bricks elements rather than whole templates, which is what makes very large templates practical. It is driven mainly from WP-CLI.

Batch controls

Exports can be chunked by batch size and optional delay. Network batch settings and schedules coordinate bigger remote or multisite sync operations, while activity and job cleanup handlers keep the admin manageable.

Retries and recovery behave as labelled. The retry count is exact, pausing a job keeps its queued retries, and the element-level retry setting is applied. An interrupted job is detected and recovered instead of sitting on Running and blocking everything queued behind it, a job that mostly failed reports completed with errors rather than Completed, and schedules hold their cadence instead of drifting later after a late cron tick. Element-level imports take one backup per job rather than one per element.

When to use batch mode

Reach for batch mode when:

• You are syncing roughly ten or more templates at once.
• The media library is large.
• You are pushing to several remotes, or to many multisite subsites.
• A remote enforces rate limits.
• A workflow includes several heavy integrations.
• An operation has already timed out once.

Multisite: prefer shared storage first. If you run one parent site and several near-identical children, the simplest sync is file-based rather than remote-based. Point every site at the same storage location, whether that is a shared child theme or a custom path, and the parent's exports become the children's imports. There are no application passwords or remotes to maintain, and the files version-control cleanly.

Move to remotes and push workflows when the sites cannot share a storage location, or when you want what workflows add: dry runs, approval gates, selective pushes, and scheduling. A practical hands-off setup for children is a single import from storage workflow, scheduled to run after each deploy.