Menos es más: limpiar y resolver conflictos

Módulo 5: Temas y plugins · Tiempo de lectura: 9 minutos

Objetivo de aprendizaje: Tras esta lección, usted podrá limpiar sus plugins y localizar y resolver por su cuenta un conflicto o una pantalla en blanco.

Conceptos clave: desactivar frente a borrar, código inactivo, error crítico, modo de recuperación (recovery mode), Salud del sitio, modo de resolución de problemas, renombrar la carpeta de un plugin, WP_DEBUG, WP_DEBUG_LOG, debug.log, registro de errores

Desactivar no es tirar

En Plugins puede desactivar o borrar un plugin. La diferencia:

• Desactivar: WordPress deja de cargar el plugin. Pero los archivos siguen en wp-content/plugins/ y a menudo todavía se pueden solicitar directamente a través del servidor web. Si hay una vulnerabilidad en un archivo PHP suelto de ese plugin, esa vulnerabilidad sigue existiendo. Los atacantes buscan archivos vulnerables conocidos, no plugins activos.
• Borrar: los archivos desaparecen. Algunos plugins, al borrarlos, también eliminan sus ajustes y tablas de la base de datos; otros los dejan.

Si ya no utiliza un plugin, bórrelo. Desactivar es solo para un momento (mientras busca un problema). Lo mismo vale para los temas (lección 2.4).

Limpiar: una revisión periódica

Revise sus plugins una vez por trimestre (lección 9.4). Para cada plugin:

1. ¿Para qué sirve? Si ya no lo recuerda, averígüelo. A menudo resulta que un plugin se instaló una vez para algo concreto y nunca se quitó.
2. ¿Se sigue utilizando? Un plugin de sliders cuando no hay ningún slider en el sitio, un plugin de formularios cuando su página de contacto usa otro formulario.
3. ¿Se puede prescindir de él? ¿Lo hace ya WordPress, el tema u otro plugin (lección 5.3)?
4. ¿Sigue teniendo mantenimiento? ¿Cuándo se actualizó por última vez? ¿Sigue en el directorio de plugins?

Haga la limpieza primero en el entorno de pruebas (staging) (lección 8.3), o al menos haga una copia de seguridad, y borre los plugins de uno en uno, para saber qué ha fallado si algo sale mal. Tenga cuidado con los shortcodes: si borra un plugin que proporcionaba [formulier id="2"], ese texto aparecerá después tal cual en su página.

Cuando algo sale mal: el error crítico

Tras una actualización, un plugin nuevo o una actualización de PHP, de repente ve:

Ha habido un error crítico en esta web.

o una página completamente en blanco. Eso significa que PHP se ha detenido con un error fatal antes de generar la página (lección 1.2). Normalmente se debe a un plugin o un tema que no es compatible con otra cosa: otro plugin, la nueva versión de WordPress o la versión de PHP.

Desde WordPress 5.2, WordPress hace entonces dos cosas:

• envía un correo electrónico a la dirección del administrador indicando qué plugin o qué tema ha causado el error, con un enlace especial;
• con ese enlace accede al modo de recuperación (recovery mode): la administración funciona, con el plugin que causó el error desactivado temporalmente, para que pueda actualizarlo, sustituirlo o borrarlo.

Por eso es tan importante tener una dirección de administrador que usted lea de verdad (lección 2.2).

Buscar usted mismo: los pasos

¿No llega ningún correo o no funciona el modo de recuperación? Así lo encuentra usted mismo.

1. Consulte el registro de errores

El error casi siempre aparece en el registro de errores del servidor web o de PHP. En DirectAdmin lo encontrará en los registros de su dominio. Busque una línea con PHP Fatal error y la hora de su intento:

PHP Fatal error:  Uncaught Error: Call to undefined function create_function()
in /home/gebruiker/domains/example.com/public_html/wp-content/plugins/oude-slider/slider.php:42

La ruta le indica quién es el culpable: aquí, el plugin de la carpeta oude-slider. El resto de la línea le dice por qué (aquí: una función que se eliminó en PHP 8, lección 8.4).

2. Active el registro de depuración (no los mensajes en pantalla)

Si el registro de errores no contiene nada útil, añada en wp-config.php (por encima de «¡Eso es todo, deja de editar!»):

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

WordPress escribirá entonces todos los errores en wp-content/debug.log, sin mostrarlos a los visitantes. No lo deje activado más tiempo del necesario: debug.log está en una carpeta que el servidor web sirve, y quien conozca la dirección puede leerlo. Contiene rutas, a veces nombres de usuario y otra información que ayuda a un atacante. Desactívelo de nuevo cuando termine y borre debug.log. O haga que WordPress escriba el archivo de registro fuera de la carpeta web indicando una ruta en WP_DEBUG_LOG (por ejemplo '/home/gebruiker/logs/wp-debug.log', si su proveedor de alojamiento lo permite). En la lección 7.4 comprobará que debug.log no es público.

