Filtrar la salida renderizada

POM Cache ofrece dos filtros de salida con públicos diferentes. Elige el filtro según si la modificación debe verla el visitante actual o si solo deben verla las futuras aciertos de caché.

Cambiar la respuesta en vivo con pom_cache_ob_callback_filter

Este filtro se ejecuta sobre el búfer renderizado antes de las comprobaciones finales de elegibilidad:

add_filter(
    'pom_cache_ob_callback_filter',
    static function ( $buffer ) {
        return str_replace(
            '<meta name="generator" content="Example">',
            '',
            (string) $buffer
        );
    }
);

La cadena devuelta:

• se envía al visitante actual;
• se evalúa para comprobar la integridad y elegibilidad de la respuesta;
• se usa como contenido candidato si POM Cache escribe un archivo.

No uses este hook solo para decidir si se debe almacenar en caché. Usa DONOTCACHEPAGE o un mecanismo de elegibilidad para ese fin. Devuelve siempre una cadena y evita el análisis costoso de todo el documento en cada renderizado de página dinámica.

Cambiar solo la copia almacenada con pom_cache_buffer

pom_cache_buffer se ejecuta después de que POM Cache haya decidido escribir y haya añadido su comentario de tiempo de generación:

add_filter(
    'pom_cache_buffer',
    static function ( $cached_copy ) {
        return str_replace(
            '<!-- public-cache-marker -->',
            '<span class="cache-label">Cached public response</span>',
            (string) $cached_copy
        );
    }
);

El visitante actual sigue recibiendo el renderizado original. Los aciertos de caché posteriores reciben la copia filtrada. POM Cache añade sus comentarios de caché finales después de este filtro.

Esta diferencia puede hacer confuso el diagnóstico. Usa transformaciones de solo copia almacenada únicamente cuando la divergencia sea intencional, determinista y esté documentada.

Salida que nunca debe introducirse

Ninguno de los dos hooks es seguro para:

• nombres de usuario o datos de cuenta;
• carritos, sesiones o resultados de autorización;
• nonces o tokens de un solo uso;
• secretos específicos de la solicitud;
• contenido aleatorio;
• marcas de tiempo que deberían actualizarse en cada solicitud;
• geolocalización o experimentos sin una clave de caché segura e independiente.

La salida debe ser idéntica para cada visitante representado por el archivo de caché de la URL.

Conservar un documento válido

POM Cache normalmente requiere un marcador de finalización reconocido antes de escribir. Una transformación que elimine una etiqueta de cierre o cree una salida mal formada puede impedir la generación o almacenar contenido inutilizable.

Al cambiar el búfer:

1. prueba la respuesta sin caché;
2. inspecciona el archivo generado mediante un acierto posterior;
3. valida el marcado y la codificación de la respuesta;
4. compara las cabeceras y el cuerpo para las solicitudes anónimas y las de usuarios conectados;
5. confirma que la invalidación regenera el resultado transformado.

Evitar la recursión accidental o los efectos secundarios

Mantén las devoluciones de llamada puras: transforma la cadena proporcionada y devuélvela. No hagas solicitudes remotas, guardes entradas, borres cachés ni dispares otro renderizado del front-end dentro de un filtro de salida.

Si la transformación proviene de un activo de tiempo de despliegue o de un valor de configuración, borra la caché HTML después de que ese valor cambie. POM Cache no puede inferir las dependencias introducidas por devoluciones de llamada de búfer de terceros.

Proteger la publicación final

Las integraciones cuyo contenido externo puede desaparecer mientras se renderiza una página pueden vetar la publicación final del archivo con:

bool apply_filters('pom_cache_publish_html', true, string $filename, string $html)

Este filtro se ejecuta inmediatamente antes de que se publique el archivo HTML temporal. Devolver false descarta ese candidato y deja intacta la respuesta en vivo. Conserva un veto previo. Usa una comprobación de identidad local acotada; nunca realices una solicitud remota en esta devolución de llamada.

Una integración puede mantener su propio bloqueo de corta duración durante la publicación. Libéralo con la acción de finalización emparejada:

do_action('pom_cache_html_publish_finished', string $filename, bool $published)

La acción de finalización se ejecuta después de un intento de publicación y cuando el filtro de publicación lo veta. No es una notificación para cada renderizado de página: los fallos de elegibilidad anteriores nunca llegan a este par. Los bloqueos también deben expirar de forma segura si el proceso PHP termina de forma inesperada.

Este par evita que una eliminación externa concurrente vaya seguida de la publicación de un renderizado en curso más antiguo. No cambia retroactivamente un estado HTTP ya enviado a un visitante.