Controlar la elegibilidad de la caché estática
POM Cache rechaza las solicitudes no seguras antes de servir o escribir HTML estático. Las extensiones deberían añadir exclusiones más específicas, no anular las protecciones existentes.
Excluir una lectura de HTML en caché
Usa pom_cache_can_serve_cached_file para vetar un archivo ya servido por PHP:
add_filter(
'pom_cache_can_serve_cached_file',
static function ( $can_serve, $file, $context ) {
unset( $file );
if ( ! $can_serve ) {
return false;
}
$request_uri = isset( $context['request_uri'] )
? (string) $context['request_uri']
: '';
if ( str_starts_with( $request_uri, '/account-preview/' ) ) {
return false;
}
return true;
},
10,
3
);
El callback primero conserva un rechazo existente. Nunca devuelvas true solo porque tu propia exclusión no coincida; hacerlo podría volver a habilitar una lectura rechazada por una cookie de omisión o DONOTCACHEPAGE.
Las claves de contexto conocidas son:
phase;file;request_uri;request_method;has_cache_bypass_cookie;donotcachepage_defined;is_user_logged_in.
Trata el array como extensible y comprueba cada clave antes de leerla.
Limitación de la fase inicial
Las lecturas de HTML normales usan la fase early cuando no hay cookie de omisión y DONOTCACHEPAGE no está definida. Esa decisión puede producirse a través de advanced-cache.php antes de que los plugins convencionales hayan registrado sus filtros. Las políticas explícitas registradas mediante pom_cache_query_variant usan en su lugar la fase query en wp_loaded; sus valores finitos, la expiración y las comprobaciones de sesión adicionales se aplican antes de que se ejecute este filtro de veto. La fase general late permanece desactivada por defecto.
En consecuencia, un callback de un plugin normal no es un límite de privacidad completo para una página ya almacenada en caché. Al añadir comportamiento privado:
- detén o limita las futuras escrituras de HTML de la funcionalidad;
- desactiva las reglas directas de Apache copiadas para la ruta afectada;
- borra los archivos HTML existentes;
- invalida las cachés de borde externas;
- prueba las rutas de solicitud limpias y autenticadas.
Usa el diseño de la aplicación y la configuración de la caché —no solo un filtro de lectura tardío— para mantener las rutas privadas fuera de la caché.
Excluir la generación con DONOTCACHEPAGE
Cuando tu código sepa durante una solicitud normal de WordPress que la respuesta debe permanecer dinámica, define la constante estándar antes de que POM Cache evalúe el búfer completado:
add_action(
'template_redirect',
static function () {
if ( is_page( 'account-preview' ) && ! defined( 'DONOTCACHEPAGE' ) ) {
define( 'DONOTCACHEPAGE', true );
}
},
1
);
Esto evita que el renderizado actual de WordPress se escriba. No elimina un archivo anterior y no puede interceptar la entrega de Apache ni una respuesta temprana que ya haya finalizado.
Comportamiento de página desconocida
pom_cache_only_cache_known_pages tiene por defecto un valor veraz (truthy). Evita que POM Cache escriba salida que WordPress no pudo clasificar como una página conocida.
Cambiarlo a false amplía la elegibilidad:
add_filter( 'pom_cache_only_cache_known_pages', '__return_false' );
Esto no se recomienda intencionadamente como una solución genérica para «la página no se almacena en caché». Puede admitir endpoints personalizados, respuestas de tipo error o salida cuyo contrato de frescura se desconoce. Prefiere registrar la ruta correctamente en WordPress y probar su comportamiento público.
Matriz de verificación
Para cada personalización de la elegibilidad, prueba:
- fallo anónimo y posterior acierto;
- solicitud con sesión iniciada;
- cada cookie de sesión o de comercio usada por la funcionalidad;
- cadenas de consulta significativas;
POST,PUTyDELETE;- rutas de error y de redirección;
- archivo existente después de que la funcionalidad se vuelva privada;
- entrega de PHP, Apache y CDN por separado.
Una extensión solo es correcta si controla tanto la generación futura como cualquier artefacto producido antes de que existiera la regla.