WordPress 5.1 que, si no pasa nada, será publicado el próximo día 21 de febrero (2019), incluirá una nueva función para proteger el acceso al panel de administración de errores generados por los plugins: los plugins en pausa.

Por supuesto, ya he estado probando el asunto (llevo casi tres semanas trabajando con WordPress 5.1) así que voy a repasar esta nueva funcionalidad y ver qué tal funciona y cómo de útil puede llegar a ser.

Uno o más plugins no han cargado correctamente

¡Hala! ¿Pero qué narices es esto? Sí, algo así se me escapó la primera vez que lo vi. Es habitual, mientras estás programando un plugin, ir haciendo recargas de página y comprobando funcionalidades mientras vas escribiendo código. Y claro, de vez en cuando pasa: un punto y coma faltante, un objeto WP_Error que no ha sido comprobado y filtrado… mil cosas que pueden hacen que un plugin genere un error crítico de PHP.

Hasta ahora, cuando pasaba eso, PHP cesaba la ejecución, mostraba el mensaje (muy drámatico) de error fatal, y listos. En una web en producción, con el modo DEBUG desactivado, el comportamiento es ligeramente distinto: una «pantalla blanca de la muerte».

Los plugins en pausa

Sin embargo desde WordPress 5.1 la cosa cambia. Ahora, gracias a la nueva funcionalidad que han llamado Site Health Check, WordPress interrumpe la ejecución del plugin antes de que el error PHP «explote». En pocas palabras, WordPress pone el plugin en cuarentena y lo mantiene activado pero sin ejecutar para proteger el funcionamiento de la instalación.

Para eso WordPress introduce un nuevo estado de los plugins, En pausa: el plugin está activado, pero se impide su ejecución hasta que manualmente ésta se reanude mediante la acción Reactivar.

Y ¿qué pasa si soy lo suficientemente obstinado inconsciente como para reactivar el plugin sin haber comprobado y corregido la causa del error? Bueno, pues aún así sigo protegido porque WordPress se negará a reactivarlo alegando que lanza un error fatal.

Ventajas y desventajas del Site Health Check

A ver, que esto puede estar muy guay, pero en realidad no lo está tanto: creo que lo ideal (mirando desde el lado del usuario, que en este caso es el administrador de la web) que el plugin se ponga en pausa, se anule la ejecución de su código, y mientras no se reactive el resto de la web siga funcionando con normalidad.

Pero no, el Site Health Check se queda a medio, ya que en el frontend (la «cara» pública de la web) también desaparece todo, se muestra un mensaje informando de que el sitio está experimentando dificultades técnicas, y se insta al administrador a acudir al panel de administración para resolver el entuerto.

Posibilidad de acceder al panel de administración

Pero bueno, ahí está la gran diferencia: aún puedes entrar al panel de administración y desactivar el plugin, o hacer lo que tengas que hacer.

Y es que, hasta ahora, la única posibilidad cuando pasaba algo así era acceder mediante FTP (o a través del gestor de archivos de tu hosting) y eliminar o renombrar el directorio del plugin… si sabías cuál era el que estaba causando el error. Si no sabías cuál era, tocaba renombrar el directorio completo de plugins para anularlos todos.

Sin duda un avance importante en este sentido.