Monitoreando múltiples instalaciones WordPress con WP_Monitor

Gestionar o supervisar un número importante de webs basadas en WordPress, a menos de que dispongamos de algún sistema para monitorearlas, a menudo se vuelve pesado y no siempre sencillo hacerles el seguimiento. Esto muchas veces se traduce en dejar una instalación desactualizada por días o, incluso peor, con vulnerabilidades graves en alguno de los plugins o temas instalados, lo que la dejará expuesta a problemas de seguridad.

En este artículo no solo exploraremos la herramienta WP-Monitor, sino que además trataremos otros conceptos generales acerca de la automatización de tareas, la seguridad y la creación de herramientas personalizadas que solucionen necesidades específicas.

Un caso habitual y la necesidad de una mejor respuesta

Si te has paseado por los logs de una instalación WordPress, habrás comprobado la cantidad de intentos de acceso no autorizados y ataques que reciben. La cosa se pone divertida el día (casi cada día) que lees la noticia de que tal o cual plugin ampliamente utilizado tiene una nueva vulnerabilidad crítica y sabes que en algún dominio se está usando. Este día puedes ver en los logs cuán rápidamente esa noticia se transforma en ataques e intentos de intrusión en las instalaciones de WordPress, lo que destaca la importancia de poder responder con rapidez.

WP-Toolkit al rescate

La llegada de WP-Toolkit para cPanel y Plesk ha mejorado significativamente el proceso de despliegue y seguimiento de las distintas instalaciones de WordPress en un servidor. Además de otras funcionalidades más enfocadas en la instalación, WP-Toolkit te proporciona información detallada de todas las instalaciones de WordPress corriendo en un servidor. Te muestra los plugins y temas instalados, sus versiones, actualizaciones pendientes y posibles problemas de seguridad. También permite configurar avisos automatizados por correo electrónico (esto último con ayuda del panel de control) y configurar actualizaciones automáticas según tus preferencias, entre otras funciones.

Aunque el asunto de las actualizaciones automáticas justificaría otro artículo, no podemos dejar de mencionar que tanto Plesk como cPanel permiten configurar WP-Toolkit para que se realicen actualizaciones automáticas de WordPress, Plugins y Themes. Incluso el propio WordPress ya incluye desde la versión 3.7 esta opción, la cual permite automatizar las actualizaciones menores y de seguridad del propio framework, aunque como es sabido y dependiendo de cada sitio web no siempre es aconsejable que se realicen actualizaciones automáticas ya que a menudo se pueden romper cosas, pero esto, como decimos, justificaría una entrada aparte.

El problema de WP-Toolkit

Como hemos mencionado, WP-Toolkit depende de cPanel o Plesk, lo que significa que toda su funcionalidad está condicionada a tener una sesión abierta en uno de estos paneles, y en la mayoría de los casos, en el panel de administrador. En muchos casos, esto representa una limitación. Estemos donde estemos y sin importar el dispositivo que tengamos a nuestro alcance, necesitaremos abrir una sesión de administrador para monitorear las diferentes instalaciones y llevar a cabo tareas específicas.

Además, aunque los avisos por correo electrónico son útiles, también requieren interactuar con el programa de correo para luego decidir qué hacer. Los sistemas de correos automatizados enviados a los clientes pueden mejorarse y, en algunos casos, sería preferible que el mensaje enviado fuera más personalizado, dependiendo de la anomalía detectada en el sitio web. Algunos clientes instalan plugins sin saber realmente lo que están añadiendo a su servidor, y cuando lo detectas, deberías poder informarles con solo pulsar un botón.

Abrir el panel, dirigirse a WP-Toolkit, revisar, actuar o no… Y si pudieramos tener a WP-Toolkit fuera del panel de control, de forma directa, con datos actualizados y con la menor demora posible?

WP_Monitor: Una prueba de concepto

WP_Monitor comenzó como un pequeño desafío, una «prueba de concepto» para satisfacer las necesidades mencionadas. Sin embargo, este proyecto ha evolucionado hasta convertirse en una herramienta de código abierto que usamos a diario. WP_Monitor permite el monitoreo centralizado de múltiples instalaciones de WordPress desde una interfaz unificada, ofreciendo una visión rápida y detallada del estado de cada sitio, además de la capacidad para realizar diversas tareas de mantenimiento y gestión.

