Gestiona errores, páginas 404 y marcadores de finalización

POM Cache excluye de forma predeterminada las respuestas fatales, incompletas y la mayoría de las de tipo error. Las extensiones deben conservar ese comportamiento conservador, salvo que una página de error cuente con una estrategia deliberada de frescura e invalidación.

wp_die() respuestas

Cuando se selecciona la gestión de wp_die de POM Cache, pom_cache_disable_cache_on_wp_die se establece de forma predeterminada en true. POM Cache define entonces DONOTCACHEPAGE.

add_filter( 'pom_cache_disable_cache_on_wp_die', '__return_true' );

Por lo general, no hay motivo para añadir este callback, porque se limita a repetir el valor predeterminado. El hook existe para integraciones excepcionales, pero devolver false puede permitir que una respuesta de error o de autorización avance hacia la evaluación normal de la caché. No desactives la salvaguarda de forma global para almacenar en caché una página pública personalizada; crea esa página mediante una ruta normal de WordPress en su lugar.

Caché de páginas 404

Un documento 404 público compartido se habilita de forma predeterminada cuando está activada la caché HTML. Desactiva su generación y su entrega en una plantilla 404 dinámica con:

add_filter( 'pom_cache_404', '__return_false' );

El valor predeterminado equivale a:

add_filter( 'pom_cache_404', '__return_true' );

Este filtro controla el documento compartido, no los archivos 404 por URL. Las URL inexistentes nunca se escriben en el árbol habitual de la caché de páginas, ni siquiera cuando el filtro devuelve true. WordPress resuelve cada solicitud y completa la gestión de redirecciones antes de la reutilización; las páginas recién disponibles no quedan ocultas por el documento compartido. Los callbacks existentes que devuelven false siguen forzando el renderizado dinámico.

Habilita la caché de páginas 404 únicamente cuando:

• el cuerpo de la 404 sea totalmente público y determinista;
• no se requieran datos específicos del visitante ni tokens de formulario que caduquen;
• sea aceptable un refresco manual tras cambiar el diseño compartido;
• la CDN conserve el estado 404 y la política no-cache de la respuesta;
• hayas probado una URL que pase de inexistente a disponible.

El filtro no recibe la ruta solicitada, por lo que no constituye por sí solo una política específica por ruta.

El documento de origen procede de un loopback anónimo firmado hacia una ruta inexistente fija, nunca de una respuesta arbitraria de un visitante. Las respuestas fallidas o personalizadas no se promocionan. El almacén independiente sobrevive a los purgados ordinarios; usa Settings → POM Cache → General → Cache tools → Delete 404 Cache para refrescarlo. Consulta Comportamiento de la 404 compartida para conocer los requisitos de idioma, solicitud y generación.

Marcadores de finalización

Antes de escribir, POM Cache compara la respuesta con pom_cache_eof_tags. La expresión regular predeterminada reconoce salida HTML, RSS, feed, de conjunto de URL o XML completada:

/(<\/html>|<\/rss>|<\/feed>|<\/urlset|<\?xml)/i

Una integración que produzca un formato público completo diferente puede ampliar la expresión:

add_filter(
    'pom_cache_eof_tags',
    static function ( $pattern ) {
        return '/(<\\/html>|<\\/rss>|<\\/feed>|<\\/urlset|<\\?xml|<\\/catalog>)/i';
    }
);

Devuelve una expresión regular completa y válida, incluidos los delimitadores y los modificadores. No concatenes en ella entrada de usuario sin escapar.

Añadir un marcador débil, como un <div> común o una sola llave de cierre, puede permitir que se almacenen en caché respuestas truncadas. El marcador debe demostrar que el documento previsto terminó de renderizarse.

Siguen aplicándose otras exclusiones

Superar la comprobación de finalización o habilitar las páginas 404 no elude:

• las comprobaciones de método de solicitud;
• las exclusiones de consulta y de vista previa;
• la clasificación REST, de feed, de robots, de redirección o de tipo de respuesta;
• las cookies de omisión;
• DONOTCACHEPAGE;
• los ajustes maestros de tiempo de ejecución;
• la detección de errores fatales;
• los requisitos de búfer no vacío.

Prueba los errores con el código de estado, las cabeceras y el cuerpo exactos. Un navegador que muestre un documento de error atractivo puede estar devolviendo igualmente una redirección, una página generada por la CDN o un estado HTTP incorrecto.