¿En qué me afectan las novedades de Drupal 10?

Portada del podcast Drupalízate
Drupalízate es un podcast semanal creado por mí, donde hablo sobre desarrollo web basado en Drupal.
El contenido central es resolver las típicas dudas que pueda tener alguien que tiene o quiere tener una web en Drupal.
Aparte de resolver dudas de "clientes", también se habla de tips, recomendaciones y buenas prácticas para el Developer que recién empiezan en este mundo.
Audio y notas del episodio

Hoy te hago un resumen de las novedades que vienen en Drupal 10, que se publica en diciembre de 2022, y te explico en que te afectan a ti esos cambios con respecto a lo que tienes actualmente en Drupal 9.

Transcripción automática de este episodio de audio (puede contener errores)

Hola otra semana más aquí en Dupalizate. Hoy quiero comentar los cambios que se vienen con la nueva versión de Dupal 10. Para que no sepa, Dupal 10 sale en menos de un mes. Estoy grabando esto a mediados de noviembre. Dupal 10 sale públicamente a mediados de diciembre. Creo que lo digo de memoria, el día 14 o 15, creo que es el 14 de diciembre. Eso tiene cosas buenas y cosas malas que dar comentarías, pero más que nada, lo interesante es saber que visualmente habrán cosas que se van a ver distintas o que van a funcionar un poco distinto. Y esto, comentar las novedades que pueden venir en Dupal 10 y a quién le puede afectar y a quién no. Primero de todo, temas visuales. En Dupal 10, en esta nueva versión, dejamos de tener el Modulo... perdón, el Modulo... el tema Bad Kit y el tema Seven. El tema Bad Kit es aquel tema, digamos, azulado, con colores azules, que está por defecto, y que muy pocas webs usan realmente. Así que, a pocas webs va a afectar. Sí que es verdad que alguna web, he visto yo, que usan el tema Bad Kit como tema base para usar su tema Custom encima. Eso significa que al actualizar Dupal 10, probablemente van a tener que instalar ese tema como un tema contribuido porque ese tema ya no va a estar incluido en el code. Quizá, si se puede, debe ser mejor rehacer el tema y para que no extienda un tema que ya no está en el code, que vaya a extender otro tema, o que directamente no extiende ninguno, y sea un tema base desde cero. Pero bueno, eso. Que pueda afectar, sobre todo si tienes un tema hecho Custom sobre escribiendo el tema Bad Kit, no es lo más normal, pero alguno me he encontrado. O eso, o que tengas directamente usando el tema Bad Kit porque visualmente tu web, a mí, parece que ese tema es bastante feo, anticuado, pero hay webs que lo usan porque visualmente, digamos, lo interesante de su web es el contenido, no es como esté visualmente. Pero bueno, a grandes rasgos, este cambio va a afectar a poca gente. En cambio, tenemos el tema 7. El tema 7 es el tema por defecto que se usa en administración. Y ese sí que está en la mayoría de webs en Dupal 8 y Dupal 9. Sobre todo en 9, porque todavía tienes que haber actualizado ya en Dupal 9. Eso significa que la mayoría de webs lo usan y que la mayoría de webs van a dejar de usarlo. Con lo cual, todos los usuarios que son administrador, editor, moderador, cualquier usuario que haga login en tu web y edite contenidos en tu web, va a dejar de usar o ver el tema 7 y verá el tema claro. El tema claro es un nuevo tema de administración, mucho más moderno, más minimalista, por así llamarlo, y a mi parecer mucho más atractivo, y más usable, más fácil de usar, sin que haga falta explicar dónde están las cosas. A mi punto de vista, esto va a gusto, esto es opiniones, ¿vale? Pero esto que sepáis de que si vuestra web hay usuarios que se loguean y editan contenidos de esa administración, pues van a ver que visualmente hay cosas distintas. Solo cambiar el tema visualmente, o sea, por detrás viene a ser todo lo mismo, pero bueno, es distinto visualmente. Y también, para los usuarios editores o moderadores, los que editan páginas, si estás usando el módulo CKEditor, que venía incluido en el core, el CKEditor en versión 4, que es el que venía antes en Drupal 8 y 9, a partir de ahora, en Drupal 10, ya no existe el CKEditor versión 4, tenemos el CKEditor versión 5, que es el que viene incluido en el core. Lo que implica de que estamos usando una versión superior de CKEditor, mucho más moderna, mucho más visualmente moderna, también minimalista y con mejor experiencia de usuario, es esto, que visualmente es distinta. Así que tus usuarios van a ver que el tema de administración es distinto, porque tenemos el clado en Visual 7, y además, todo lo que es CKEditor, van a pasar a ver de que también se ve distinto. Se puede hacer exactamente lo mismo que en CKEditor versión 4 y algunas cosas más, pero digamos que para la mayoría de webs, que básicamente es un campo de texto y puedes poner H1, H2, H3, y negritas y subrayados y enlaces, viene a ser lo mismo, solo que visualmente se ve un poco distinto. Después, para temas de, digamos, de pica de código para desarrolladores, también se mejoran en Drupal 10 cosas que tienen que ver con hacer webs desacopladas, especialmente para lo que implica temas de menús y gestión de web relés. Esto no me lo miro mucho yo, porque a mí no me ha afectado, porque no he estado en ningún proyecto real de web desacoplada, pero sí que se comenta esto, que en Drupal 10 se está tirando a facilitar todo el tema de poder desacoplar todo lo que es de la web. Así que también, teniendo en cuenta, son mejoras de que en Drupal 10 va a ser más fácil desacoplar partes de la web que lo que ya era, que tampoco es excesivamente complicado hacerlo en Drupal 9. Después tenemos cosas que se han mejorado del módulo Layout Builder y de lo que es la inclusión con el módulo Media. Bueno, son nuevas mejoras y que se está potenciando que se puedan usar estos módulos juntos y para hacer webs más complejas sin tener que tocar código. Al final esto es un montador de páginas, todo desde configuración. Para depender de qué proyectos puede ser bueno o malo, depende de cómo se use, es una opción más a cómo se puede crear landings dentro de Drupal y tener conocimientos de programación, pudiendo poner bloques o partes de contenido donde el usuario quiera. Así que bueno, que sepáis esto, que se han mejorado funcionalidades de ese estilo, lo que mejora la usabilidad de la web para gente que solo quiere configurar y no tener que tocar código. Después están también mejoras, bueno, más que mejoras es el cambio, con el tema Starter Kit. Digamos que se está potenciando, más de lo que se estaba potenciando antes, de hacer temas hechos a medida. Drupal versus otros CMS, básicamente casi la mayoría de proyectos usan temas hechos a medida. O sea, visualmente es un tema que ha hecho un diseñador y después alguien tiene que programarlo para que visualmente la web se vea como el diseño. Digamos que Drupal es un sistema de contenidos, un gestor de contenidos, especialmente, o que se enfoca mucho, a webs hechos a medida, con lo cual tiene sentido mundo que esté intentando facilitar y mejorar cómo se quedan los temas personalizados. Esto, como digo, afecta sobre todo a partir de ahora a los temas hechos a medida, que van a ser más fáciles, o hay más funciones, o se está potenciando más, esta parte. Después está también hablando de temas, de hacer temas a medida. Tenemos las cosas de JQuery y JavaScript. Digamos que Drupal, desde hace muchos años, usa JQuery por detrás, en temas de, en vez de JavaScript puro. JQuery es una cosa que a día de hoy se ha quedado bastante anticuada, por así llamarlo. Y se está potenciando, o digamos que el foco final donde va para todo esto es que Drupal quiere dejar de usar JQuery y se tiene que reemplazar con librerías más modernas de JavaScript. Esto, como digo, afecta solo a webs que tengan actualmente JQuery, actualmente va a poder seguir usando, pero que a futuros los temas nuevos se intenten de que Drupal deje de depender de JQuery. Esto solo aplica básicamente a la gente de Frontend en la que hacen los temas. Si ya tienes una web con esto, no te afecta nada, lo puedes seguir usando. Y después está ya de más de backend de tema de código, digamos PHP, que estamos haciendo un cambio en Drupal 10 a usar, en vez de Symfony 4, que es lo que había en Drupal 9 y 8, a usar lo que está en Symfony 6. Saltamos directamente de Symfony 4 a Symfony 6. ¿Por qué? Básicamente porque Symfony 4 deja de tener soporte en menos de un año, así que la versión estable en ese momento de Drupal no puede estar usando esa versión de Symfony, sobre todo por temas de seguridad, porque ya no se va a dar soporte a esa versión de Symfony. Así que Drupal se ha visto obligada a pasar a la versión más nueva, que tiene mayor tiempo de soporte, y que es Symfony 6. Y esto implica al mismo tiempo que tenemos que tener una versión de PHP también actualizada a una versión mínima de 8.1 de PHP. Eso significa que la mayoría de webs actualmente, o la mayoría, muchas webs tienen PHP 7 en su servidor, así que la actualización a Drupal 10 implica un cambio de Symfony y un cambio de la versión de PHP, lo que implica un cambio de configuración del servidor. Esto visualmente no afecta en nada, solo que desde el punto de vista de backend se han de hacer cambios para que el servidor sea compatible con estos cambios. Y pocos más. Así que de forma resumida tenemos varios cambios de lo que es el frontend, sobre todo de la parte de administración, de lo que afecta a los usuarios que editan contenidos, que van a ver cosas distintas. Y después tenemos varios cambios que afectan a nivel de código, de generación de temas hechos a medida, o partes de código PHP, ya sea por código custom o porque tú vas desarrollando módulos contribuidos. Así que sí, vienen muchos cambios en Drupal 10. La mayoría, por no decir todos, son muy buenos y algunos bastante esperados por la comunidad. Y por los más datos de esto, comentar de Drupal 10 se lanza ahora en diciembre. Yo no actualizaría tal cual ahora mismo en diciembre en Drupal 10. Me esperaría unos meses, dos, tres... Primero sería mirar si tu web actualmente, todos los módulos contribuidos que tú uses, son compatibles con Drupal 10, que puede ser que aún haya alguno que no. Y por eso te digo de esperarte unos meses. En plan, a principios del año que viene, en enero, febrero, marzo, volveré a mirártelo y si ya están todos actualizados, que deberían estar la gran mayoría, pues entonces sí, actualizar. Si tu web es muy pequeña, apenas usas módulos contribuidos, y en diciembre mismo ya estás viendo de que están todos disponibles, todos los que usas tú, están disponibles en la versión de Drupal 10, pues adelante, hazlo. Pero para webs más complejas, con muchos módulos contribuidos, puede ser que no todos sean compatibles con Drupal 10 ahora en diciembre. Por eso te digo de no hace falta que actualices ya antes del fin de año. A todo esto también, comentar para la gente que no sabe de temas de backend, actualizar un módulo, o sea, modificar un módulo existente de Drupal 9 para que sea compatible con Drupal 10, muchos lo único que tienen que hacer es modificar el.info, o sea, el fichero de información del módulo para especificar de que es compatible con Drupal 10, y con eso muchos ya está, porque básicamente de un Drupal 10 es la última versión de Drupal 9 con la eliminación del código de precado y los cambios de symphony. No cambian muchas más cosas. Si estás usando, digamos, código actualizado actualmente en Drupal 9. Así que si el módulo contribuido está más o menos al día, la actualización es básicamente cambiar el.info y ya está. Así que es verdad que en algunos otros módulos pueden haber un par o tres de funciones que están de precadas y se han de modificar, pero que también son cambios relativamente simples de aplicar para actualizar un módulo existente de Drupal 9 a 10. Aún así, hay módulos de Drupal 9 que, digamos, son más viejos, que no están apenas actualizados hace no sé cuánto tiempo. Y aquí sí que podemos encontrar de que, bueno, pues, tengan muchas cosas de precadas que se han de cambiar y que pueden llevar más tiempo en arreglar todos esos problemas. Y aquí también incluyo los módulos que no son contribuidos, sino que son custom, que se ha hecho a medida solo para el desarrollo del proyecto. Y una vez está hecho, ya no se actualiza nunca más. Con lo cual puedes tener módulos hechos a medida, muy viejos, que no están con el código, digamos, limpio, que el código de precado no está eliminado, con lo cual al intentar actualizar a un Drupal 10, te van a salir que esos módulos tienen muchas incompatibilidades. También te digo, si tu web tiene uno o varios módulos custom hechos a medida por alguien, yo te diría que ya se empiecen a investigar si esos módulos son compatibles o hasta qué punto son compatibles con Drupal 10 y empezar a actualizarlos. Para que no sean un bloqueante y que esto no te impida actualizar a Drupal 10. Así que digamos que el calendario sería empezar ya a mirar los módulos hechos custom para tu proyecto, si son compatibles y si no lo son, empezar a modificarlos para que lo sean, y ya en enero o febrero deberías empezar a pensar que tu web debería estar ya actualizada a Drupal 10. Si puedes hacerlo antes, mejor, pero esto, que a principios del año que viene deberías plantearte de que tener tu web actualizada. Y pocos más, no sé si hacer un tutorial, aunque sería raro solo en audio, de cosas a tener en cuenta para actualizar un Drupal 10, en plan un poco paso a paso, pero esto no sé si tiene mucho sentido, aparte que si se busca por internet se encuentra bastante fácil como actualizar. Ah, hay un par de cosas que no he comentado. En Drupal 10 hay un par de iniciativas interesantes que creo que no van a salir ahora en diciembre, pero es bueno tenerlas en cuenta. La primera de ellas es actualizaciones automáticas. Hay una iniciativa que para Drupal 10 se quiere que, sobre todo específicamente para webs pequeñas, o desde mi punto de vista esto tiene sentido para webs pequeñas, no para webs medianas grandes, pero se quiere que se puedan actualizar automáticamente. Que tu web automáticamente se pueda autoparchear, por así llamarlo, auto bajar el código actualizado, y actualizarse de forma automática, sin que haya nadie, no depender de un programador que te lo haga. Esto puede estar bien o puede estar mal, depende del proyecto, depende de cómo de grande sea, y depende, sobre todo si tienes monetización y dependes de que tu web no se rompa en ningún momento. Si es una web pequeña como un blog y no te importa que se actualice automáticamente, y si pasa algo, pues que tu web esté caída pues equis tiempo o equis días, pues nada. Que en la mayoría de casos no debería pasar, pero la posibilidad existe. Si por el contrario tienes una web que por algún motivo es, digamos, la columna vertebral de tu negocio, y no te puedes permitir que la web esté caída, mi recomendación es que no se haga automático, o que se haga automático en un entorno controlado, como puede ser un desarrollo, y que tengas un programador o un equipo de programadores que esté revisando que todo funciona bien, y que después se suba esto manualmente a producción. Pero es igual, todo esto, que hay una iniciativa que en Drupal 10 se quiere que en algún momento se puedan ejecutar actualizaciones automáticas, cosa que como digo es interesante para webs pequeñas. Y al mismo tiempo también hay otra iniciativa, que es el Project Browser, que intenta, digamos, entre comillas, copiar lo que está en WordPress, de que es que alguien no técnico, con una web instalada y con permiso de administrador, puede ir a un listado de módulos de la comunidad, y dar al botón instalar, y eso automáticamente se va a bajar el código en tu web, y vas a tener el módulo instalado. O sea, en definitiva están intentando dar poderes a la gente no técnica para que pueda instalar módulos sin depender de, digamos, una persona técnica que instale el código. Esto puede ser bueno o puede ser malo, como decía antes, depende. Si es un proyecto pequeño que es tú mismo y tú no eres técnico, pues esto es muy bueno. Estamos dando poder a gente no técnica. Pero tiene la inconveniente de que estamos dando poder a que posibles ataques, o sea, temas de seguridad importantes, de que se pueda descargar código instalado en la web, esto puede traer riesgos de seguridad bastante importantes. Y después está el tema de que puede ser gente no muy técnica, que si no sabes lo que está instalando, pues puedes tener webs con muchos módulos instalados que realmente no se están usando, y que esto puede afectar gravemente al rendimiento de la web. Al final, yo veo bien que estas dos iniciativas estén. Si en tu caso de proyecto no tiene sentido que estén, pues no se activan, no se usen y ya está. Y para, digamos, los proyectos más simples, o digamos, lo que puede ser competencia de web, esto, webs más simples enfocadas a gente no técnica, tiene todo sentido del mundo intentar abrir mercado y que en Drupal llegue a ese tipo de gente. Y, como digo, en Drupal 10 se está intentando ir hacia esa dirección, cosa que en Drupal 9, en Drupal 8 se intentó en plan de, no, no, vamos a hacer webs más especiales para gente más técnica, y se han dado cuenta de que funciona bien, pero es un mercado muy nicho, muy pequeño, aunque se mueve dinero, pero es un mercado relativamente pequeño, comparado con webs de tipo WordPress, que al final es gente no técnica, que en muchos casos no quiere programar un programador, y se lo quiere hacer ella misma. Pero nada, eso, que las novedades de Drupal 10 pintan muy bien, y que ya veremos estos próximos meses qué problemas pueden surgir, y si la comunidad, con todos estos cambios que se están implementando, la comunidad deriva hacia gente no tan técnica, y si gracias a esto Drupal se empieza a usar más de lo que se está usando ahora mismo, que ojalá sea así. Y nada más, hasta la semana que viene. Chao.

¿Tienes algún proyecto en mente?

Si quieres hacer algo en Drupal tal vez puedas contratarme.

Ya sea para consultoría, desarrollo o mantenimiento de sitios web Drupal.