WP_Monitor funciona básicamente mediante tres secciones operativas:

1. La obtención automática de datos actualizados

• Un script bash que se ejecuta a través de cron jobs y que recava la información necesaria mediante una combinación de comandos propios de cPanel o Plesk. En esencia estos comandos terminan ejecutando WP-CLI, la interfaz de comandos de WordPress y con la que interactua WP-Toolkit para facilitarnos las cosas.

2. La visualización y gestión de datos

• Una interfaz web (PHP8) con la que visualizaremos la información e interactuaremos con ella.

3. La ejecución de tareas (JOBS) sobre las diferentes instalaciones WordPress

• Un servicio que inspeccionará una cola de trabajos para realizar aquellas operaciones que hayamos enviado a la cola.

Instalación y puesta en marcha

IMPORTANTE: Antes de poner en marcha WP Monitor debes asegurarte de que tu servidor cumple con los requisitos necesarios. Además, sea cual sea el método de instalación que uses debes asegurarte de que tanto las rutas como los permisos son los correctos, de otro modo te encontrarás con problemas cuando despliegues la interfaz web (el archivo install.sh te ayuda a verificar la instalación, más detalles en Instalación automática).

Otra cosa importante que debes tener en cuenta es que a fecha de hoy solo hemos podido correr la aplicación en un servidor con Plesk y, aunque el CRON para cPanel se ha programado siguiendo la documentación oficial de cPanel en cuanto a rutas, permisos y comandos, no lo hemos podido poner a prueba, por lo que si eres usuario de cPanel y te animas a instalar WP Monitor, puedes darnos tu feedback tanto aquí en el blog como en la pagina del respositorio en Github: WP Monitor. Nos será de gran ayuda!

Requisitos previos

• Servidor Web:
  • Apache o Nginx funcionando correctamente
    • Se asume que dispones de un dominio o subdominio de trabajo desde el que ejecutarás la herramienta
    • El dominio debe estar protegido con certificado SSL
    • La variable de entorno WP_PATH debe estar definida
• PHP:
  • PHP 8.0 o superior, con las siguientes extensiones habilitadas:
    • Si usas el envío de correo deberás tener activo o curl o allow_url_fopen
    • json
    • mbstring
    • Phar
• Sistema Operativo:
  • Linux (cualquier distribución compatible con los requisitos anteriores)
• Librerías Linux:
  • jq (Procesador JSON de línea de comandos)
• WP-Toolkit:
  • Instalado y configurado en el servidor mediante Plesk o cPanel
• Acceso SSH:
  • Acceso SSH al servidor
• Permisos:
  • Asegúrate de tener permisos suficientes para crear y modificar archivos en el servidor

Estructura de los archivos y directorios

Lo primero que haremos es clonar el repositorio WP_Monitor en el servidor donde queramos ejecutarlo. Para este ejemplo se utilizará el directorio /opt de nuestro servidor Linux. El directorio /opt es el que usa la aplicación por defecto, aunque puedes cambiarlo por otro de tu preferencia.

// Entrar en la carpeta donde isntalaremos WP Monitor

cd /opt

// Clonar el respoistorio de Github
git clone https://github.com/Parkteknia/wp_monitor


// Entrar la carpeta

cd wp_monitor/

En la carpeta wp_monitor encontraremos lo siguiente:

• Archivo install.sh: Un instalador automático de la aplicación que también permite realizar un test previo (Ver Instalación automática)
• Archivo config.json: Contiene las variables de configuración de WP_Monitor.
• Archivo jobs: Contendrá las tareas que iniciemos para cada una de las instalaciones de WordPress.
• Archivo jobs_executed: Contendrá un log con las tareas que se hayan ejecutado.
• Directorio wpm_bash/: Contiene los scripts bash necesarios tanto para la recolección de datos mediante WP-Toolkit (CRON), como para la ejecución de tareas (JOBS):
  • Directorio cpanel/: Contiene el archivo bash recolector (CRON) «wpm_cron_cpanel.sh» escrito para cPanel.
  • Directorio plesk/: Contiene el archivo bash recolector (CRON) «wpm_cron_plesk.sh» escrito para Plesk.
  • Archivo wpm_jobs.sh: Ejecutará las tareas (JOBS) que iniciemos.
  • Archivo wpm_process_jobs.service: Un servicio systemd que monitoreará las tareas (JOBS) pendientes.
