Design cache invalidation for bulk operations

Importers and synchronization jobs can save hundreds of posts and terms. Because POM Cache's automatic post invalidation clears the current site's full store, deleting it once per item wastes I/O and can repeatedly flush related work.

The target pattern is: suppress only the job's redundant automatic clears, then clear each affected site and representation once after the batch becomes publicly consistent.

Prefer an application-level commit point

If you control the importer, avoid modifying POM Cache's filters globally. Let the importer collect affected sites and representations, then call the public helpers at the end:

$needs_html = false;
$needs_json = false;

foreach ( $items as $item ) {
    my_plugin_import_item( $item );
    $needs_html = true;
    $needs_json = true;
}

if ( $needs_html && function_exists( 'pom_cache_delete_site_cache' ) ) {
    pom_cache_delete_site_cache( 'my_plugin_import_complete' );
}

if ( $needs_json && function_exists( 'pom_cache_json_delete_site_cache' ) ) {
    pom_cache_json_delete_site_cache( 'my_plugin_import_complete' );
}

This works when the import path itself does not trigger the built-in automatic clear for every item. If it does, use a narrowly scoped gate.

Scope temporary suppression

The shared site-deletion filter receives a context. Suppress only known importer contexts while a verified job state says the batch is open:

add_filter(
    'pom_cache_should_delete_site_cache',
    static function ( $allow, $context ) {
        // An importer must never override a veto registered elsewhere.
        if ( ! $allow ) {
            return false;
        }

        $bulk_contexts = array(
            'save_post',
            'post_change',
            'set_object_terms',
            'term_change',
        );

        if (
            in_array( $context, $bulk_contexts, true )
            && my_plugin_current_job_defers_cache()
        ) {
            return false;
        }

        return true;
    },
    10,
    2
);

The job-state function must not rely on an untrusted request flag. Tie it to an authenticated worker, command, lock, or durable import record.

Jobs spanning multiple requests

For background queues:

1. create a durable job record with affected blog IDs and required stores;
2. mark deferral active before the first mutation;
3. update progress idempotently;
4. on successful completion, clear once per affected blog;
5. on cancellation, timeout, or failure, also clear before releasing deferral;
6. provide an authorized recovery action that clears caches and closes a stranded job.

A PHP static variable or in-memory flag disappears after one request and cannot protect a queue safely.

Multisite

Deduplicate blog IDs. For each authorized site, switch context, clear HTML and/or JSON with a custom completion context, and restore the original blog. Do not use a recursive network filesystem delete.

Avoid these patterns

• Returning false for every deletion indefinitely.
• Blocking manual or manual_ajax recovery clears.
• Calling flush_rewrite_rules() for each imported item.
• Clearing a CDN before the import reaches a consistent origin state.
• Purging only HTML when progressive JSON contains the same changed data.
• Re-enabling public delivery before the final clear succeeds.

Validate the batch

After completion, request representative singular pages, archives, languages, facets, and progressive batches. Confirm that the origin regenerated current data, then invalidate the exact CDN objects or approved path group.