Sincronización específica de contenido de WordPress
La sincronización específica de contenido publica los efectos públicos de los cambios de contenido de WordPress sin rastrear el sitio completo. Está disponible con una suscripción Professional o Agency activa, al igual que la publicación incremental, y se ejecuta mediante una regla guardada del programador y el ejecutor de colas externo de @smart-cloud/publisher-exporter.
Qué sigue una regla
Cada regla selecciona uno o varios tipos de contenido públicos, consultables públicamente y con enlaces permanentes estables. WordPress registra sus transiciones públicas, entre ellas:
- publicación y actualizaciones de contenido publicado,
- cambios de taxonomía y del estado fijado,
- retirada de publicación, envío a la papelera y eliminación permanente,
- cambios del enlace permanente, el autor y la fecha de publicación que afectan a las superficies públicas activadas.
La regla puede conciliar archivos de tipos de contenido y taxonomías, la página de entradas configurada, archivos opcionales por autor y fecha, paginación y la cadena de mapas del sitio. Use Explicit listing routes para páginas con Query Loop u otras superficies de listado cuyas consultas WordPress no pueda inferir con fiabilidad. Las rutas deben ser relativas al sitio, una por línea, como / o /insights/.
Por eso, publicar o modificar una sola entrada puede actualizar varios archivos estáticos: la propia entrada puede ser solo un miembro de un conjunto afectado de listados, archivos, paginación y mapas del sitio.
Establecer primero la línea base
Una publicación completa o incremental normal debe completarse correctamente y establecer una línea base verificada antes de implementar trabajo específico. La línea base vincula la regla con la versión actual de WordPress, el origen y el destino, el comportamiento de reescritura, la configuración del mapa del sitio, el alcance seleccionado y el manifiesto de rastreo de confianza.
Ejecute otra publicación normal cuando la administración indique New baseline required. Las causas habituales son una versión nueva del tema o un plugin, cambios en enlaces permanentes o mapas del sitio, cambios de reescritura, otro destino de implementación o modificaciones del alcance de sincronización de contenido. La sincronización de contenido se detiene de forma segura en lugar de ampliarse implícitamente a un rastreo completo cuando la línea base queda obsoleta.
Comportamiento del programador y los reintentos
El programador de WordPress no inicia Node.js por sí mismo. Ejecute publisher-exporter queue-runner desde cron, un temporizador de systemd, el Programador de tareas de Windows o CI. Se recomienda ejecutar el proceso cada minuto; el intervalo propio de la regla controla la frecuencia con la que se evalúa la demanda.
El ejecutor procesa un intervalo cerrado del diario. Los cambios nuevos que lleguen durante la ejecución se convierten en trabajo pendiente para un trabajo posterior. Las demandas equivalentes se agrupan y los fallos aplican una espera progresiva limitada entre reintentos, conservando el punto de control. El cursor confirmado solo avanza después de que la implementación, la invalidación de CloudFront y la verificación final se completen correctamente.
Si abandona un reintento desde la pantalla Trabajos, Static Publisher borra su plan y punto de control locales, pero no confirma el intervalo del diario. Por tanto, una ejecución posterior del programador puede crear un trabajo nuevo para el mismo trabajo pendiente.
Actualizaciones y eliminaciones seguras
Para contenido publicado, el ejecutor renderiza la URL pública nueva y las superficies de navegación afectadas. Para retiradas de publicación, envíos a la papelera, eliminaciones o cambios de enlace permanente, usa la última URL pública exacta registrada antes de la transición. Los alias de la papelera de WordPress que terminan en __trashed se rechazan como destinos de eliminación.
La eliminación remota pertenece al manifiesto: la sincronización de contenido solo puede marcar para eliminación una ruta de salida que ya figure en el manifiesto de rastreo de confianza. Nunca enumera todo el prefijo de S3 para adivinar qué debe eliminarse, por lo que conserva los objetos no relacionados o que solo existen en remoto. La limpieza general de recursos sigue siendo responsabilidad de una conciliación completa o incremental normal.
WordPress multisitio
Include multisite subsites está desactivado de forma predeterminada. Mientras esté desactivado, la regla solo sigue el sitio propietario del entorno de ejecución de Static Publisher.
Actívelo únicamente cuando:
- WordPress se ejecute como una red multisitio,
- SmartCloud Static Publisher esté activado para toda la red,
- los subsitios incluidos usen el mismo origen con URL basadas en rutas y compartan el espacio de nombres de salida estática configurado.
Al activarlo, se siguen los tipos de contenido coincidentes en toda la red y cada evento recibe la identidad de su sitio. También cambia el alcance de la regla, por lo que después debe ejecutar una nueva publicación normal. Los subsitios alojados de forma independiente o con asignación de dominio necesitan destinos de Publisher separados; no se tratan silenciosamente como rutas del sitio principal.
Comprobaciones operativas
La pantalla Ajustes del programador muestra las secuencias observada y confirmada, el retraso, la disponibilidad de la línea base, el trabajo pendiente, los intentos de reintento y la operación más reciente. En una ejecución completada correctamente, las secuencias observada y confirmada coinciden, el retraso es cero, la línea base está lista y no queda activo ningún trabajo ni punto de control de sincronización de contenido.