Reading time aprox: 2 minutes, 58 seconds
Actualizar tu servidor local de WordPress.
Cuando tenemos un servidor local con una copia de WordPress, no es infrecuente que escribamos o hagamos cambios en el servidor «en vivo» y la copia local quede desactualizada.
Cierto es que es más que aconsejable, tener una copia de seguridad que se ejecute de forma automatizada cada (aplíquese lo que proceda en cada caso) día/semana/mes.
Y sería lógico, usar esa copia de seguridad para restaurar nuestro servidor local al estado real.
Actualizar tu servidor local de WordPress
Hay ocasiones en que los cambios no tienen mayor envergadura, o han sido pocos. En este caso, ¿vale la pena manejar todo el peso de una copia de seguridad completa?
Es cierto que dependiendo del plugin de copia que tengas instalado, podrás hacer copias de seguridad incrementales, lo que redundará en un menor «peso» del archivo de copia y, quizá eso ya lo haga más manejable.
Pero no es lo más usual encontrar este tipo de copias, así que debemos realizar manualmente el proceso de selección.
Sea cuál sea el caso, en el archivo de copia nos interesa contar con dos elementos:
- La copia de la base de datos.
- La copia del sub directorio uploads
Veamos cómo se manejan
Los elementos
del archivo de copia.
Por lo general, los plugin de copia de seguridad, generan un archivo comprimido en formato ‘.zip’ que contiene todos los componentes de la copia.
Por un lado tenemos la copia de la base de datos y por otro, los archivos copia del disco.
La copia de la base de datos
Normalmente, la copia de la base de datos viene almacenada en uno o más archivos con el formato propio de SQL, independientemente de si el motor de SQL del servidor es mySQL o MariaDB, que son los dos formatos con los que puede trabajar WordPress.
La diferencia entre las copias en un único archivo ‘sql’ o varios, no presenta gran diferencia, salvo por el tratamiento que hace el plugin en concreto. Para este caso, asumiré que el plugin genera un único archivo ‘sql’.
También para efectos de este artículo, asumiré que se usa mySQL, como se indica en la entrada: Instalando WordPress en tu servidor LAMP.
Para restaurar la copia de la base de datos, hay que acceder al servidor SQL con una herramienta como phpmyadmin.
En el servidor seleccionamos la base de datos correspondiente a la copia de WordPress, con lo que nos presentará todas las tablas que componen esa base de datos.
Vamos a seleccionar todas las tablas y las eliminamos (drop) con lo que la base de datos quedará vacía.
Procedemos a importar el contenido de la base de datos.
Para eso tenemos que extraer del archivo de copia comprimido, el archivo de datos sql.
Y luego, en la consola de phpmyadmin presionar el enlace Importar, seleccionar el archivo ‘.sql’ que hemos extraído y, ¡listo!
Cuidado, hay que hacer un pequeño cambio antes de intentar usar esa base de datos.
Para que las cosas funciones y no la líes, hay que cambiar la localización de la copia de WordPress.
Si intentamos acceder, aunque estemos en local, a la bitácora con la base de datos como está, es posible (altamente probable) que terminemos dañando la copia en línea de nuestra bitácora, porque WordPress usa los datos de la base de datos que es una copia fiel.
Para evitar esta situación, antes de hacer nada más, hay que acceder a la tabla de opciones de WordPress y cambiar un par de registros.
En el registro número 1, se encuentra el valor de siteurl que es la dirección actual de nuestra bitácora, deberemos cambiarlo para que sea la dirección en el servidor local (posiblemente algo como: https://192.168.1.54/)
De igual forma, en el registro número 2, está el valor home que también debe apuntar al servidor local (posiblemente algo como: https://192.168.1.54/wordpress)
Una vez que tenemos la base de datos, nos ocupamos de
La copia de los archivos
En el archivo de copia que tenemos y, que es de dónde se extrajo el archivo ‘.sql’ de la base de datos, se encuentran los demás archivos de WordPress, con toda la estructura de directorios.
Si la copia ha sido incremental en lugar de total, sólo estarán los subdirectorios que contengan archivos que han sido cambiados o añadidos desde el momento de la copia anterior.
En cualquier caso, hay subdirectorios que raramente cambian, incluso tras una actualización. Hay directorios, por otro lado, que cambian continuamente con cada imagen que subimos o cambio de plugins (incluidas las actualizaciones).
Si se han producido cambios de importancia o simplemente si no estamos seguros, es mejor «curarse en salud» y reemplazar todos los directorios que encontremos en el archivo comprimido de la copia de seguridad.
Si estamos seguros de que los únicos cambios son los producidos por las imágenes nuevas que hemos puesto en la bitácora, podemos centrarnos en el directorio /wp-content/uploads/, pues es ahí donde se almacenan las imágenes que vamos añadiendo.
Y de este modo, hemos hecho una restauración o actualización de nuestra copia local de la bitácora.
¡Gracias por leernos!
¡Tus comentarios y preguntas nos ayudan a mejorar, por favor comenta!