3. Desactivar un plugin sin acceso a la administración

Si no puede entrar en la administración, desactive el plugin sospechoso renombrando su carpeta, mediante el Administrador de archivos o SFTP:

wp-content/plugins/oude-slider   pasa a   wp-content/plugins/oude-slider-uit

WordPress deja de encontrar el plugin y lo desactiva. Si no sabe cuál es, renombre toda la carpeta plugins a plugins-uit: se desactivan todos los plugins. Si el sitio web funciona entonces, cree una nueva carpeta plugins vacía, vuelva a colocar los plugins uno por uno y compruebe después de cada uno si el error reaparece. Con un tema ocurre lo mismo: renombre la carpeta del tema activo y WordPress recurrirá a un tema predeterminado, si todavía hay uno instalado (lección 2.4).

4. Conflictos sin error fatal

No todos los problemas son un error crítico. A veces falla una sola función: un botón no hace nada, el formulario no se envía, el editor se carga a medias. En ese caso suele tratarse de un conflicto entre dos plugins o entre un plugin y el tema. Para ello resulta útil el plugin oficial Health Check & Troubleshooting: en el modo de resolución de problemas desactiva todos los plugins y cambia a un tema predeterminado solo para su sesión, mientras los visitantes siguen viendo el sitio web normal. Después los va activando uno por uno hasta que el problema reaparezca.

Consulte también la consola de su navegador (F12): los errores de JavaScript suelen indicar el archivo y, con ello, el plugin.

Salud del sitio

En Herramientas > Salud del sitio WordPress revisa su propio sitio web: versión de PHP obsoleta, plugins y temas inactivos, extensiones de PHP que faltan, una REST API que no funciona, tareas programadas con retraso. En la pestaña Información encontrará todos los datos de su instalación (versiones, rutas, ajustes de PHP). Puede copiar esa pestaña y adjuntarla cuando pida ayuda. Échele un vistazo después de cada cambio importante.

Resumen

• Desactivar deja los archivos en su sitio; borre los plugins y temas que no utilice.
• Haga limpieza cada trimestre, un plugin cada vez, con una copia de seguridad o en el entorno de pruebas (staging).
• Ante un error crítico, WordPress envía un correo con un enlace al modo de recuperación.
• El registro de errores o debug.log indica la ruta del culpable; desactive la depuración al terminar, porque si no debug.log queda público.
• Sin acceso a la administración, desactiva un plugin renombrando su carpeta; los conflictos se buscan con el modo de resolución de problemas.

Cuestionario

Ejercicio

Ejercicio A5.4: ¿Su registro de depuración no es público? Introduzca la dirección de su sitio web y demuestre con el código que le da el ejercicio que el sitio es suyo (un registro TXT o un pequeño archivo). El programa solicita /wp-content/debug.log: el resultado es correcto si no existe o se deniega el acceso (404 o 403). Si el programa recibe un archivo, el resultado es rojo. Además, el programa cuenta cuántas carpetas de plugins distintas aparecen en el HTML de su página de inicio (solo a título informativo).

Ejercicio D5.4: Poner orden en su lista de plugins. Haga una lista de todos sus plugins (activos e inactivos): nombre, para qué sirve, si sigue siendo necesario (sí/no) y alternativa sin plugin. Borre (después de una copia de seguridad o en el entorno de pruebas (staging)) los plugins que ya no necesite, de uno en uno, y compruebe después de cada borrado si el sitio web sigue funcionando. Indique cuántos plugins tenía y cuántos quedan, y anote si quedaron shortcodes que tuvo que limpiar.

Más información

Estos artículos describen los pasos en los paneles de WebOké; en otros paneles funcionan de forma similar.

• Manual de DirectAdmin 18.1: Mi web aparece en blanco o da un error 500
• Error 500 o «error crítico» en su sitio web (también tras una actualización de WordPress)
• Manual de DirectAdmin 14.6: Errores tras una actualización de PHP y cómo encontrar el registro de errores
• Manual de DirectAdmin 17.2: Resumen del sitio y registros: el registro de errores y el registro de accesos
• ¿Cómo puedo depurar PHP sin modificar php.ini?
• Depuración en WordPress (developer.wordpress.org, en inglés): https://developer.wordpress.org/advanced-administration/debug/debug-wordpress/
• Cómo elegir, evaluar y depurar plugins de WordPress