Comprender la invalidación en todo el sitio

En POM Cache, «en todo el sitio» significa el árbol de caché seleccionado completo para el sitio de WordPress actual. Es más amplio que una sola URL, pero más reducido que una red multisitio.

Acciones que usan este ámbito

Las extensiones compatibles también pueden solicitar o suprimir el borrado a través de las interfaces públicas para desarrolladores. Un propietario normal del sitio debería juzgar el resultado por el almacén seleccionado y el sitio actual, no por el nombre interno de un evento.

Estas purgas ordinarias de HTML/JSON conservan el documento 404 compartido. Actualízalo por separado con Cache tools → Delete 404 Cache después de cambiar cualquier cosa renderizada en su diseño, incluido el contenido de cabecera, pie o navegación.

Por qué una sola edición provoca un vaciado amplio

El contenido de WordPress está muy interconectado. Un producto editado puede cambiar:

• su página individual;
• un módulo de la página de inicio;
• los archivos de tipo de contenido y de taxonomía;
• el orden y la paginación de páginas posteriores;
• un recuento de navegación o una lista destacada;
• varios lotes progresivos de archivos;
• variantes traducidas.

POM Cache no construye un gráfico de dependencias para cada aparición renderizada. Vaciar el árbol completo del sitio actual proporciona un límite de frescura predecible.

El coste de regeneración

El borrado en todo el sitio elimina archivos en caliente. POM Cache no los precarga, de modo que la siguiente petición apta para cada URL se convierte en su generador:

full current-site clear
→ first page request renders HTML
→ first progressive batch request renders JSON
→ later matching requests reuse generated files

En un sitio de mucho tráfico, muchas URLs distintas pueden regenerarse a la vez. El impacto depende de la diversidad de rutas, no solo del tráfico total.

Elige las purgas automáticas deliberadamente

Activa la invalidación automática en todo el sitio cuando:

• la frescura del contenido deba seguir los guardados editoriales normales;
• las ediciones sean moderadas en comparación con el tráfico de visitantes;
• un elemento pueda aparecer en muchas respuestas públicas;
• el origen pueda absorber el calentamiento impulsado por la demanda.

Considera un vaciado manual controlado al final de un lote cuando:

• las importaciones actualicen cientos de entradas o términos;
• las traducciones se generen en un lote largo;
• los editores guarden muchos registros relacionados antes de publicar el estado final;
• un despliegue cambie varias plantillas globales a la vez.

El objetivo no es evitar la invalidación. Es vaciar una sola vez, en el punto en que la fuente alcanza un estado final coherente.

Cambios que necesitan una decisión manual

Los interruptores de entradas y términos cubren sus eventos de WordPress documentados. No implican que cada cambio de configuración vacíe la caché.

Revisa ambos almacenes después de:

• ajustes globales de tema o plantilla;
• cambios de navegación o pie renderizados en todas las páginas;
• cambios de tamaño de lote o agrupación de archivos;
• campos personalizados cambiados fuera del manejo normal de entradas;
• actualizaciones directas de base de datos;
• sincronización externa;
• cambios de ruta pública, nombre de host o prefijo de idioma;
• cambios de reescritura del servidor.

Algunas integraciones compatibles pueden invalidar explícitamente, pero POM Cache no activa por defecto una política general de «purgar en cada guardado de ajustes».

Country pricing zones de POM Tweaks es una integración explícita. Vacía el HTML del sitio actual cuando cambian las zonas, los precios de productos regionales canónicos o las opciones de seguridad de caché. La activación y desactivación de plugins, las actualizaciones de plugins o temas gestionadas por WordPress, los guardados relevantes de ajustes de POM Tweaks y los cambios de tema colocan primero la caché en un estado pendiente conservador; la siguiente petición pública anónima que de otro modo sea apta para el HTML compartido recalcula si el contrato universal y la ruta de proxy pública son seguros. WP-CLI, cron, la administración, REST, AJAX y las peticiones autenticadas no pueden promover este estado persistido a seguro.

El vaciado automático solo afecta a los archivos de origen. Purga o invalida el HTML de CDN coincidente después de desplegar una nueva versión de POM Theme, POM Tweaks o de la integración de POM Cache, y después de resolver un estado de compatibilidad inseguro.

Recuperarse sin problemas

Después de un vaciado amplio:

1. Prueba la página de inicio y una página interior representativa en el origen;
2. Prueba los archivos progresivos estándar y dividido si ambos existen;
3. Incluye cada idioma público;
4. Verifica que las sesiones autenticadas y de comercio sigan evitando la entrega compartida anticipada;
5. Observa la tasa de errores y el tiempo de respuesta del origen durante el calentamiento;
6. Invalida las rutas de visor de CDN necesarias solo después de que el origen sea correcto;
7. Confirma que el borde público se rellena con la salida actual.

Si solo se vació un almacén, verifica explícitamente que el almacén conservado siga presente y actualizado.

Límite multisitio

POM Cache resuelve el borrado con el ID de blog actual y su directorio específico del sitio. Una purga en todo el sitio no es una purga en toda la red.

Esta seguridad depende de operar en el contexto de sitio previsto y de que las reglas del servidor asocien cada host/ruta con el espacio de nombres de caché correspondiente. Lee Clear one site safely on a multisite network antes de realizar tareas de mantenimiento en varios sitios.