Arquitectura y fases de ejecución

POM Cache tiene dos almacenes de archivos independientes—HTML estático y JSON progresivo—y varias capas de entrega posibles. Entender cuándo se ejecuta el código es esencial al ampliar cualquiera de los dos almacenes.

El ciclo de vida del HTML

Fase 1: lectura temprana de la caché

Cuando WordPress tiene WP_CACHE habilitado y carga el drop-in de POM Cache advanced-cache.php, POM Cache puede clasificar la solicitud y servir un archivo HTML existente antes de la carga normal de los plugins de WordPress.

Esta fase es intencionadamente pequeña. Comprueba el método de la solicitud, la ruta, la consulta, las cookies de omisión, las constantes de la caché y la seguridad del archivo. Un acierto PHP correcto termina la solicitud con:

X-POM-Cache: Served static cache from PHP; phase=early

La llamada add_filter() de un plugin normal no se ha ejecutado necesariamente en este punto. Los hooks que se cargan mediante el arranque temprano pueden participar, pero las llamadas de retorno ordinarias de los plugins no deben tratarse como la única protección del contenido privado.

Fase 2: renderizado de WordPress y escritura en la caché

Cuando no se sirve ningún archivo temprano, WordPress se carga con normalidad. POM Cache almacena en búfer la respuesta generada, clasifica la solicitud y la respuesta finales, y escribe una representación completa elegible en index.html.

El visitante recibe el búfer renderizado normal. POM Cache crea una copia en caché separada, aplica pom_cache_buffer, añade comentarios de diagnóstico, escribe un archivo temporal y lo mueve atómicamente a su lugar.

Esta fase es donde los hooks convencionales de WordPress pueden influir de forma fiable en la generación y la escritura.

Entrega Apache opcional

Las reglas de reescritura de Apache copiadas pueden servir el archivo antes de que PHP y WordPress se ejecuten en absoluto. Ninguna llamada de retorno PHP ni cabecera de diagnóstico puede ejecutarse en un acierto de este tipo.

Las reglas son una copia de despliegue. Desactivar un ajuste de POM Cache no elimina ni neutraliza automáticamente una regla del servidor web instalada previamente. Cambia la propia regla al desactivar la entrega directa.

El ciclo de vida del JSON progresivo

El JSON progresivo tiene ajustes separados de maestro, lectura alternativa, escritura y purga.

POM Theme puede pedir a POM Cache una carga de archivo progresivo ya almacenada a través de pom_progressive_archive_cached_json. Si no se suministra ninguna, el tema genera el JSON y lo anuncia mediante pom_progressive_archive_json_generated; POM Cache lo almacena solo cuando el contexto de generación indica que es cacheable.

Una URL JSON elegible también puede servirse tempranamente desde el drop-in, o directamente mediante una regla Apache opcional. Los ajustes HTML no habilitan, limpian ni validan implícitamente el almacén JSON.

Flujo de invalidación

Los cambios de contenido pueden desencadenar la limpieza del HTML y del JSON del sitio actual cuando sus respectivos ajustes de purga están habilitados. Los ayudantes programáticos también pueden limpiar un almacén directamente.

El orden normal de alto nivel es:

1. se produce un evento de contenido o de integración;
2. los filtros de eliminación de entradas y de sitios pueden vetar la purga correspondiente;
3. POM Cache elimina los artefactos del sitio actual;
4. las solicitudes elegibles posteriores los regeneran;
5. una CDN externa debe invalidarse de forma independiente si todavía conserva objetos antiguos.

La invalidación del HTML y del JSON son independientes. Una puerta compartida pom_cache_should_delete_site_cache es consultada por ambos ayudantes de limpieza de sitio de alto nivel, mientras que el JSON tiene una puerta adicional específica del JSON.

Límite de CDN y compresión

POM Cache controla los artefactos del origen. Una CDN controla su propia caché de objetos, la negociación de compresión y la vida útil en el borde. Puede seguir devolviendo un objeto después de que se elimine el archivo del origen.

Trata la ruta de entrega completa como:

WordPress source → POM Cache artifact → PHP or Apache origin response → CDN → browser

Depura e invalida de izquierda a derecha.

Consecuencias de diseño para las extensiones

• Un filtro tardío puede impedir escrituras futuras, pero puede no bloquear un acierto temprano existente.
• Cuando una representación pasa a ser privada, limpia los archivos generados previamente como parte del despliegue.
• Nunca hagas que una clave de caché represente múltiples salidas que varíen por usuario, autorización, carrito, nonce o secreto.
• Usa invalidación HTML y JSON independiente cuando solo cambie una representación.
• No ejecutes licencias, APIs remotas, trabajo intensivo con la base de datos ni lógica específica del usuario en la ruta del acierto temprano.
• Prueba la entrega PHP antes que la entrega Apache opcional, y la entrega del origen antes que la CDN.