Veremos un método para actualizar Drupal core en sitios complejos, osea instalaciones de Drupal multisitios, con modificaciones en el core de Drupal o modulos core.

Es normal que se liberen muy seguido nuevas versiones de Drupal que no traen nuevas características, sino que son actualizaciones de seguridad y correcciones a pequeños fallos.

En los casos de tener un Drupal con múltiples sitios, varios módulos contrib, modulos core modificados, o cualquier otra instalación compleja de Drupal, se nos hará difícil estar constantemente actualizando nuestro Drupal core de la forma tradicional, por este motivo buscaremos una manera más practica (pero no sencilla) de realizar esta tarea.

Este método no es aplicable para actualizar tu Drupal core 5.x a 6.x, sino para esas actualizaciones que se liberan por problemas de seguridad.

Ejemplificaremos con la actualización que recién hice de Drupal core 5.7 a 5.10

IMPORTANTE: Hacer backup de bases de datos y archivos antes de comenzar, el autor de este artículo no se responsabiliza por lo daños que el mismo pueda causar.

El método consta de dos partes:

En la primer parte analizaremos los cambios que realizamos a nuestro drupal 5.7 que esta en funcionamiento

En la segunda parte crearemos un parche con la aplicación diff y las dos versiones de drupal (5.7 y 5.10 en nuestro ejemplo).

Luego con la información con de ambas partes sabremos si podemos aplicar el parche y que cambios serán necesarios para poder aplicarlo.

Si tu Drupal en funcionamiento no tiene cambios en los archivos del core, entonces puedes saltar directamente a la segunda parte.

Primer parte: Analizar las modificaciones en el Drupal Core en funcionamiento

Creamos un directorio Drupal, descargamos y descomprimimos nuestra versión actual y la versión a la cual actualizaremos.

Nos quedarán los directorios drupal-5.7 y drupal-5.10 con sus versiones de Drupal core originales.

Sabemos que nuestra versión actual de Drupal es la 5.7 pero que contiene algunos archivos modificados, como podrian ser:

robots.txt: Es muy probable que hayamos modificado este archivo porque la version que trae Drupal core esta incompleta.

.htaccess: Es probable que hayamos agregado algunas redirecciones a este archivo según los requerimientos de nuestro/s sitio/s.

Drupal core y modulos core: Podriamos haber modificado algunos de los archivos del core de Drupal y módulos core.

Archivos ocultos/eliminados: Seguramente habremos eliminado algunos de los txt para complicarle la vida a los bots que andan consultando que versión de Drupal tenemos instalado. Tampoco esta mal eliminar u ocultar el install.php, sites/default/settings.php y update.php

Seguramente tendremos anotado en algún lado que archivos modificamos, o tendremos que recordar un poco. Pero para estar mas seguros utilizaremos un script que no diga que cambios sufrió nuestro Drupal respecto a la versión original.

Asi que compararemos nuestro Drupal core 5.7 funcionando con el Drupal core 5.7 original, para ello usaremos el siguiente script:

cambios.sh

Ejecutamos el script y guardamos la salida.

En mi ejemplo leo el archivo cambios.txt y observo:

Archivos que se eliminaron:

Antes de aplicar el parche conviene reponer los archivos php que se eliminaron/ocultaron en el Drupal en funcionamiento. Por si necesitan actualización.

Es importante destacar que si el archivo sites/default/settings.php fue modificado en la nueva versión del core con algún nuevo parámetro, tendremos que reconfigurar nuestros sitios (sites/example.com/settings.php) con este nuevo archivo.

Archivos que se modificaron:

Además de decirnos que archivos se modificaron, también nos queda guardado cuales fueron los cambios.

Tendremos que entender como se lee un archivo diff. Veamoslo básicamente con un ejemplo:

Numere las lineas para poder indicar lo que nos dice el archivo.

En la salida de diff de ejemplo podemos observar:

Las lineas 1) y 2) nos dice que es el archivo que se modifico es robots.txt y algunos datos mas. Estas lineas comienzan con --- y +++

