WordPress y sus problemas de actualizaciones automáticas

Tras una actualización hacia Apache 2.4 observe que ciertos clientes tenían problemas con el sistema de actualizaciones de WordPress o en el de la subida de ficheros multimedia.

En unos caso emitía el informe de error, en otros ni siquiera decía nada, y sin embargo el sistema de permisos de las carpetas de los usuarios en sus instalaciones de WordPress estaban correctos.⁽¹⁾

⁽¹⁾ Los permisos dependerán de la topologia de la instalación. Deberá consultar con su Hosting. En nuestro caso, los permisos deben ser 750 para el directorio y 640 para ficheros que necesitan escritura. Si desea más seguridad se recomienda 440 para ficheros que no deben ser modificados y contienen informacion sensible (configuraciones por ejemplo)

Verificación del path: ajustes multimedia

Algunos plugins, o tras cambios de servidor, es posible que el path de WordPress apunte a una configuracion que no es apropiada. Este error, no deja rastro en los logs (que feo) por lo que deberemos verificarlo.

Generalmente lo encontraremos en Ajustes Multimedia

Tanbiem deberemos verifciar el contenido del fichero wp-config.php por si tuviera una acción define para esta varbela como

define( 'UPLOADS', 'wp-content/'.'uploads' );
// El path no puede ser absoluto y siempre es relativo a ABSPATH, ademas no que no requiere el slash del final

Los permisos

En este artículo voy a desarrollar el proceso de análisis y búsqueda de soluciones de una forma progresiva, que permitirá al usuario medio, la compresión necesaria de los pasos a seguir, para poder solventar por sí mismo los problemas derivados de esta situación. ⁽²⁾

Permisos de las carpetas en el servidor

En el 95% de los casos, el universo de Internet muestra una información, un tanto obsoleta que se ha convertido en una especie de Ley fundamental del Hosting:

“Los permisos de la carpeta temporal o donde se hace la descarga son incorrectos”Fake Gurus

El motivo es que la configuración Apache + Modulo PHP (DSO) para Hosting compartidos, es muy poco utilizada, salvo en empresas de Hosting, cuya capacidad técnica o cuya infraestructura es muy pobre, siguen usándolo ya sea por lo económico de la solución (—coste en recursos —dificultad en el mantenimiento y administración del sistema), como por lo sencillo de la implementación.

Estos handlers, hacen que los scripts PHP se ejecuten por el usuario del sistema y no por el usuario que ejecuta Apache (nobody, wwwdata, www, según la distribución y/o panel de control para Hosting)

Así pues, en este escenario (handlers que ejecutan PHP como usuario propietario del sitio), los permisos son 750/755 para directorio y 640/440 (según queramos más o menos seguridad, o tengamos necesidad de escritura sobre los ficheros. Esa ya sería parte de otro artículo)

Lectura de logs

Otro de los puntos importantes del análisis, sería la lectura de los logs o bitácoras que forman parte del problema.

• Apache
• Mod Security
• Firewall
• PHP

Forman parte del gran olvidado en las recomendaciones de los expertos en los distintos artículos y mensajes de los foros que podamos encontrar.

Así pues, en Cpanel podríamos necesitar acceso SSH o si no lo tenemos concedido, podríamos usar las herramientas que facilita Cpanel ⁽³⁾

Si tras la lectura de los logs (en mi caso suelo tener varias ventanas abiertas para la lectura) no vemos nada extraño deberemos continuar nuestra investigación. Por el contrario, algunos de los logs nos indicaría si se trata de un problema derivado de una regla (rule) de Mod Security, si se trata de una prohibición expresa o problema del fichero .htaccess, o del fichero de configuración de Apache para nuestro Virtualhost, o una prohibición de nuestro cortafuegos (firewall), o cualquier otra cuya acción debe quedar reflejada en esas bitácoras.

En nuestro caso verificamos que ni ModSecurity, ni el cortafuegos CSF, estuvieran bloqueando el proceso de descarga desde download.wordpress.org

Creación de la copia de seguridad (BACKUP)

Ese gran olvidado, el procedimiento más básico y desatendido de la informática, y responsable de la seguridad y minimización del tiempo perdido en caso de desastres, la copia de seguridad o backup.

Activación del sistema de debug de WordPress

Todo software que este medianamente diseñado, debe tener un sistema de debug o depuración, es decir, un método que nos permita aumentar o disminuir el registro de la actividad, con el fin de depurar problemas en nuestro software.

En WordPress podremos activar el modo de depuración

// Activar modo WP_DEBUG
define('WP_DEBUG', true);
// Activar registro de depuración al fichero /wp-content/debug.log
define('WP_DEBUG_LOG', true);
// Desactiva mostrar los errores y avisos
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);
//Usa versiones dev de ficheros centrales JS y CSS (solo necesario si estás modificando esos ficheros centrales)
define('SCRIPT_DEBUG', true);

