Menos es más: ordenar y resolver conflictos

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

Objetivo de la lección: Después de esta lección sabrá ordenar sus plugins y detectar y resolver usted mismo un conflicto o una página 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

Apagar no es tirar

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

• Desactivar: WordPress deja de cargar el plugin. Pero los archivos siguen estando en wp-content/plugins/ y, a menudo, siguen siendo accesibles directamente a través del servidor web. Si hay una vulnerabilidad en un archivo PHP suelto de ese plugin, esa vulnerabilidad sigue ahí. Los intrusos buscan archivos vulnerables conocidos, no plugins activos.
• Borrar: los archivos desaparecen. Algunos plugins también eliminan al borrarse su configuración y sus tablas de la base de datos; otros las dejan como están.

Si ya no utiliza un plugin, bórrelo. Desactivar es solo algo temporal (mientras busca un problema). Lo mismo se aplica a los temas (lección 2.4).

Ordenar: una ronda fija

Revise sus plugins una vez por trimestre (lección 9.4). Por 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 volvió a quitar.
2. ¿Todavía se utiliza? Un plugin de slider cuando no hay ningún slider en ningún sitio, un plugin de formularios mientras su página de contacto usa otro formulario.
3. ¿Se puede prescindir de él? ¿Ya lo hace WordPress, el tema u otro plugin (lección 5.3)?
4. ¿Sigue teniendo mantenimiento? ¿Última actualización, sigue en el repositorio de plugins?

Haga primero la limpieza en un entorno de pruebas (staging) (lección 8.3), o al menos haga una copia de seguridad, y borre un plugin cada vez para saber qué falló si algo sale mal. Preste atención a los shortcodes: si borra un plugin que generaba [formulario id="2"], ese texto aparecerá literalmente en su página después.

Cuando algo sale mal: el error crítico

Después de una actualización, un nuevo plugin 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. Esto significa que PHP se ha detenido con un error fatal antes de que hubiera una página (lección 1.2). Normalmente se debe a un plugin o 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 a la dirección del administrador indicando qué plugin o tema causó el error, junto con un enlace especial;
• con ese enlace puede iniciar sesión en el modo de recuperación (recovery mode): el escritorio funciona entonces, con el plugin que causó el error desactivado temporalmente, para que pueda actualizarlo, sustituirlo o borrarlo.

Por eso es tan importante que la dirección del administrador sea una que usted realmente lea (lección 2.2).

Buscarlo usted mismo: los pasos

¿No llega el correo o no funciona el modo de recuperación? Así puede encontrarlo 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 encuentra en los registros (logs) 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: en este caso, el plugin en la carpeta oude-slider. El resto de la línea explica por qué (aquí: una función que se eliminó en PHP 8, lección 8.4).

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

¿No hay nada útil en el registro de errores? Entonces añada en wp-config.php (por encima de «deje 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 deje esto activado más tiempo del necesario: debug.log está en una carpeta que el servidor web ofrece, y quien conozca la dirección puede leerlo. Contiene rutas, a veces nombres de usuario y otra información que ayuda a un intruso. Desactívelo de nuevo cuando termine de buscar 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 sea público.

3. Desactivar un plugin sin acceder al escritorio

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

wp-content/plugins/oude-slider   wordt   wp-content/plugins/oude-slider-uit

WordPress ya no encuentra el plugin y lo desactiva. Si no sabe cuál es, renombre toda la carpeta plugins a plugins-uit: todos los plugins se desactivan. Si el sitio funciona entonces, cree una nueva carpeta vacía plugins, vaya devolviendo los plugins uno a uno y compruebe después de cada uno si el error reaparece. Para un tema se aplica lo mismo: renombre la carpeta del tema activo y WordPress volverá a un tema predeterminado, si todavía está instalado (lección 2.4).

4. Conflictos sin error fatal

No todos los problemas son un error crítico. A veces una sola función no funciona: un botón no hace nada, el formulario no se envía, el editor carga a medias. En ese caso suele tratarse de un conflicto entre dos plugins o entre un plugin y el tema. Para esto resulta útil el plugin oficial Health Check & Troubleshooting: en el modo de resolución de problemas desactiva todos los plugins solo para su sesión y cambia a un tema predeterminado, mientras los visitantes siguen viendo el sitio normal. Después los va activando uno a 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 automáticamente su sitio: versión de PHP obsoleta, plugins y temas que no están activos, extensiones de PHP que faltan, una API REST que no funciona, tareas programadas que van con retraso. En la pestaña Información aparecen todos los datos de su instalación (versiones, rutas, configuración de PHP). Esa pestaña se puede copiar y enviar si pide ayuda. Revíselo después de cada cambio importante.

Resumen

• Desactivar deja los archivos en su sitio; borre los plugins y temas que no utilice.
• Ordene cada trimestre, un plugin cada vez, con una copia de seguridad o en un 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 de nuevo cuando termine de buscar, porque de lo contrario debug.log es público.
• Sin acceso al escritorio, desactive un plugin renombrando su carpeta; busque conflictos 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 y demuestre con el código que le indica el ejercicio que es su propio sitio (un registro TXT o un pequeño archivo). El programa solicita /wp-content/debug.log: es correcto si no existe o se deniega (404 o 403). Si el programa recibe de vuelta un archivo, aparecerá en rojo. Además, el programa cuenta cuántas carpetas de plugins distintas aparecen en el HTML de su página de inicio (solo con carácter informativo).

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

Para saber más

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 después de 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/