{"id":868,"date":"2018-11-28T10:30:42","date_gmt":"2018-11-28T09:30:42","guid":{"rendered":"https:\/\/blogs.ugr.es\/tecweb\/?p=868"},"modified":"2018-11-28T10:31:24","modified_gmt":"2018-11-28T09:31:24","slug":"actualizar-el-nucleo-de-drupal-minor-version-update","status":"publish","type":"post","link":"https:\/\/blogs.ugr.es\/tecweb\/actualizar-el-nucleo-de-drupal-minor-version-update\/","title":{"rendered":"Actualizar el n\u00facleo de Drupal (minor version update)"},"content":{"rendered":"

Una de las cosas que m\u00e1s molesta a los usuarios de Drupal es el proceso de actualizar el n\u00facleo del software, especialmente si vienes de WordPress y observas que ese CMS, t\u00e9cnicamente m\u00e1s pobre que Drupal, puede realizar actualizaciones autom\u00e1ticas desde su versi\u00f3n 3.7 (de octubre de 2013).<\/p>\n

Adem\u00e1s de WordPress existen otros CMS que permiten la actualizaci\u00f3n autom\u00e1tica del core del CMS sin quebraderos de cabeza para el usuarios. Pero en Drupal\u2026 NO.<\/p>\n

Lo cierto es que este asunto es bastante recurrente en los foros de Drupal. De hecho, en 2009 se empez\u00f3 a hablar de este tema<\/a> y se volvi\u00f3 a retomar con la aparici\u00f3n de la versi\u00f3n 8.0<\/a>, pero los avances son bastante pobres y, en el caso de que se produzcan, no tendr\u00edan \u201cefectos retroactivos\u201d, por lo que solo ser\u00eda \u00fatiles para las versiones m\u00e1s actuales del CMS.<\/p>\n

Con sorpresa descubr\u00ed hace unos meses que la \u00faltima versi\u00f3n del panel de control de hosting Plesk<\/a> se encarga de hacer la actualizaci\u00f3n autom\u00e1tica del n\u00facleo de este CMS de manera autom\u00e1tica. Pero claro, no todo el mundo usa Plesk.<\/p>\n

\"Plesk<\/a><\/p>\n

As\u00ed que el problema sigue estando ah\u00ed. Como adem\u00e1s es una cuesti\u00f3n bastante recurrente en mi asignatura<\/a>, creo que es interesante hacer una peque\u00f1a rese\u00f1a sobre uno de los muchos procedimientos que existen para realizar esta actualizaci\u00f3n.<\/p>\n

Y digo \u201cmuchos procedimientos\u201d porque realmente es posible realizar la actualizaci\u00f3n de cuatro formas diferentes<\/a>. De todas ellas, la que m\u00e1s me gusta es la que emplea el shell para comandos Drush<\/a>, del que cada vez esto m\u00e1s enamorado, pero como no es el que suele emplear la gente normal, me decantar\u00e9 por hacer la est\u00e1ndar.<\/p>\n

Antes de nada hay que especificar que este tipo de actualizaciones son del tipo minor<\/i>, es decir, la que actualiza de una versi\u00f3n 7.x a otra 7.x superior. Las actualizaciones ma<\/i>j<\/i>or<\/i> son las que sirven para pasar a versiones superiores, por ejemplo, de una 6 a una 7 o de una 7 a una 8. En Drupal los cambios minor<\/i> se denominan updating (actualizaci\u00f3n), mientas que las major<\/i> son upgrading (mejoras).<\/p>\n

Los pasos son bastante sencillos, pero conviene ser riguroso en su tratamiento. Drupal es un software muy sensible, y realizar las cosas en un orden diferente al esperado hace que el software responda de manera err\u00f3nea. Para mostrar el proceso voy a actualizar una versi\u00f3n<\/p>\n

7.50<\/a>, de Julio de 2018, a la \u00faltima 7.x lanzada en el momento de hacer esta entrada, que es la 7.61<\/a>, de noviembre de 2018.<\/p>\n

\"Versi\u00f3n<\/a><\/p>\n

1.- Realizar una copia de seguridad de la base de datos<\/h3>\n

Este es siempre un paso imprescindible siempre que se vaya a realizar cualquier cosa importante en Drupal. Es m\u00e1s, yo recomiendo hacerla incluso antes de instalar m\u00f3dulos y\/o temas, ya que la experiencia me dice que en muchas ocasiones un solo m\u00f3dulo puede volver muy inestable cualquier instalaci\u00f3n. Pues con m\u00e1s motivo, si vas a actualizar, lo ideal es realizar la copia de la base de datos completa en la que tengas instalado Drupal. As\u00ed, si las cosas salen mal siempre puedes volver al punto en el que estabas antes de entrar en p\u00e1nico.<\/p>\n

 <\/p>\n

2.- Crear una copia de seguridad de los ficheros<\/h3>\n

En la mayor\u00eda de CMS siempre hay dos elementos clave a la hora de hacer la copia de seguridad. Uno es el evidente, la base de datos; pero mucha gente suele olvidar el segundo elemento: los ficheros del sistema. La base de datos solo almacena datos (que no es poco, porque lo son todo), pero los ficheros de tu sitio web con los pdf, las im\u00e1genes, los php, los ficheros que hacen que funcionen tus m\u00f3dulos y temas\u2026 son igual de importantes. Hacer una copia de seguridad solo de una cosa no vale para nada. Es necesario hacer la copia de seguridad del contenido de tu carpeta sites<\/i>, que es donde se almacena todo este contenido en Drupal. Para ello puedes usar el administrador de ficheros de tu hosting o un cliente FTP.<\/p>\n

\"Copia<\/a><\/p>\n

3.- Poner en sitio en modo mantenimiento<\/i><\/h3>\n

Haciendo eso consigues que ning\u00fan usuario modifique el contenido del sitio web al mismo tiempo que se produce la actualizaci\u00f3n, con el consiguiente problema de recursividad que puede producir en la base de datos. La ruta donde se encuentra esa opci\u00f3n es:<\/p>\n

Administraci\u00f3n \u2192 Configuraci\u00f3n \u2192 Desarrollo \u2192 Mantenimiento<\/pre>\n
O si lo tienes en ingl\u00e9s:<\/p>\n
Administration \u2192 Configuration \u2192 Develpoment \u2192 Maintance mode<\/pre>\n
\"Poner<\/a><\/p>\n
4.- Eliminar ficheros<\/h3>\n
Desde el administrador de ficheros del hosting (o desde el FTP) debes eliminar todo el contenido de tu servidor web donde se encuentre Drupal. Suponiendo que solo tienes el CMS instalado en la ra\u00edz del servidor, deber\u00edas eliminar todo el contenido de tu ra\u00edz salvo los siguientes ficheros y carpetas:<\/p>\n