• Directorio wpm_data/: Contendrá la información recabada para cada uno de los dominios. En la raíz se guardarán archivos «id-code.json» donde el ID será el id de la instalación WordPress y CODE un código único que identificara cada instalación en la interfaz web..
  • Direcotorio logs/: Se guardará una copia comprimida del archivo «dominio.error_logs.tar.gz» de cada instalación y también, en caso de que se haya configurado el envío de correo, un archivo id-email.log para los correos electrónicos que enviemos a cada propietario de su respectiva instalación WordPress.
  • Directorio tmp/: Se descomprimirán temporalmente los archivos dominio.error_logs.tar.gz.
    • En el directorio tmp/ también se escribirá el archivo «wp_monitor.lock», que nos servirá para bloquear la escritura en wpm_jobs.sh e impedir que se ejecute hasta que haya terminado la anterior ejecución.
• Directorio wpm_www: Contiene los archivos de la interfaz web con la que interactuaremos.
  • Directorio assets/: Contiene tanto el javascript y css de la interfaz, como una copia de Bootstrap 5.3
    • Directorio bootstrap-5.3.3/: Contiene una instalación limpia de Bootstrap 5.3 (se omite describir el contenido, puedes usar tu propia instalación pero recuerda revisar los paths).
    • Archivo wpm.js: La lógica javascript de la interfaz web.
    • Archivo wpm.css: Algunas reglas css para la interfaz.
  • Directorio locales/: Contiene la tradución es_ES para la interfaz y mensajes de la aplicación.
  • Archivo index.php: El archivo índice para ejecutar WP_Monitor.
  • Archivo WPMonitor.php: La clase PHP con la lógica principal de la aplicación.
  • Archivo WPMonitorAPI.php: Lógica que gestionará las llamadas de la interfaz.
  • Archivo WPMonitorFunctions.php: Funciones adicionales.

Instalación automática

// Ejecutanto de este modo se realiza un test de instalación
sudo bash install.sh

WP Monitor incluye un modo de instalación «automática» a través de la ejecución de install.sh. Por defecto, si se ejecuta sin pasarle ningún argumento, hará una instalación en modo «información«. Este modo es recomendable antes de realizar la instalación final, ya que nos permitirá comprobar que nuestro servidor cumple con los requesitos para poder ejecutar WP_Monitor. Ejecutando install.sh sin parámetros, no realiza ningún cambio en el servidor.

Una vez nos hemos asegurado de que no hay errores a la hora de ejecutar install.sh, podremos ejecutar:

sudo bash install.sh no-check

Esto realizará exactamente lo mismo que se visualiza en la imagen anterior, pero ejecutando cada una de las acciones para dejar WP_Monitor configurado.

Ahora ya puedes visitar la url donde lo instalaste para visualizar la interfaz web.

Instalación manual

NOTA: Aunque decidas instalar de forma manual, una ejecución de install.sh sin pasarle ningún parámetro te ayudará a visualizar de forma rápida lo que tienes que configurar.

Archivo de configuración

Archivo de configuración con comentarios informativos de cada variable.

Recabar los datos mediante una tarea CRON

Bien, llegados a este punto lo primero que haremos es poner en marcha el script que recabará los datos de nuestras instalaciones WordPress. Hasta que te hayas familiarizado con el funcionamiento del conjunto, te recomendamos que por ahora no cambies nada en los bash ya que están escritos teniendo en cuenta la instalación clásica de cPanel y Plesk. Aunque como comentario decirte que ambos scripts permiten configurarse para que tu puedas usar tus propios paths de trabajo, así como enviar simples notificaciones email cuando se ejecuten los scripts bash.

