WP Manifestindependent plugin directory
manifest / multisite / vigilante-network-sync

Vigilante Network Sync releasesself-updates

Capa de red para WordPress multisite que replica la configuración de Vigilante desde el sitio principal al resto y unifica el login (opcional). Complementa Vigilante; no lo modifica.

by Albert Calzada (communikt) · github.com/communikt/vigilante-network-sync · website

0stars
42release downloads
≈10active sites
0forks

Install

The author publishes release zips, so WP-CLI can install straight from GitHub:

wp plugin install https://github.com/communikt/vigilante-network-sync/releases/download/v2.0.7/vigilante-network-sync.zip

Ships its own WordPress updater (Plugin Update Checker), so new versions show up under Dashboard → Updates.

Readme

Vigilante Network Sync

Capa de red para WordPress multisite que complementa el plugin de seguridad Vigilante (de Fernando Tellado). Vigilante guarda su configuración por sitio y no tiene panel de red; este plugin añade esa capa que le falta:

  • Replica la configuración de Vigilante (vigilante_options) desde el sitio principal al resto de sitios de la red, bajo demanda y con registro de resultado por sitio.
  • Permite elegir el sitio principal (por defecto el principal de la red, normalmente el ID 1, pero configurable por si los IDs cambian).
  • Ofrece, como opción, un login unificado por bloqueo: el login solo se hace en el sitio principal y los subsitios responden 404 a cualquier intento de acceso (wp-login.php y slug) sin revelar el slug secreto, para que el 2FA se configure una sola vez (la cookie de auth de red da acceso al resto).
  • No hace nada si Vigilante no está activo y está diseñado para no romper el acceso (diseño fail-open).

Este plugin no modifica Vigilante: solo lee y escribe su opción de configuración.

Requisitos

  • WordPress multisite (obligatorio).
  • WordPress 6.2+ y PHP 7.4+.
  • Plugin Vigilante activo en la red.

Instalación

  1. Copia la carpeta vigilante-network-sync/ en wp-content/plugins/.
  2. En Network Admin → Plugins, activa el plugin en red (Network Activate).
  3. Ve a Network Admin → Configuración → Vigilante Sync.

Para montar una red desde cero (Vigilante incluido) en el orden correcto y con las verificaciones que evitan quedarse fuera, sigue la guía paso a paso docs/INSTALACION-MULTISITE.md del repositorio.

Uso

  1. Sitio principal: elige el sitio del que se copiará la configuración (por defecto el principal de la red).
  2. Sincronización: pulsa «Sincronitza ara». Verás una tabla con el resultado por sitio (correcto / sin cambios / error).
  3. Login unificado (opcional): activa «Bloquejar el login als subsites». Solo es posible en redes de subdirectorio y si el sitio principal tiene configurado el custom-login de Vigilante. Los subsitios responderán 404 a cualquier intento de login (sin revelar el slug); el login real solo funciona en el principal.

Qué NO se copia a los subsitios

1. Ajustes de fichero compartido (con Vigilante 2.9.8 o superior). wp-config.php y el .htaccess de la raíz son ficheros únicos de toda la red y desde 2.9.8 solo los escribe el sitio principal; los subsitios ven esas secciones en modo solo lectura, mostrando los valores del principal. Copiarlas no tendría efecto, así que el sync las preserva del destino:

  • toda la sección security_headers,
  • la parte de wp_hardening que escribe constantes (disallow_file_edit, force_ssl_admin, wp_debug…),
  • la mitad .htaccess de firewall (protect_wp_config, limit_http_methods, disable_directory_browsing…).

La lista se lee de Vigilante (Vigilante_Settings::get_shared_file_settings()), no está duplicada aquí. Con versiones anteriores a 2.9.8 el comportamiento es el de siempre.

2. Campos propios de cada sitio:

  • Listas de IPs y de User-Agents (firewall.ip_whitelist/ip_blacklist/ua_whitelist/ua_blacklist, login_security.ip_whitelist, activity_log.excluded_ips) — marca la casilla para copiarlas. Al copiarlas, las entradas de IP que nunca podrían coincidir (999.999.999.999/99, una palabra suelta…) se descartan con el mismo validador que usa Vigilante 2.9.9 al guardar, y se nombran en el log del sync. Las de User-Agent no se tocan.
  • Configuración de 2FA (login_security.two_factor) — los secretos TOTP son por sitio; marca la casilla para copiarla solo si el método es e-mail.
  • email.additional_recipients — quién recibe los avisos de un sitio es decisión de ese sitio.
  • security_headers.csp.report_uri (URL absoluta por sitio) — siempre se preserva.
  • Cualquier campo que Vigilante declare en get_user_data_keys() y que este plugin no conozca: se preserva por defecto, para que una versión futura de Vigilante no nos pille copiando campos nuevos sin criterio.

Excepciones que sí se propagan aunque Vigilante las trate como datos del usuario, porque en una red en subdirectorio son uniformes por definición: firewall.trusted_proxy_header, user_security.insecure_usernames y las exclusiones de file_integrity (el escaneo recorre el mismo sistema de ficheros en todos los sitios).

En multisite los IDs de usuario son globales, así que las exclusiones por usuario y los roles sí se replican correctamente.