La verdad es que en nuestro caso, no nos sirvió de nada. A fin de cuentas, WordPress es solo una pequeña parte del universo que suele ir asociado a él. Plugins y temas, son la otra parte que muchas veces como en casi todo el software asociado a Internet, suele ser la pesadilla de nuestros sitios.

Tras varios intentos, WP no nos mostraba absolutamente nada.

Uso de FTP para el sistema de actualización de WordPress y subida de imágenes

Decidí probar el subsistema FTP para subir ficheros y para actualizar WordPress. Este subsistema, se abstrae de los problemas típicos de los permisos ya que mientras el user de ftp tenga permisos de acceso, no importa quien sea el usuario que ejecuta los scripts. En algún caso funciono la subida de ficheros, pero para la actualización seguíamos con el problema.

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_BASE', '/path/to/wordpress/' );
define( 'FTP_CONTENT_DIR', '/path/to/wordpress/wp-content/' );
define( 'FTP_PLUGIN_DIR ', '/path/to/wordpress/wp-content/plugins/' );
define( 'FTP_PUBKEY', '/home/username/.ssh/id_rsa.pub' );
define( 'FTP_PRIKEY', '/home/username/.ssh/id_rsa' );
define( 'FTP_USER', 'username' );
define( 'FTP_PASS', 'password' );
define( 'FTP_HOST', 'ftp.example.org' );
define( 'FTP_SSL', false );

Ya no quise ni probar con el método SSH2, pues pese a que instale en el servidor para otras cuestiones el modulo Pear SSH2, no tenia ganas pues estaba claro que el tema iba mas lejos.

Desactivación de extensiones

Bien, uno de los consejos que mas cuesta de aceptar del Codex de WordPress es el método “empieza de 0” a base de desactivar todos los plugins. Este método funcionará en el 90% de los casos, y el resto será causa de manipulaciones o posibles problemas en las tablas asociadas al core de WordPress. ⁽⁵⁾

• Si tenemos acceso al área de administración podemos desactivarlos todos desde allí.
• Si no tenemos acceso o si preferimos empezar de 0 (aconsejado) lo apropiado es crear una carpeta en ./wp-content/plugins-deactivate/ y mover todo el contenido de ./wp-content/plugins/. Después recargamos el dashboard y estarán todos desactivados.

.htaccess por defecto (Solo en caso de Apache)

Es muy habitual, el uso de plugins de refuerzo para evitar la (in)seguridad de WordPress y sus plugins, y estos hacen uso de .htaccess para añadir directivas de seguridad. Estas pueden afectar a ciertas operaciones, así que se aconseja hacer una copia del fichero .htaccess (.htaccess.XXXXYYMMDD) y dejar el fichero al mínimo. Tras realizar las operaciones de verificación, por ver si era este el problema, podremos volver a poner el contenido original.

# BEGIN WordPress
 
  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.php [L]
  # END WordPress

En el caso de Nginx, deberá revisar el fichero de configuración de su Virtualhost, para revisar que etiquetas de seguridad no sean las que estén afectando al comportamiento del actualizador.

Llegados a este punto, y sin extensiones, el 90% de los sitios recuperarán la facilidad de actualizar automáticamente WP, sus plugins y sus temas.

Si fallara, (puede que en este caso no sea importante pero si puede ser en otros casos de funcionamiento irregular) se recomienda configurar el sitio con un template oficial por defecto.

Localización del elemento distorsionador

Bueno, no hemos conseguido con los pasos anteriores que nuestro WP funcione y se actualice de forma normal. Aquí llegamos a un punto donde la impaciencia suele jugar malas pasadas a más de uno.

• Uno por uno, iremos moviendo los plugins de la carpeta ./wp-content/plugins-deactivate/ a ./wp-content/plugins/
• Uno por uno los iremos verificando.

Uso de Wp-Cli. Migraciones, exportación e importación de sitios.

Exportación

En algún caso, algún cliente con mucha antigüedad, más de 10.000 post y 90.000 comentarios, y código tocado, desconocimiento de su sitio (abandono del administrador antiguo) no le funciono el procedimiento descrito hasta llegar a este punto. Sabíamos que tenía que ser algo interno pues en ese mismo servidor hay mas de 200 WordPress funcionando sin ningún tipo de problema.

La mejor solución, en nuestra opinión en este escenario tan complicado es una migración sobre una instalación desde 0.

• Para ello WordPress nos permite mediante una herramienta nativa exportar el contenido de nuestro blog a un fichero en formato XML, que se localiza en Herramientas->Exportar Marca la opción de exportar TODO y te descargaras un fichero XML en formato WordPress eXtended RSS (RSS ampliado de WordPress) o WXR que contendrá la información necesaria para luego importarlo.
• Exportar las configuraciones de aquellos plugins y/o temas que permiten esta característica. En su defecto anotar o tener guardadas las configuraciones.

Creación del nuevo sitio.

Bueno, llegados a este punto ahí muchos trucos, muchas formas que dependerán del conocimiento del usuario.

Se trata de “eliminar” el contenido actual, y hacer una instalación desde 0