Para el ejemplo usaremos la ejecución en un entorno Plesk y antes de crear la tarea CRON realizaremos una ejecución manual para comprobar que no existan errores.

cd /opt/wp_monitor/wpm_bash/plesk/
sudo chmod +x wpm_cron_plesk.sh
sudo bash wpm_cron_plesk.sh

Si el comando no da errores es que la ejecución ha sido correcta. Para asegurarte puedes comprobar como en /opt/wp_monitor/wpm_data/ se han guardado los id.json, así como las copias comprimidas de los error_log de cada dominio. También se guarda el archivo wpi.json, el cual incluye un archivo con el conjunto general de todos los datos.

Ahora solo nos queda activar el CRON. Aunque podrías programar la tarea a través de crontab directamente, para este ejemplo de instalación manual, la activaremos mediante la propia interfaz de Plesk (en cPanel es similar). Por ahora ejecutaremos el script cada 5 minutos. A cotinuación tienes una captura de pantalla para visualizar la configuración a la que accedes desde Plesk -> Herramientas y Configuración -> Tareas programadas (tareas cron)

Un servicio para systemd que ejecute las tareas pendientes (JOBS)

Un «service» en Linux, es una unidad que define y gestiona un proceso de fondo (daemon o demonio), y que permite tareas como ejecutar scripts de procesamiento asíncrono, programar tareas futuras o crear un demonio que escuche en un socket, entre otros. La mayoría de distribuciones Linux han adoptado systemd, el supervisor o administrador de servicios en y para el propio sistema Linux, y es para systemd para quien escribiremos nuestro simple servicio, el que permitirá leer nuestra cola de trabajos a ser ejecutados.

Básicamente lo que hará nuestro servicio gestionado por systemd es ejecutar el bash wpm_jobs.sh, el cual se encargará de ejecutar las tareas (JOBS) pendientes. Además, será persistente a reinicios, por lo que siempre estará activo, incluso si hay algún fallo, siempre se volverá a iniciar.

IMPORTANTE: Antes de instalar el servicio debes configurar la variable PANEL en wpm_bash/wpm_jobs.sh e indicar 1 si estás ejecutando en cPanel y 2 si lo haces en Plesk.

A continuación, para instalar el servicio de forma manual deberemos ejecutar los siguientes comandos como root:

// Copiamos el servicio en el sistema
cp wpm_bash/wpm_jobs_service.service /etc/systemd/system/

// Asegúrate de asignar permisos de ejecución a los siguiente archivos
chmod +x wpm_bash/wpm_jobs_service.service 
chmod +x wpm_bash/wpm_jobs.sh

// Ahora puedes activar el servicio así
systemctl start wpm_jobs_service.service
systemctl enable wpm_jobs_service.service

// Ahora, para comprobar que efectivamente el servicio se ha iniciado
systemctl status wpm_jobs_service.service

Si el servicio se ha iniciado correctamente deberías ver algo muy similar a la siguiente imagen:

Levantando la interfaz web y consideraciones sobre su seguridad

Ahora que nuestro CRON y el sevicio JOBS se están ejecutando y mantienen los datos actualizados, podemos pasar a la interfaz web con la que podremos visualizar e interactuar con dicha información.

Para poner en marcha la interfaz web, se han tenido en cuenta tres cuestiones fundamentales para procurar garantizar la protección de los datos y la integridad del sistema:

1. Cifrado de la conexión

El servidor web donde se ejecute la interfaz debe contar con un certificado SSL para que la conexión sea cifrada mediante el protocolo HTTPS. Esto garantiza que los datos transmitidos entre el cliente y el servidor estén protegidos contra interceptaciones y ciertos ataques man-in-the-middle.

2. Almacenamiento de datos fuera del directorio web

Los datos recopilados mediante scripts bash (CRON) se almacenan en un directorio separado fuera del directorio web. Esta medida asegura que los datos sensibles no sean accesibles directamente desde la interfaz, reduciendo así el riesgo de exposición ante posibles vulnerabilidades.