Recomendaciones de configuración

  • Modo bloqueo (recomendado para 2FA único, red multi-idioma): configura el custom-login en el sitio principal, mantén el slug copiado a los subsitios (sync) y activa el bloqueo de login. El login solo funciona en el principal; los subsitios responden 404 sin revelar el slug. El 2FA se configura una sola vez y la cookie de red cubre el resto. Requiere multisite en subdirectorio (cookie de auth compartida).
  • Modo independiente: mismo slug en todos los sitios (vía sync) y bloqueo desactivado. Cada sitio oculta su propio login; el 2FA se configura por sitio (las tablas TOTP de Vigilante son por sitio; no marques copiar la config de 2FA con TOTP).
  • .htaccess / wp-config.php son únicos y compartidos en la red: configúralos desde el sitio principal. Con Vigilante 2.9.8 o superior esto ya no es solo una recomendación — el propio Vigilante rechaza esas escrituras desde cualquier otro sitio— y el sync replica al resto únicamente la configuración de PHP-runtime.

Resiliencia y recuperación

  • Diseño fail-open: ni el sync ni el bloqueo pueden dejar al admin sin acceso. El sitio principal nunca se bloquea. El sync valida el esquema de Vigilante antes de escribir y aborta si no lo reconoce; el bloqueo solo actúa si se cumplen todas las precondiciones.

  • Redes de subdominio: el bloqueo se deshabilita y avisa (is_subdomain_install()), porque la cookie de auth no se comparte y dejaría al admin fuera de los subsitios.

  • Vigilante de versión: si Vigilante cambia de versión, aparece un aviso en Network Admin y se envía un email (una vez por versión) al destinatario configurado.

  • Salvaguarda post-update: tras actualizar este plugin, si el esquema de Vigilante no valida, se desactiva solo el bloqueo automáticamente.

  • Kill-switch de emergencia: define en wp-config.php:

    define( 'VIGSYNC_DISABLE_LOGIN_GUARD', true );

    Esto desactiva el bloqueo sin tocar la base de datos (también se acepta el antiguo VIGSYNC_DISABLE_REDIRECT). Y como es un plugin normal, siempre puedes desactivarlo o borrarlo para recuperar el acceso.

  • Guía completa de recuperación (kill-switch → WP-CLI → FTP): docs/RECUPERACION-EMERGENCIA.md del repositorio.

Actualizaciones automáticas (GitHub + Plugin Update Checker)

Este plugin se distribuye fuera de wordpress.org. Usa la librería Plugin Update Checker (PUC) apuntando a GitHub Releases del repositorio público communikt/vigilante-network-sync.

  • La librería se incluye en lib/plugin-update-checker/. Si no está presente, el plugin funciona igual pero sin auto-update.
  • Cada instalación detecta las nuevas versiones y muestra la actualización con la UI nativa de WordPress (incluido el toggle de auto-update por plugin).

Política de actualización (recomendada)

Por defecto solo notificación (no auto-update silencioso), porque este plugin afecta al login. Cada web puede optar al auto-update. Se recomienda un flujo canary:

  1. Publicar la nueva Release en GitHub (subiendo Version: y, si procede, Vigilante compat: en la cabecera del plugin).
  2. Actualizar primero en un sitio de pruebas (canary) y verificar que el login sigue funcionando.
  3. Propagar al resto.

Flujo de mantenimiento

Cuando salga una versión nueva de Vigilante: revisar que el esquema de vigilante_options sigue siendo compatible, actualizar la cabecera Vigilante compat:, subir Version: y publicar una Release/tag en GitHub. PUC se encarga de distribuirla.

Estructura

vigilante-network-sync/
  vigilante-network-sync.php           Bootstrap, constantes, hooks, updater
  uninstall.php                        Limpieza de la opción de red
  includes/
    class-vigsync-settings.php         Opción de red + defaults
    class-vigsync-detector.php         Detección/lectura de Vigilante, validación, versión
    class-vigsync-sync.php             Motor de sincronización + log
    class-vigsync-login-guard.php      Bloqueo de login en subsitios (fail-open)
    class-vigsync-network-admin.php    Página de red, formularios, avisos
    views/network-settings-page.php    Plantilla de la página
  assets/css/admin.css
  lib/plugin-update-checker/           Librería PUC (vendorizada)
  languages/                           .pot + traducciones ca/es/en (.po/.mo)
  README.md                            Esta documentación
  CHANGELOG.md                         Historial de versiones

Historial de cambios

Consulta CHANGELOG.md. Sigue Keep a Changelog + SemVer.

Licencia

GPL v2 o posterior.

Read the full README on GitHub →

Releases

TagPublishedAssetDownloads
v2.0.7 Sep 9, 2026 vigilante-network-sync.zip 6
v2.0.6 Aug 29, 2026 vigilante-network-sync.zip 9
v2.0.5 Aug 26, 2026 vigilante-network-sync.zip 6
v2.0.4 Aug 23, 2026 vigilante-network-sync.zip 6
v2.0.3 Aug 20, 2026 vigilante-network-sync.zip 7
v2.0.2 Aug 14, 2026 vigilante-network-sync.zip 4
v2.0.1 Jul 4, 2026 vigilante-network-sync.zip 2
v2.0.0 Jun 28, 2026 vigilante-network-sync.zip 1
v1.0.1 Jun 23, 2026 vigilante-network-sync.zip 1
v1.0.0 Jun 23, 2026 vigilante-network-sync.zip 0

Active-site estimate ≈10 comes from the v2.0.6 cohort. Method.