Los cambios que se realizaron al archivo robots.txt estan entre las lineas 6) y 10)

Las lineas que comienzan con - indican que se quitaron y las lineas que comienzan con + indican que se agregaron.

Las demas lineas son para facilitar la lectura y tener a la vista el contexto, pero no son cambios.

La linea 6) nos dice que se quito una linea en blanco
La linea 7) nos dice que se quito una linea que contenia User-agent: *
La linea 8) nos dice que se quito una linea que contenia Crawl-delay: 10

La linea 10) nos dice que se agrego una linea con User-agent: *

El resultado es que se quito Crawl-delay: 10 del robots.txt. La linea User-agent: * solo cambio de posicion, de la linea 8 a la 10.

Segunda parte: Creación y aplicación del parche

Eliminamos los documentos txt en los core Drupal 5.7 y 5.10 originales que no estan en nuestro Drupal en funcionamiento.

CHANGELOG.txt
UPGRADE.txt
INSTALL.txt
INSTALL.pgsql.txt
MAINTAINERS.txt

No elimines el robots.txt que es el unico txt útil.

El parche se crea muy fácil, primero nos movemos al directorio /home/pepe/drupal donde descargamos las versiones core y luego ejecutamos diff con las siguientes opciones:

Cómo organizar las versiones de drupal en funcionamiento

Para poder mantener varias versiones de Drupal y poder volver rápidamente a una versión anterior en caso de problemas, mantendremos la ultima versión en funcionamiento durante unos días hasta que hayamos comprobado que la nueva versión funciona bien.

En nuestro ejemplo drupal esta funcionando dentro de /var/www, osea tendremos un directorio.

/var/www/drupal-5.7 donde estará nuestro Drupal funcionando.

Copiamos este directorio a /var/www/drupal-5.10, al cual aplicaremos el parche.

Por ultimo tendremos un enlace simbólico que apuntara al Drupal en funcionamiento para indicarle al apache que Drupal ejecutara.

En resumen nos quedara:

/var/www/drupal-5.7 Drupal funcionando
/var/www/drupal-5.10 Drupal copia del anterior que parchearemos
/var/www/drupal enlace simbólico que apunta a /var/www/drupal-5.7 pero una vez aplicado el parche apuntara a /var/www/drupal-5.10

También tendremos que configurar apache para que el DocumenRoot sea el enlace simbólico (/var/www/drupal) y además permita utilizar enlaces simbólicos.

Probar el parche

Probaremos si al aplicar el parche con el comando patch nos trae algún problema, para ello simularemos la aplicación del parche pero no modifcaremos nada.

La opcion --dry-run hace que patch simule la aplicación del parche, pero no modifica ningún archivo.

Aquí observaremos que no de errores, en caso de errores tenemos varias posibilidades:

Si el error es en un archivo que contiene php es porque hemos modificado ese código, tendremos que volver el archivo a la versión original, aplicar el parche y luego rehacer nuestras modificaciones.

Los archivos mas frecuentes que dan errores son el robots.txt y el .htaccess porque necesitan bastantes modificaciones según los requerimientos de nuestros sitios

A estos dos archivos prefiero quitarlos de la versiones originales antes de crear el parche y manualmente analizar y aplicar los cambios. Porque tienen muchísimas modificaciones.

Una vez que logramos que la simulación del parche no de errores, procedemos a aplicarlo.

Antes de aplicarlo sacamos de servicio los sitios.

Modificamos el enlace simbolico al nuevo drupal (/var/www/drupal-5.10)

Ejecutamos el script de actualizacion (www.example.com/update.php) para actualizar el esquema de base de datos (en cada sitio).

En caso de archivos php core o módulos core modificados. Rehacer los cambios.

Verificar si el archivo settings.php tuvo modificaciones de parametros y rehacer el settings.php (sites/example.com/settings.php) de nuestros sitios.

Eliminar/esconder los archivos install.php update.php y sites/default/settings.php

Y por último verificamos que todo ande bien y volvemos a poner el/los sitio/s en línea.