Para que la interfaz pueda leer datos en /opt/wp_monitor/wpm_data/, estos directorios deberán tener los permisos adecuados.

Dependiendo de si vas a usar WP_Monitor en cPanel o Plesk, así como dependiendo de la configuración particular que se esté usando, las configuraciones pueden variar, pero en esencia deberás asegurarte de que /opt/wp_monitor/wpm_data/ y su contenido pertenecen al usuario:grupo que ejecutan el servidor web del dominio donde reside WP_Monitor.

// Cambair propietario de forma recursiva wpm_data
sudo chown -R usuario:nobody /opt/wp_monitor/wpm_data/

// Cambair propietario de forma recursiva wpm_data
sudo chown -R usuario:psacln /opt/wp_monitor/wpm_data/

IMPORTANTE: En este punto, el bash (CRON) que se está ejecutando está guardando los datos como pertenecientes a root:root, y lo que queremos es que los guarde con los permisos adecuados, es decir el mismo usuario:grupo que has determinado en el punto anterior. Para ello deberás modificar la siguiente variable en tu archivo bash.

// Tanto en /opt/wp_monitor/wpm_bash/plesk/wpm_cron_plesk.sh
// como en /opt/wp_monitor/wpm_bash/cpanel/wpm_cron_cpanel.sh
// según el Panel de Control que tengas instalado.
USER_GROUP="usuario:grupo"

3. Protección de la interfaz web mediante autenticación básica y Fail2Ban

Para restringir el acceso a la interfaz web, se ha implementado autenticación básica HTTP. Esto garantiza que solo los usuarios con credenciales válidas puedan acceder a la interfaz, proporcionando una capa adicional de seguridad contra accesos no autorizados. Tanto cPanel como Plesk tienen la opción para configurar un directorio protegido con usuario y contraseña. Hacerlo mediante el propio cPanel o Plesk te ahorrará trabajo ya que detectará nuestra configuración y creará los archivos y cambios necesarios para proteger dicho directorio, por el contrario si prefieres configuararlo manualmente puedes configurarlo así:

// Substituye la ruta por la ruta a tu nombre de dominio
cd /var/www/dominio.com/wp_monitor/

// Ahora crea el archivo .htpasswd con el siguiente comando. Escribe una contraseña robusta.
htpasswd -c .htpasswd usuario_admin

// El archivo quedará así:
cat .htpasswd
-> usuario_admin:$apr1$bkS4zPQl$SyGLA9oP75L5uM5GHpe9A2

// Estas credenciales que has configurado en .htpasswd son las que deberás introducir para entrar en el área protegida. Ahora el .htaccess en el mismo directorio: 
nano .htaccess

// Y pegamos lo siguiente:

// Directorio protegido
AuthType Basic
AuthName "Acceso restringido"
AuthUserFile /var/www/dominio.com/wp_monitor/.htpasswd
Require user usuario_admin

server {
    listen 443;
    listen [::]:443;

    root /var/www/dominio.com/wp_monitor/;
    index index.php index.html index.htm index.nginx-debian.html;
    
    auth_basic "Acceso restringido";
    auth_basic_user_file /var/www/dominio.com/wp_monitor/.htpasswd;
    server_name dominio.com www.dominio.com;

    location / {
        try_files $uri $uri/ =404;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;

        fastcgi_pass unix:/run/php/php8.3-fpm.sock;

        fastcgi_param WPM_PATH /opt/wp_monitor;
    }

    location ~ /\.ht {
        deny all;
    }
    
    location /api {
        
        rewrite ^/api(\?.*)?$ /WPMonitorAPI.php last;
    }
}

Si las configuraciones realizadas en este punto han sido correctas, cuando visites https://www.dominio.com o https://www.dominio.com/wp_monitor/, dependiendo de si pondrás los archivos en la raíz del dominio o en un subdirectorio, deberá aparecerte una ventana para que introduzcas las credenciales de acceso que configuraste.

