Borrar un sitio de forma segura en una red multisitio

POM Cache aísla los archivos generados por sitio de WordPress. Un borrado de «sitio» manual o automático utiliza el contexto actual del blog; no elimina intencionadamente la caché de todos los sitios.

Cómo se separan los sitios

HTML y JSON usan árboles independientes, y cada árbol contiene un espacio de nombres de sitio derivado del host público de inicio y, para una instalación en subdirectorio, de su ruta.

Conceptualmente:

cache/
├── pom-cache/
│   ├── site-a.example/...
│   └── site-b.example/...
└── pom-cache-json/
    ├── site-a.example/...
    └── site-b.example/...

Un sitio en subdirectorio puede tener este aspecto:

example.com/site-b/...

Esta estructura permite que una red comparta una única Cache Location física manteniendo las operaciones de cada sitio acotadas.

Procedimiento más seguro de ambos almacenes para un subsitio

  1. Abre el frontend del subsitio exacto.

  2. Confirma el hostname del navegador y la ruta del sitio.

  3. Confirma que la barra de administración pertenece a tu usuario autorizado.

  4. Selecciona Delete Cache en la barra de herramientas.

  5. Espera a:

    HTML and JSON cache deleted for the current site.
  6. Solicita una página y un lote progresivo en ese subsitio.

  7. Verifica la salida actual y la regeneración.

  8. Visita un segundo sitio y confirma que sus respuestas en caliente siguen disponibles.

Usar la barra de herramientas desde el frontend de destino hace que el sitio activo sea visualmente explícito.

Procedimiento con almacenes separados

Cuando solo HTML o solo JSON está obsoleto, usa la pantalla General de POM Cache del sitio de destino y la herramienta correspondiente:

  • Cache tools → Delete Cache para HTML;
  • Progressive JSON tools → Delete Progressive JSON Cache para JSON.

En multisitio, el acceso a estos ajustes está restringido a administradores autorizados a nivel de red. Los ajustes también pueden aparecer en Network Admin → Settings → POM Cache. Antes de seleccionar un botón, verifica el sitio actual que representa la solicitud; una pantalla de red no es un botón de borrado de toda la red.

Mapeo de dominios

En un subsitio con dominio mapeado, el host de inicio configurado del sitio define su espacio de nombres de caché. Verifica:

  • que la Home URL de WordPress sea el dominio público mapeado;
  • que las solicitudes lleguen al origen con el host esperado;
  • que las reglas directas de Apache o Nginx usen el mismo mapeo host-a-directorio;
  • que la CDN reenvíe el host requerido por la configuración del origen.

Una discrepancia puede provocar un fallo de caché. Más grave aún, una regla de servidor personalizada demasiado amplia puede mapear al archivo del sitio equivocado. Mantén acotadas las reglas de servidor generadas y prueba cada dominio mapeado antes de habilitar la entrega directa.

Redes en subdirectorio

En una red basada en rutas, la ruta del sitio forma parte del espacio de nombres. Prueba:

https://example.com/
https://example.com/site-a/
https://example.com/site-b/

No asumas que el host compartido por sí solo identifica el destino de la caché. Los mapeos directos del servidor deben conservar la ruta del subsitio igual que lo hace POM Cache.

Verificar el aislamiento

Usa una comprobación no destructiva de antes y después:

  1. Calienta una URL de HTML y una URL de JSON conocidas en el sitio A.
  2. Haz lo mismo en el sitio B.
  3. Registra los dos resúmenes de estado de cada sitio.
  4. Borra un almacén en el sitio A.
  5. Confirma que solo el recuento seleccionado del sitio A vuelve a cero.
  6. Solicita las mismas URLs del sitio B y confirma que siguen siendo aciertos.
  7. Regenera el sitio A y confirma que su hostname/ruta actual recibe los archivos nuevos.

Repite para HTML y JSON porque sus mapeos son independientes.

El alcance de la CDN también es por ruta del visitante

Un borrado del sitio actual en el origen no sabe cómo tu distribución de CDN agrupa los hosts. Si varios sitios comparten una distribución de CloudFront, incluye el host y el diseño de comportamiento al seleccionar las rutas de invalidación.

Una ruta de visitante como /* puede afectar a todos los hosts de una distribución compartida según su clave de caché y su semántica de invalidación. Prefiere rutas revisadas y específicas del sitio, o comportamientos separados donde la CDN los admita.

Lee Coordinar el borrado de POM Cache con la invalidación de la CDN antes de invalidar una distribución compartida.

Evita el borrado a nivel de todo el sistema de archivos

No borres manualmente toda la raíz común de caché para borrar un solo sitio. Usa los controles del sitio actual, que resuelven y validan el espacio de nombres previsto.

Si parece que se ha borrado el sitio equivocado, detente y revisa las URLs de inicio de WordPress, el contexto del blog, la ubicación de la caché, el mapeo de dominios y las reglas del servidor antes de continuar por la red.