Controlar la eliminación en todo el sitio

POM Cache permite a las integraciones vetar un borrado del sitio actual o controlar el vaciado de las reglas de reescritura de HTML. Estos filtros son puntos de coordinación, no mecanismos de autorización.

Puerta de eliminación compartida

pom_cache_should_delete_site_cache es comprobado por el asistente de alto nivel de borrado de sitio HTML. El asistente de borrado de sitio JSON también lo utiliza antes de aplicar su propia puerta.

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
);

Conserva un veto existente. Usa un contexto con un nombre específico para que los borrados manuales, editoriales y de integración no relacionados sigan funcionando.

Puerta específica de JSON

Después de la puerta compartida, pom_cache_json_should_delete_site_cache puede vetar JSON sin bloquear 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
);

Usa esto solo cuando puedas demostrar que la representación JSON no cambió.

Vaciado de las reglas de reescritura

Después de un borrado de HTML permitido, POM Cache puede ejecutar un vaciado suave de las reglas de reescritura de WordPress. Su valor predeterminado es:

• true para manual y manual_ajax;
• false para contextos personalizados y automáticos.

pom_cache_delete_site_cache_flush_rewrite_rules puede cambiar esa decisión:

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
);

No fuerces un vaciado de reescritura después de cada guardado de contenido ni por cada elemento de un trabajo por lotes. El vaciado es mucho más costoso que eliminar un archivo de caché y solo es relevante cuando las reglas de reescritura realmente cambiaron.

Observar borrados de HTML completados

El borrado de HTML de bajo nivel emite:

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

pom_cache_cleared no tiene argumentos. No identifica el contexto, el blog, el número de elementos eliminados ni el estado de JSON. Lee el blog actual antes de abandonarlo si tu observador necesita la identidad del sitio, y no uses esta acción como evidencia de que se produjo una purga de JSON.

No crees una supresión permanente

Una función de retorno global que siempre devuelve false deja artefactos obsoletos indefinidamente. Para un trabajo por lotes que abarca varias solicitudes HTTP o de cola, mantén un estado de trabajo duradero, garantiza la limpieza tanto en caso de éxito como de error, y realiza un borrado final. Una variable local al proceso es insuficiente entre solicitudes.

El borrado manual de emergencia debe seguir estando disponible. Eximir los contextos manuales de la supresión temporal facilita la recuperación:

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

Los filtros no protegen el endpoint que inicia la eliminación. Tu controlador aún necesita autenticación, capacidades, un nonce o una función de retorno de permisos REST, y validación de entrada.