Batch Processing & Recompute

BricksMembers provides batch processing functions for recomputing structure paths, progress totals, and drip unlocks. Use these functions when you need to recalculate data after bulk changes.

Unified Recompute

The easiest way to recompute all data for structures. Orchestration is centralized in the drip orchestration service for consistent scheduling:

Drip recompute is also the correct path after saving a drip rule, deleting a drip rule, or changing a post-level drip override. That now includes overrides saved from the standard post editor and overrides saved through the Content & Structures Quick Edit modal or staged structure commits. The scheduler still handles structure-scoped rules, Selected Posts rules, and broad Post Type rules in the same pipeline.

Timed drip execution now uses a hybrid model. Full drip recompute still rebuilds unlocked rows, but it also seeds a lightweight exact due queue per user. Future timed unlocks are then processed by exact single-event WP-Cron buckets, with hourly reconciliation and throttled authenticated-session wake-ups as safety nets. This keeps runtime unlock checks fast without relying on broad frequent cron sweeps.

Single-user background backfills are intentionally conservative for due-queue updates: partial worker passes can move the stored next-due timestamp earlier immediately, but later-or-cleared corrections are finalized by the next exact pass (full recompute, exact inline backfill, or the due worker itself). That keeps unlocks on time without introducing a second schedule table.

In Bricks query loops, batch preloading now computes full drip status objects for the candidate posts instead of deriving a minimal locked/unlocked guess from persisted rows alone. That keeps query filters, dynamic tags, and Bricks conditions aligned with the main runtime evaluator even while async row persistence is still in flight.

Normal loop preloading now scopes preserved unlock-row reads to the current loop candidates. Full-history reads are kept for backfill or rebuild-style flows that genuinely need the entire user unlock history.

// Recompute everything for specific structures
brm_schedule_unified_recompute( [
    'structures' => [ 'courses' ],
    'spm' => true,      // Structure paths
    'progress' => true, // Progress totals
    'drip' => true      // Drip unlocks
] );

// Recompute for all structures
brm_schedule_unified_recompute( [
    'structures' => null, // All structures
    'spm' => true,
    'progress' => true,
    'drip' => true
] );

// Recompute for specific post types
brm_schedule_unified_recompute( [
    'post_types' => [ 'lesson' ],
    'spm' => true,
    'progress' => true,
    'drip' => true
] );

When to Recompute

Recompute data when you make bulk changes that affect structure relationships or totals:

After importing content in bulk
After reorganizing structure hierarchy
After bulk content updates
When progress totals seem incorrect

Adjusting Batch Sizes

Batch sizes are managed internally based on host profiling. For user backfill specifically, you can adjust the number of posts processed via brm_unlocks_user_worker_posts_per_page if needed.

The exact due-bucket worker size is also configurable via brm_drip_due_bucket_users_per_run, and the wake-up throttle / lead windows can be tuned with brm_drip_due_wake_throttle_seconds, brm_drip_due_wake_lead_seconds, and brm_drip_due_worker_timeout_ms.

Drip Stream Types

Structure streams – Built per structure, post type, and optional parent filter
Selected Posts streams – Built from the combined selected post IDs for rules of the same post type
Post Type streams – Built from the published posts of one post type, optionally narrowed by taxonomy + selected terms
Post overrides – Custom overrides piggyback on the normal drip recompute path; no separate worker family is introduced

Cohort timing now evaluates the same way for all three stream types. The structure-only pieces are the full prerequisite payload and cadence-boundary inputs: required_posts, delay_after_prev_days, prereq_combine, previous_within, require_all_previous, and cadence_boundary. Non-structure rules stay time-based only, with triggers such as registration, level assignment, group join, fixed datetime, cohort timing, and cadence. Post Type rules can additionally narrow stream membership by one taxonomy plus selected terms, while runtime cadence order remains rule-specific.

Monitoring Progress

Batch processing runs automatically and updates progress. You can check progress via admin interface or hooks:

Batch processing completion is tracked via transients. Check completion status programmatically:

// Check if batch processing is complete
$spm_completed = (int) get_transient( 'brm_batch_spm_completed' );
$progress_completed = (int) get_transient( 'brm_batch_progress_completed' );
$drip_completed = (int) get_transient( 'brm_batch_drip_completed' );

if ( $spm_completed ) {
    error_log( 'SPM batch processing completed' );
}

Best Practices

Use unified recompute: Simplest way to ensure all data is up to date
Run during low traffic: Batch processing can be resource-intensive
Adjust batch sizes: Match your hosting capabilities
Monitor progress: Use hooks to track batch completion