Control site-wide deletion

POM Cache lets integrations veto a current-site clear or control the HTML rewrite-rule flush. These filters are coordination points, not authorization mechanisms.

Shared deletion gate

pom_cache_should_delete_site_cache is checked by the high-level HTML site-clear helper. The JSON site-clear helper also uses it before applying its own gate.

add_filter(
    'pom_cache_should_delete_site_cache',
    static function ( $allow, $context ) {
        if ( ! $allow ) {
            return false;
        }

        if (
            'my_plugin_import_item' === $context
            && my_plugin_import_is_still_running()
        ) {
            return false;
        }

        return true;
    },
    10,
    2
);

Preserve an existing veto. Use a narrowly named context so unrelated manual, editorial, and integration clears continue to work.

JSON-specific gate

After the shared gate, pom_cache_json_should_delete_site_cache can veto JSON without blocking HTML:

add_filter(
    'pom_cache_json_should_delete_site_cache',
    static function ( $allow, $context ) {
        if ( ! $allow ) {
            return false;
        }

        return 'my_plugin_html_only_deploy' !== $context;
    },
    10,
    2
);

Use this only when you can prove that the JSON representation did not change.

Rewrite-rule flushing

After an allowed HTML clear, POM Cache can run a soft WordPress rewrite-rule flush. Its default is:

• true for manual and manual_ajax;
• false for custom and automatic contexts.

pom_cache_delete_site_cache_flush_rewrite_rules can change that decision:

add_filter(
    'pom_cache_delete_site_cache_flush_rewrite_rules',
    static function ( $should_flush, $context ) {
        if ( 'my_plugin_permalink_migration' === $context ) {
            return true;
        }

        return $should_flush;
    },
    10,
    2
);

Do not force a rewrite flush after every content save or item in a bulk job. Flushing is much more expensive than deleting a cache file and is only relevant when rewrite rules actually changed.

Observe completed HTML clears

The low-level HTML clear emits:

add_action(
    'pom_cache_cleared',
    static function () {
        // Record a lightweight metric or schedule related work.
    }
);

pom_cache_cleared has no arguments. It does not identify the context, blog, deleted count, or JSON state. Read the current blog before leaving it if your observer needs site identity, and do not use this action as evidence that a JSON purge occurred.

Do not create permanent suppression

A global callback that always returns false leaves stale artifacts indefinitely. For a bulk job spanning several HTTP or queue requests, keep durable job state, guarantee cleanup on success and failure, and perform one final clear. A process-local variable is insufficient across requests.

Manual emergency clearing must remain available. Exempting manual contexts from temporary suppression makes recovery easier:

if ( in_array( $context, array( 'manual', 'manual_ajax' ), true ) ) {
    return $allow;
}

Filters do not secure the endpoint that initiates deletion. Your controller still needs authentication, capabilities, a nonce or REST permission callback, and input validation.