Rastrear una solicitud de generación de caché HTML

Usa el comando wp pom-cache generate_debug cuando una página pública no crea su archivo index.html esperado y las comprobaciones de configuración normales no explican el motivo. El comando realiza una única solicitud anónima real al frontend e informa de cada decisión de POM Cache sin necesidad de WP_DEBUG ni de registro de depuración persistente.

La solicitud sigue la ruta de renderizado normal de WordPress y puede crear o reemplazar el archivo HTML estático de la página de destino. Ejecútalo solo para una página pública cuya salida compartida sea segura de cachear.

Requisitos previos

• Acceso por shell con WP-CLI disponible.
• POM Cache activo en el sitio seleccionado.
• El sitio de multisitio correcto seleccionado con la opción global --url.
• Una --page-url pública absoluta cuyo host coincida con la URL de inicio de ese sitio seleccionado.
• Un origen que pueda recibir una solicitud HTTP desde el servidor que ejecuta WP-CLI.

El comando no requiere el modo de depuración de WordPress, Query Monitor ni una sesión de navegador autenticada.

Ejecutar un diagnóstico normal

Usa la opción global --url para seleccionar el sitio de WordPress y --page-url para identificar la página del frontend:

wp --url=https://www.example.com pom-cache generate_debug \
  --page-url=https://www.example.com/

El comando arma un token de solicitud de cinco minutos, realiza una solicitud sin cookies, elimina su parámetro de diagnóstico privado antes de las comprobaciones de elegibilidad normales y borra el rastreo almacenado cuando el comando termina.

Para comparar una página que funciona con una que falla, ejecuta el comando una vez por cada URL exacta:

wp --url=https://www.example.com pom-cache generate_debug \
  --page-url=https://www.example.com/working-page/

wp --url=https://www.example.com pom-cache generate_debug \
  --page-url=https://www.example.com/

Omitir una CDN o un proxy inverso

Si el nombre de host público se resuelve hacia una CDN, pasa una URL completa de origen o de bucle local con la misma ruta y consulta:

wp --url=https://www.example.com pom-cache generate_debug \
  --page-url=https://www.example.com/ \
  --request-url=http://127.0.0.1/

El comando envía el host público en la cabecera HTTP Host para que WordPress seleccione el sitio de multisitio previsto. Solo el esquema, el host y el puerto pueden diferir entre --request-url y --page-url.

Usa --skip-ssl-verify solo para un origen HTTPS local o privado de confianza con un certificado que WP-CLI no pueda validar. No lo uses para una solicitud pública normal. Usa --timeout=<seconds> para cambiar el tiempo de espera HTTP desde su valor predeterminado de 20 segundos; los valores aceptados van de 5 a 60.

Leer el resultado

La tabla de rastreo sigue la solicitud a través de estas etapas:

1. bootstrap demuestra que el token llegó a WordPress, coincidió con la URL prevista y se eliminó antes de la evaluación de la caché.
2. phase2 demuestra que POM Cache inició su búfer de salida HTML o explica por qué no lo hizo.
3. pom_cache_ob_callback informa del resultado exacto de elegibilidad a nivel de solicitud.
4. pom_cache_get_ob informa de la comprobación de integridad de la respuesta y de cada resultado relevante de directorio, archivo temporal, escritura, tamaño y cambio de nombre.

Una conclusión satisfactoria incluye la index.html final exacta y el recuento de bytes. Una conclusión abandonada o fallida incluye un código de motivo estable. Los códigos de motivo habituales incluyen:

• donotcachepage_defined: otro componente definió DONOTCACHEPAGE durante el renderizado;
• query_string: la URL de destino real contiene una cadena de consulta;
• is_redirect, is_rest, is_feed o is_robots: WordPress clasificó la respuesta como un tipo de solicitud excluido;
• unknown_page_type: WordPress no identificó un tipo de página conocido;
• missing_eof_marker: la salida final carece de un marcador de cierre reconocido de HTML, feed, sitemap o XML;
• cache_directory_unavailable o temporary_file_open_failed: no se pudo crear el directorio o el archivo temporal;
• cache_file_publish_failed: no se pudo cambiar el nombre del archivo temporal al archivo de caché final;
• static_file_written: el archivo HTML estático completo se escribió correctamente.

La tabla puede incluir rutas de caché absolutas, permisos, errores del sistema de archivos de PHP, estado de la respuesta, cabeceras de la respuesta y nombres de cookies cuando una cookie causó la omisión. Nunca almacena el cuerpo de la respuesta, los valores de las cookies, las cabeceras de autorización ni el token de diagnóstico claro.

Trata la salida como evidencia operativa privada: elimina las rutas absolutas innecesarias y las cabeceras de infraestructura antes de compartirla fuera de tu canal de soporte.

Si ningún rastreo llega a WordPress

No trace reached WordPress significa que la solicitud HTTP no llegó a esta instalación de POM Cache con su token de diagnóstico. Las causas típicas son un acierto de caché de la CDN, un proxy que elimina la consulta o la cabecera personalizada, el enrutamiento DNS hacia otro origen o un fallo de conexión HTTP.

Reintenta con --request-url apuntando directamente al origen. Verifica también que el host público siga coincidiendo con el sitio seleccionado por --url y que el origen enrute la cabecera Host suministrada al sitio de multisitio correcto.

Lo que este comando no demuestra

El comando demuestra si POM Cache generó el archivo HTML estático del origen y muestra las cabeceras de respuesta seleccionadas. No demuestra que Apache, Nginx, CloudFront u otra CDN sirva posteriormente ese archivo, lo cachee o lo comprima. Después de una escritura satisfactoria, continúa con Verificar un acierto de caché y Verificar la compresión de la respuesta.