IMPORTANTE: Existen diferentes ataques de autenticación HTTP que pueden llevarse a cabo para intentar explotar el mecanismo de autenticación, por eso, además de asegurarnos que la conexión es mediante HTTPS, no solo es muy importante que la contraseña que usemos sea robusta, sino que además debemos contar con algún mecanismo que pueda bloquear aquellas direcciones IP cuyas autenticaciones fallidas superen un número determinado de fallos. Esto último lo podemos lograr de diferentes modos, aunque aquí hablaremos muy brevemente de una herramienta llamada Fail2Ban.

En esencia y por no hacerlo muy largo, Fail2Ban es una herramienta de seguridad que protege de diversos tipos de ataques automatizados y de fuerza bruta, mediante la detección de patrones sospechosos de actividad maliciosa y el posterior bloqueo de las IPs asociadas a dicha actividad. Fail2ban utiliza patrones definidos en filters y jails para identificar y bloquear estas actividades dirigidas contra los servicios que corremos en nuestro servidor. A continuación ponemos un ejemplo de filter y jail que bloquearía una IP que introdujera tres veces credenciales erróneas en un servidor Apache con NGINX haciendo de proxy inverso.

En el log del sistema podríamos apreciar una o varias líneas como esta:

2024/06/23 21:58:18 [error] 1416278#0: *18113 user "fake_user": password mismatch, client: 104.192.3.74, server: www.dominio.com, request: "GET / HTTP/2.0", host: "www.dominio.com"

Luego tendríamos un filtro, por ejemplo en el archivo /etc/fail2ban/filter.d/nginx-auth.conf con las siguiente expresiones regulares:

[Definition]
failregex = ^ \[error\] \d+#\d+: \*\d+ user "\S+":? (password mismatch|was not found in ".*"), client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$
            ^ \[error\] \d+#\d+: \*\d+ no user/password was provided for basic authentication, client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$

ignoreregex =

Para finalizar podríamos crear el jail para este filtro por ejemplo en el archivo /etc/fail2ban/jail.local, añadiendo al final del mismo:

[nginx-http-auth]
enabled = true
filter = nginx-auth
action = iptables-multiport[name=nginx-auth, port="http,https"]
logpath = /var/www/dominio.com/logs/proxy_error_log
        /var/log/nginx/error.log
bantime = 604800
maxretry = 3

Hecho esto solo nos quedaría reinciar el servicio fail2ban por ejemplo con sudo systemctl restart fail2ban.service y nuestro jail empezaría a actuar. Esto es una visión general de como funciona Fail2Ban, por lo que te recomendamos que profundices en la herramienta a través de la ámplia información que hay disponible en Internet. Aquí te enlazamos su pagina principal así como su Wiki en Github.

Configuraciones finales de la interfaz web

Además de lo visto hasta ahora, quedan dos últimas configuraciones para que la interfaz web funcione correctamente:

Variable de entorno WPM_PATH

Actualización: En la versión 1.0.2 Se ha añadido un archivo .env en la raíz de la interfaz web por si algún usuario tiene problemas para establecer la variable del lado del servidor. Puedes leer el tema en el commit #19, y por defecto se crea el .htaccess para la reescritura de la url a la /api.

Para que en la aplicación web no tengamos que escribir el path donde residirá el directorio principal así como los datos, creamos una variable de entorno WPM_PATH que apunte, en este caso, a /opt/wp_monitor. Esta variable debe cambiarse en el caso de que queramos poner nuestros datos en una hubicación diferente. Si te fijas, en la configuración NGINX de más arriba ya se incluye dicha variable en la línea fastcgi_param WPM_PATH /opt/wp_monitor, aunque también puede definirse mediante env WPM_PATH=/opt/wp_monitor;. En el caso de Apache podrías definir esta variable en un archivo .htaccess en la raíz del propio directorio web de la interfaz, lo recomendable es definirla del lado del servidor en el archivo de configuración correspondiente a tu dominio, por ejemplo en el caso de Plesk podríamos modificar /var/www/vhosts/system/dominio.com/conf/vhost_ssl.conf y añadir la directiva SetEnv WPM_PATH «/opt/wp_monitor» o en el caso de un servidor con cPanel la ruta podría ser /etc/apache2/conf.d/userdata/ssl/2_4/user/domain/includename.conf, y definiríamos la variable de la misma forma que en Plesk, SetEnv WPM_PATH «/opt/wp_monitor». Hay diferentes métodos para definir estas variables, incluso desde los propios paneles de control.