Yo voy a indicar los pasos que realizaría yo, en un servidor con Cpanel (aunque sería valido para cualquier modelo)

• Crear un base de datos nueva en Cpanel
• Crear un usuario con permisos para usar esa base de datos en Cpanel
• Copia de seguridad de la base de datos actual
• Crear una exportación de WordPress, y de aquellos módulos o temas, que permitan guardar su configuración en un fichero descargable.
• Mover el contenido del sitio a una ubicación (fuera del public_html en mi /home/usuario) /home/miusuario/old_wp (*) ssh rsync
• Instalar de 0 un WordPress (mejor si es una versión antigua precisamente para comprobar que funciona el sistema de actualizaciones.
• Copiar la carpeta de uploads a la nueva instalación /home/miusuario/old_wp/wp-content/uploads (*)
• Puede ser un nombre distinto si así lo teníamos en la vieja instalación.
• Comenzar instalar los módulos
• Instalar el tema usado por nuestro sitio
• Importar el fichero WXR que guardaste antes
• Repasar todo…

Uso de Wp-cli

Bien, un sitio como el de mi clienta, cuyo fichero WXR pesaba mas de 200Mb , puede ser un verdadero problema, ya que el tiempo necesario para el proceso del fichero, así como el tamaño del mismo pueden hacer que el procedimiento sea, cuando menos lento, y lo más seguro frustrante por ser necesarios más de un intento, y sus correspondientes ajustes.

Encontré esta herramienta que uso a menudo y que me parece buenísima, pues el uso del Shell, para realizar tareas que requieren del uso de ficheros de gran tamaño, y operaciones complejas, es infinitamente más rápido y eficaz que el uso de interfaces web (backups de mysql, restauración, trabajo con ficheros XML, etc)

Para estos caso lo mejor es usar Wp-Cli, básicamente una entrada al mundo de las RESTful Api, orientado a WordPress. Algo que los desarrolladores (modernos) llevan reclamando mucho tiempo. Necesario para desarrolladores de aplicaciones (plugins, temas y/o sitios) de wordpress, con un modelo de trabajo, rápido, eficaz y limpio.

Los pasos son bien sencillos:

1. Comprimir el fichero descargado WXR ⁽⁶⁾
2. Subir el fichero a nuestra cuenta de Hosting
3. Descomprimir el fichero
4. Ejecutar el comando para restaurar o importar el contenido del fichero WXR

wp import  --path= --authors=create --debug

Tras la importación usando el comando de arriba (es el recomendado, pero la descripción del comando es más extensa) serán necesarios en muchos casos, los ajustes, de los plugins, el tema, pero a cambio tendremos una instalación limpia, muy apropiado sobre todo para wordpress que llevan años, desde los inicios de las primeras versiones, arrastrando en muchos casos suciedad en sus bases de datos.

(*) Lamentablemente el 90% de los Hosting famosos que dan soporte a los webmasters, no permiten el uso de SSH aduciendo problemas de seguridad cuando en realidad se refieren a problema de incapacidad técnica o un celo en la seguridad, que les provoca pánico debido quizás a su pobre formación técnica. O incluso, porque es un buen argumento de marketing, para vender a sus clientes, el “subir” a un VPS o a un Servidor Dedicado. Es curioso que luego estas mismas empresa trabajen sus empleados con entornos Windows, y sin políticas de seguridad. Si no te dejan usar SSH, mejor cambia de empresa de alojamiento web.

⁽¹⁾ Los permisos dependerán de la topologia de la instalación. Deberá consultar con su Hosting. En nuestro caso, los permisos deben ser 750 para el directorio y 640 para ficheros que necesitan escritura. Si desea más seguridad se recomienda 440 para ficheros que no deben ser modificados y contienen informacion sensible (configuraciones por ejemplo)

⁽²⁾ El documento no trata de expresar un método único o lineal, sino por el contrario mostrar la comprensión sobre el problema, y los pasos a seguir en estas situaciones

⁽³⁾ Algunos Hosting se capan las facilidades y menús de Cpanel, dejando el mino a sus clientes, y pudiera ser, que no localizará el visualizador de errores (es la herramienta que muestra los logs de error de Apache) o la descarga de logs de Apache.

⁽⁴⁾ Guardar la copia de seguridad para siempre en el servidor, guardarla en las carpetas de acceso público (public_html) es un error, y un grave problema de seguridad, muy común. Descargue la copia y manténgala a resguardo.

⁽⁵⁾Uno de los problemas de este procedimiento en muchos casos, es que el usuario, no hace el proceso paso por paso, sino que muchas veces se “adelanta” porque cree que tal o cual plugin es el causante. Al final, sin un método lineal, progresivo el proceso puede ser inútil.

⁽⁶⁾ La compresión de un fichero Xml con zip o gz será de un ratio de 10/1, como en el ejemplo de nuestra cliente que paso de 245Mb a 26Mb

• WP WordPress Fatal error: Allowed memory size Dashboard