Modificar código de los módulos y themes contribuidos de Drupal

 Bienvenido o bienvenida aquí otra semana más a Drupalizate, donde yo, Robert Menetray, te cuento cosas que hago con Drupal, ya sean cosas buenas que me han pasado o cosas malas, o buenas prácticas que deberías seguir para hacer tus proyectos en Drupal. En este episodio en concreto, el de esta semana, quiero hablar sobre buenas prácticas para modificar temas o módulos contribuidos o directamente el propio core de Drupal. Esto viene a petición de un usuario, o sea, una persona que escucha ese podcast, igual que tú, que me contactó por LinkedIn y me dijo, mira, creo que es buena idea que hagas el tema este porque creo que no lo has comentado en ningún otro episodio. Y yo fue, pues no, es verdad, no lo he comentado y creo que es un buen tema a tener en cuenta. Dicho esto, igual que esa persona me ha contactado por LinkedIn, tú, si me escuchas, me puedes contactar desde mi web, minetrai.com, en la formularia de contacto, o si no, pues LinkedIn, me buscas por mi nombre, o en la newsletter que envío desde LinkedIn, también me puedes comentar allí en la newsletter. Esto, en LinkedIn, o de forma privada, en el chat, o, o sea, un mensaje privado, o en la newsletter mismo. Dicho todo esto, esa persona me dijo esto, de teniendo un módulo contribuido o un tema contribuido, cómo los puedo modificar. Y yo voy a añadir aquí en medio de no solo módulos y temas, sino también el propio core de Drupal, porque en algunos proyectos me he encontrado que han modificado el propio código base de Drupal. Primero, como quiero que este episodio sea lo más básico para gente que no sabe de Drupal, o cómo funciona la comunidad de Drupal.org, intentaré explicar un poco las bases. Primero de todo, Drupal tenemos Drupal.org, que es la web oficial donde se sube todo el código de Drupal, tanto el core, como los módulos contribuidos, como los temas contribuidos. Vale, dicho esto, ¿qué es un tema contribuido y un módulo contribuido? La comunidad de forma altruista, es gratis todo esto, la gente sube su código allí. Han hecho un módulo que hace X funcionalidad, y yo qué sé, pues te añade un botón de compartir en Facebook, por decir algo, o lo que sea, cualquier cosa que hayan hecho interesante. Yo, por ejemplo, tengo algunos módulos de temas de E-commerce que puse en su día, cosas de estas. Al final es, por algún cliente o por algún proyecto que has tenido, has tenido que hacer un módulo y aprovechas para hacerlo ya bien y subirlo a la comunidad, y que otra gente pueda aprovechar este código ya hecho. Pues eso, que lo suben, tanto para módulos como para temas. Has hecho un tema, aquí viene un poco el tema de si el cliente te permite subirlos en la comunidad y que todo el mundo pueda usar ese tema, que normalmente no, y aparte los temas son muy hechos a medida y no siempre se pueden compartir en la comunidad. Lo que sí que es verdad es que en Drupal.org hay muchos temas que se usan como tema base, ¿vale? Como por ejemplo tenemos el bootstrap, que es uno de los más conocidos. Así que voy a empezar con el tema de modificar temas contribuidos, porque conceptualmente es la parte más fácil de entender y la que mucha gente hará empezar por aquí. Pues vale, tenemos en tu local un proyecto en Drupal, te has bajado un tema, pongamos por caso el tema bootstrap, que es uno de los que más se están usando, y pues motivos que sean, quieres modificar el color, por ejemplo, de no recibir lo que hay, pues quieres modificar el color o poner algún padding o margen o algo así, algo digamos muy simple de momento. ¿Cuál sería la mejor forma de modificar el tema bootstrap? O mejor dicho, tener un tema que use bootstrap pero con tus modificaciones. Digamos que la más fácil y que en algunos casos he visto es coger el tema bootstrap y lo modifica hasta lo cual hay medio. A corto plazo es una opción de por funcionar funciona. El problema es que a mediado plazo o largo plazo el mantenimiento es una pesadilla, ¿vale? Cuando se modifica un tema contribuido, o sea un código contribuido por alguien más, lo estás modificando y vas a subir a producción ese código modificado. Si de aquí a un mes, dos meses, medio año actualizas el código porque por temas de seguridad o por temas de funcionalidades, pues Drupal 8 y por ejemplo A cada pecado tenemos que pasar a Drupal 9, o el tema bootstrap pues se detecta un bug de seguridad que en su día hubieron unos cuantos años atrás y tenías que actualizar porque por temas de seguridad o por temas de rendimiento. Si tú tienes el código modificado, cuando actualices vas a perder las modificaciones que tú has hecho. Así que tenemos que tener alguna forma de que esas modificaciones que tú has hecho no se pierdan durante el tiempo. Así que lo de modificar directamente el código en plan picando fuego el código, ahí en medio, no, ¿vale? Es mala práctica, muy mala práctica. Me lo sigo contando en algunas webs pero que evítalo, por dios. La segunda opción sería hacer parches. Hacer parches significa en la comunidad, en todos los módulos y temas hay un apartado donde se discuten las issues del módulo o del tema que básicamente se ha detectado un bug pues yo puedo abrir una issue en este módulo o en ese tema y decir he detectado que cuando navego como usuario o yo que sé, administrador, esto no me funciona como toca o el permiso que activo aquí no se aplica allí. Bueno, pues abres una issue y explicas qué está pasando y si es programador y te ves capacitado o ves cuál es la solución puedes subir código, ¿vale? Y eso es un parche. Un parche es un fichero.patch que ahí especificas pues en esta línea de código con símbolos de menos y más, especificas que estas líneas se eliminan y estas líneas se añaden a este fichero. De forma muy simplista es esto. Al final digamos que esto se genera desde la línea de comandos o desde el IDE de programación que tengas tú, o sea no lo haces picando código a mano, creando el fichero.patch a mano, pero para que se entienda es un fichero muy simple donde salen las líneas a eliminar y las líneas a añadir en el código. Con lo cual si por ejemplo en el tema del bootstrap lo que quieres es añadir o modificar una plantilla puedes crear un parche que añada o modifica una plantilla twiq de ese tema bootstrap. Bueno o malo, pues cuando te actualices si los cambios no son muy distintos en la actualización el parche se va a aplicar automáticamente. Con lo cual en las actualizaciones los parches primero se intentan aplicar automáticamente y si no fallan pues ya está, todo perfecto. Y si fallan te saltarán la consola de que ha fallado algo y tendrás que ver si este parche lo tienes que modificar o si la comunidad ya lo ha incluido dentro del tema original y ya no hace falta aplicar parche o si por el contrario ese parche no ha sido incluido pero con las modificaciones deja de ser válido y tienes que aplicar un parche distinto porque normalmente la comunidad se da cuenta de esto y al cabo de un tiempo se sube un parche, una versión nueva del parche para que funcione con las últimas versiones de ese modulo o de ese tema. Y si no lo puedes crear tú mismo, eso suponiendo que sepas unos conocimientos mínimos de programación y que no tengas miedo a tocar código y que entiendas cómo funciona el código porque bueno, creo que es lo lógico vamos. Dicho esto, de momento hemos hecho, bueno, lo modificamos a mano, mejor que no, en vez de modificarlo a mano creamos un parche para que lo aplique automáticamente y tenemos al final los parches. Sabemos qué parches hay y en qué módulos o temas se aplican así que está todo más ordenadito y a seis meses vista cuando toca actualizar una web o cuando otra persona que no es tú que haces arreglar esta web a alguien más le toca actualizar, verá qué parches hay y en qué afecta y la actualización va a ser mucho más fluida, mucho más rápida y mucho más barata sobre todo. Y en los temas en concreto hay la opción que yo recomiendo más que es hacer un subtema. Suponiendo que no es un bug de seguridad ni es un bug digamos, íntegro del tema base sino que es un que es cambiar colores o que es añadir plantillas que el tema base no tiene, lo lógico sería hacer un tema custom tuyo y en el punto info de tu tema especificas de que el tema base por ejemplo es bootstrap, vale, con lo cual solo con el tema custom y el fichero de info estás cargando el tema bootstrap sin nada más, veías exactamente lo mismo en tu web, pero si especificas ficheros de plantillas nuevos o ficheros JavaScript o fichos CSS se van a añadir a los que ya está cargando bootstrap, en este caso el tema base por detrás. Esto significa de que puedes añadir o modificar o mejor dicho, es decir, suscribir plantillas existentes en bootstrap poniéndolas en tu tema y modificándolas y cuando actualices bootstrap se va a actualizar solo bootstrap pero tu tema custom no, seguirá machacando las plantillas que tenías en bootstrap pues si has modificado la plantilla de el nodo o la plantilla de no sé qué campo se va a mantener, o sea, no lo vas a perder esos cambios cuando actualices los códigos de los temas. Yo recomiendo esto y temas de CSS y JavaScript, por ejemplo en el tema 7, el de administración, en alguna web ha pasado que en los formules de edición de los nodos pues por cosas de ese proyecto en concreto digamos que salían cosas un poco desmaquetadas que falta poner un board, un padding y un margin y poca cosa más. Puedes crear un subtema que extienda al tema base 7 y poner un CSS que son cuatro líneas de pues en este campo, en este formulario se le pone un margen o un padding o lo que sea. Total, que el tema custom tuyo carga todos los ficheros del tema 7 porque es el base y después añade un fichero CSS que es el tuyo custom y por las clases que tú has puesto en el CSS va a sobrescribir visualmente cómo se ve la web en el navegador. Como digo, mi recomendación en temas es usar siempre que puedas temas custom que extiendan el tema base. Que parece que al principio son cuatro chorras de solo modificar un CSS y tal, normalmente ya que estamos pues también en el JavaScript y ya que estamos, añade estas dos plantillas y siempre en proyectos más o menos grandes y que hay cosas custom acostumbran a no ser un par de cosas tontas sino que acaba creciendo. Así que yo recomendaría siempre como temas custom extiendo el tema base y en cosas muy concretas sobre todo si son de la comunidad y la comunidad ya ha dado un parche pues puedes aplicar los parches. Así que para los temas básicamente me recomiendo seríz esta. Después temas de en el código. En el sentido de que tenemos un Drupal y que por X motivos hemos modificado ficheros del propio Drupal. Ya no de temas o de módulos contribuidos por la comunidad sino el propio código base de Drupal hay gente que lo modifica para meter PHP por el medio para que haga sus cosas. Esto muy mal. Mejor hacer un módulo custom y que haga tus funciones que no modificar el tema contribuido o el tema base del tema del core. Perdón el tema, el código del core de Drupal. Si aún así por motivos X tuvies que hacerlo o porque se ha detectado un buco o lo que sea se debería aplicar con parches. Igual que con los temas tú puedes aplicar un parche directamente al core. Por ejemplo yo tuve que aplicar un parche no hace demasiado hace un par de meses creo que fue en una migración que se usaba Migrate porque había un bug en el módulo Migrate y el módulo Migrate está dentro del core de Drupal. Total que se aplicaba un parche al core porque el Migrate está incluido en el core. Pues estas tonterías son parches que ha hecho la comunidad y que se van a incluir en X versión nueva del Drupal pero hasta que esa X versión no sea estable y se publique en tu web tienes que aplicar un parche para solucionar esos errores. Total en el core se aplican parches. Pero no lo modificas a pelo porque me he encontrado gente que modifica a pelo cosas en el core y eso cuando actualizas después revienta la web. Hemos visto temas hemos visto core ahora queda los módulos ¿Cómo modificar módulos contribuidos? Los módulos y también puedes aplicar parches que también sería una opción recomendada sobre todo si son bugs que la comunidad sabe lo mismo que con el core si la comunidad ha descubierto que hay un bug se ha creado un parche y aún no está estable como para añadirlo a la versión del módulo publicada en tu parodaje o porque la persona que contribuye al módulo no ha tenido tiempo de revisarlo o incluirlo en el código de la rama master. Al final tú puedes poner el parche y aplicarlo en tu proyecto. Por cierto los parches siempre se deberían aplicar en la rama de desarrollo en la versión de desarrollo del módulo o del tema. Algunos se pueden aplicar en la versión estable pero puede ser que el parche te de error porque la versión estable y la de desarrollo no siempre coinciden. El código puede tener modificaciones porque la versión estable es de hace dos meses y la versión de desarrollo es de hace un mes y tiene cambios. El parche siempre se aplica sobre versiones de desarrollo. Dicho esto, con módulos pues aplicas un parche y ya está. Eso soluciona tu bug. Pero en el caso de que sea código tuyo custom que hace cosas tuyas de cliente de la funcionalidad que pide es hacer X cosas por ejemplo una cosa que hice yo en un proyecto mío que creo que lo comenté que fue en webcaster que cuando el módulo flags que es un módulo contribuido yo lo puse en el Drupal yo que llegue al hacer que la gente al hacer clic en el flag hace o sea marcase como favorito X contenido de X nodos Drupal internamente hiciese cosas como enviar mails por ejemplo o hacer comparativas de si puede el usuario hacer o no X acción. Esto lo podría haber hecho modificando el módulo flags o podría haberlo hecho haciendo un parche para módulo flags pero la opción buena en este caso más que hacer un parche fue hacer un módulo contribuido que usa los eventos o los hooks del módulo flags. No todos los módulos lo tienen pero los módulos más o menos importantes o más o menos grandes tienen sus propios hooks o sus propios eventos a los que puedes digamos disparar acciones en Drupal para que tú después en tu propio módulo custom en tu propio código custom en el módulo puedes hacer ciertas cosas en este caso cada vez que alguien marcaba un flag o sea añadía el nodo al flag que había en mi código custom se detectaba eso y hacía X cosas como por ejemplo enviar mails. Total en los módulos siempre que se pueda debes tener un módulo tuyo custom y hacerlo vía hooks o vía eventos o lo que te permita el módulo que quieres extender por otro ejemplo el tema de migraciones en Drupal 8 y 9 las migraciones que son con el módulo migrate que es el módulo que viene en el code en Drupal casi nunca o muy pocas veces hace falta tocar código PHP en casos muy contados y muy hechos a medida pero normalmente con configuraciones punto yamel o sea tienes un fichero yamel donde están las configuraciones de las migraciones ya te sirve al final es que da un módulo custom tuyo donde sólo hay archivos yamel que son las configuraciones que el migrate va a usar después para pues añadir las migraciones de Drupal. A lo que voy es que depende del módulo unos serán hooks otros serán eventos otros sólo son fichos de configuración depende un poco de cada módulo por eso al final el tema de hacer código custom en módulos es un poco más complejo que en temas pero igualmente casi nunca o en pocos proyectos hace falta código custom en módulos o sea en proyectos muy grandes y muy hechos a medida pero en proyectos pequeños y medianos casi nunca entonces falta tocar un módulo o módulo custom y nada creo que más o menos espero que haya quedado claro a finales evita tocar código y meterlo todo en githy y ya está siempre que puedas o por parches o haciendo un módulo custom o un tema custom y extendiendo a los contribuidos existentes vale es mejor que un parche pero que en varios casos pues por temas de que hay un bug que se ha detectado o lo que sea pues es mejor aplicar el parche vale aquí un cosa que no comentado cómo se aplican los parches los puedes aplicar por ejemplo en tu local tienes una idea de programación como yo tengo un parche piston pues tiene una opción de aplicar parches tal cual lo puedes hacer también desde línea de comandos vale te descargas el fichero y pues por línea de comandos haces que el parche se aplique en dupal la mejor opción al menos desde mi punto de vista porque queda todo más ordenadito ya que en dupal se trabaja en dupal 8 9 se trabaja con fiche con composer en el fichero del composer especificas de que tienes estos parches y que este parche es de este módulo este parche es del del core de dupal y que este parche es de este tema vale específicas en cuatro líneas que partes son de qué partes del dupal si es un módulo un tema y el nombre del módulo o el nombre del tema cuando haces un composter install lo que hace el dupal es vale me bajo el código de contribuido de la gente en dupal o rg y después intento aplicar el parche si el parche lo aplico correctamente pues perfecto si el parche no se puede aplicar por x motivo el composer te va a mostrar un error de que no se puede aplicar el parche y no se puede instalar el módulo total yo recomiendo que los parches se apliquen desde composer primero porque queda por escrito qué parches están puestos y en qué módulos y segundo porque es muy fácil gestionarlo vale sobre todo para actualizaciones y además también depende cómo trabajes lo normal sería que en producción o en pre producción o en cualquier entorno no tengas el código de los módulos contribuidos en git cuando subas o hagas un despliegue en un servidor composer se bajará todos los módulos y aplicará los parches correspondientes así que evitas tener todo el código contribuido en git sólo tienes el código que es tuyo propio código custom es una forma de trabajar que se recomienda trabajar así en dupal en proyectos míos propios en algunos lo tengo en otros no por temas de que el hosting pues no tiene composer y no se puede hacer despliegue de esta forma pero una cosa ten en cuenta que muchos proyectos la forma recomendada es todo por composer y composer automáticamente se baja todo el código y después aplicar los parches correspondientes y ya está y nada más espero que con esto solucionan las dudas si no ha quedado claro del todo me lo comentáis como he dicho por LinkedIn o en mi propia web e intentarse algo un poco más detallado porque al final esto es audio no se puede compartir pantalla y digamos que al final es para que sepas cómo funciona estas cosas si te interesa de verdad ya teniendo un poco estos conocimientos puedes buscar mejor por google de a vale que es aplicar parches por composter en dupal y ya te va a salir cómo aplicar esto vale es un ejemplo tonto pero finales creo que es mejor es más útil saber que esto existe más que los pasos exactos para cómo se hace y nada más que me alargo como siempre hasta semana que viene y cualquier cosa me contactar por LinkedIn o desde mi web menetray.com chau y gracias por escucharme.