Reescritura de la URL que apunta a la «API»

La interfaz web realiza diferentes llamadas al archivo WPMonitorAPI.php. Para evitar el uso del nombre del archivo en las URLs de dichas llamadas, creamos una regla de reescritura. Si te fijas en la configuración de NGINX de más arriba, al final de la misma puedes observar como se añadiría la regla de reescritura en el caso de un servidor corriendo NGINX.

location /api {
    rewrite ^/api(\?.*)?$ /WPMonitorAPI.php last;
}

En el caso de Apache, aunque una vez más podemos hacerlo de diferentes modos, una forma simple es añadir en un archivo .htaccess en el directorio raíz de la interfaz la siguiente instrucción:

<IfModule mod_rewrite.c>
    RewriteEngine On
    RewriteRule ^api(.*)?$ /WPMonitorAPI.php [L,QSA]
</IfModule>

Con estas reglas podremos usar una url tipo https://dominio.com/api? desde la interfaz.

Funcionamiento de la interfaz web

Una vez hayamos completado todo el proceso de instalación, si no hay ningún problema, cuando visitemos el https://nombredediminio.com( donde instalamos la interfaz, deberemos ver todas las instalaciones WordPress existentes en el servidor, tal como se aprecia en la siguiente imagen.

Explicación de los distintos colores y datos en la tabla

• Cuando una línea está toda blanca significa que la instalación está actualizada, tanto la versión de WordPress, como sus Plugins y Theme
• Si la línea está blanca pero la columna Plugins está en rojo, significa que la versión de WordPress está actualizada pero alguno de sus Plugins o Theme está desactualizado
• Cuando la línea está de color fucsia, significa que la versión de WordPress está desactualizada
• Cuando la línea está de color amarillo significa que se están ejecutando tareas (JOBS) para esa instalación
• La barra horizontal de color azúl (Progress Bar) se va llenando a medida que avanza el tiempo que hayamos definido para recargar los datos. Recuerdas la variable «app_reload_time» en config.json? Pués este será el intervalo de tiempo que pasará hasta que se vuelvan a solicitar los datos.

A nivel de los datos de la tabla, no creemos que sea necesario explicarlo ya que es bastante evidente y solo apuntar que el número que aparece en la columna Plugins, es el número de Plugins instalados en cada despliegue de WordPress.

Contenido de la ventana modal de cada instalación

Cuando hacemos click en una fila se nos abrira una ventana modal con los siguientes contenidos:

Pestaña WordPress

En la pestaña WordPress solo se muestra un checkbox para activar si queremos actulizar la versión de WordPress

Pestaña Plugins

En la pestaña Plugins podemos definit que Plugins queremos actualizar o desactivar

Pestaña Themes

En la pestaña Themes podemos definir que Theme queremos actualizar

Pestaña SSL

En la pestaña SSL tenemos información sobre nuestro certificado y si WordPress está protegido.

Pestaña Logs

En la pestaña Logs podemos hacer búsquedas o listar los logs de error de nuestra instalación.

Pestaña Email

En la pestaña Email podemos enviar correos electrónicos a los propietarios de las instalaciones WordPress

Bonus: Telegram

En WPMonitor se ha implementado el uso opciónal de Telegram, que de estar configurado correctamente mediante las tres variables de configuración: $telegramToken, $telegramChatId y $telegramEnabled, permite enviar avisos a un bot en Telegram. Dicho bot debe ser creado y configurado previamente por el usuario para obtener tanto el $telegramToken como el $telegramChatId. Las condiciones por las cuales se pueden enviar avisos al bot de telegram no están implementadas y debe ser el usuario el que las implemente según sus necesidades. Si las variables de configuración para el envío a Telegram se han configurado correctmente, al cargarse index.php se ejecuta un envío de prueba:

$wpMonitor->sendMessageToTelegram("WP Monitor iniciado correctamente");