Cómo solucioné un error de Simply Static tras migrar un WordPress

Nota: El problema descrito en este artículo se produjo utilizando Simply Static 3.7.2. Es posible que en versiones posteriores cambie la ubicación de la configuración o el comportamiento del plugin.

Hace unos días me encontré con un problema bastante curioso al migrar una instalación de WordPress a un nuevo servidor.

La migración había ido bien.

• La web cargaba correctamente.
• El dominio respondía sin problemas.
• La base de datos estaba actualizada.
• El certificado SSL funcionaba.

Todo parecía indicar que el trabajo había terminado.

Sin embargo, al intentar generar la versión estática de la web con Simply Static, el proceso fallaba.

Logotipo de WordPress: Zekelhuter, CC BY-SA 4.0; imagen disponible bajo la misma licencia.

Un error poco evidente

Simply Static permite generar una copia completamente estática de una web WordPress para publicarla después en cualquier servidor.

En mi caso, al iniciar la generación del ZIP, el proceso terminaba con un error. Lo curioso era que la web funcionaba perfectamente: no había errores en WordPress ni en el servidor, así que la causa no era nada evidente.

La investigación

Como suele ocurrir en este tipo de situaciones, empecé revisando lo habitual: URLs antiguas, configuración de WordPress, permisos de archivos, cachés y base de datos. Todo parecía estar correcto.

Así que decidí revisar la configuración del propio plugin. Y ahí apareció el problema.

La configuración que había sobrevivido a la migración

Dentro de los ajustes avanzados de Simply Static hay un apartado para definir el directorio donde se almacenan los archivos temporales durante la generación.

La ruta configurada seguía siendo la del servidor anterior. Algo similar a esto:

/var/www/vhosts/servidor-anterior/httpdocs/wp-content/plugins/simply-static/static-files/

Después de la migración, ese directorio simplemente ya no existía. El plugin seguía intentando escribir ahí sus archivos temporales y el proceso terminaba fallando.

Ese valor, y esto es lo que explica que un dato así sobreviva, no vive en un fichero de configuración del servidor: es la clave temp_files_dir dentro de la opción simply-static, guardada en la tabla wp_options de la base de datos. Es decir, viaja en el volcado. Migras la base de datos, que es exactamente lo que hay que hacer, y con ella se muda una ruta absoluta que solo tenía sentido en la máquina de origen.

Un detalle más, útil para diagnosticar: Simply Static tiene una pantalla de Diagnostics que comprueba precisamente esto y avisa de si el servidor web puede leer y escribir en el directorio de archivos temporales. Si el fallo es este, ahí sale marcado.

La solución

Fue más sencilla de lo que esperaba. En Simply Static 3.7.2 basta con ir a:

Simply Static → Settings → Advanced → Debug → Temporary Files

y corregir el directorio. Después, Clear Temporary Files para eliminar restos de ejecuciones anteriores, guardar y volver a lanzar la generación. Esta vez el ZIP se generó sin ningún problema.

Ahora bien, si tuviera que volver a hacerlo, no pondría la ruta nueva a mano: dejaría el campo vacío. Cuando ese ajuste está en blanco, el plugin resuelve el directorio por su cuenta y lo sitúa dentro de la carpeta de subidas, en wp-content/uploads/simply-static/temp-files/, creándolo si hace falta. Una ruta relativa a la instalación en lugar de una absoluta al servidor es justo lo que hace que el problema no se repita en la siguiente mudanza.

Y si por lo que sea el directorio tiene que estar en otro sitio en un entorno concreto, existe la constante SIMPLY_STATIC_TEMP_FILES_DIR, que se define en wp-config.php y tiene prioridad sobre lo que haya en la base de datos. Es la forma correcta de que una ruta dependiente del servidor viva en el servidor y no en el volcado.

Consejo: Si has migrado tu WordPress a otro servidor y Simply Static deja de generar el ZIP, merece la pena revisar este ajuste antes de invertir tiempo buscando problemas en la base de datos, los permisos o la configuración de WordPress. En mi caso, esa única ruta era la causa del fallo.

Una buena lección

Cuando hacemos una migración solemos preocuparnos por el dominio, la base de datos, las DNS, el certificado SSL y los enlaces internos.

Pero algunos plugins guardan además configuraciones específicas del servidor —rutas absolutas del sistema de archivos para cachés, copias de seguridad, exportaciones o temporales— en la propia base de datos. Ese tipo de ajuste pasa desapercibido porque la web sigue funcionando con normalidad. Solo se descubre cuando el plugin necesita acceder a una carpeta que ya no existe.

Un punto más para mi checklist

A partir de ahora, siempre que migre una instalación de WordPress revisaré también la configuración de los plugins que trabajen con archivos temporales, copias de seguridad o exportaciones. Es una comprobación de un minuto que puede ahorrar bastante tiempo de depuración.

La migración había terminado. Pero una parte de la configuración seguía viviendo en el servidor anterior.