Settings.php, módulos y configuraciones twig de un Drupal en producción

 Hola, ¿qué tal? Aquí otra semana más en Drupalizate. Como comenté semana pasada, he acabado con el tema de casos reales, al menos el de PodcastBeddy, y hasta que no acabe o tenga algo que contar sobre el nuevo proyecto que quiero empezar en septiembre, pues el tema de casos reales de momento queda parado, a menos que algún cliente me deje contar alguna interioridad de su proyecto, cosa que normalmente no pasa. Y por eso yo contaba proyectos míos propios. Dicho esto, como nadie me ha dado ideas de temas de los que hablar esta semana, voy a hablar sobre una chorrada, pero que mucha gente hace mal, y que no cuesta nada tener un checklist cuando subas estas cosas a producción para no liarla. Y hoy toca hablar de configuraciones en el settings, configuraciones de tweak y desarrollo, y temas de módulos, o sea, qué módulos no deben estar activos nunca en producción. Como digo, es una chorrada, es una cosa básica, pero que me sigo encontrando bastante web en producción, o sea, me llegan algunos clientes de temas de rendimiento, es que la web me va lenta, y lo primero que mido es qué modos están activados, cómo está el settings, y cuatro cosas más, pero que las más típicas, en muchos casos, siguen fallando. Y esto es que me peta la cabeza, no entiendo cómo hay gente que pueda hacer esas cagadas tan simples y subir esto en producción. Así que empezamos. Primero de todo, lo más simple, módulos. Qué módulos no deben estar nunca activados en producción. Hay unos cuantos, pero digamos que hay dos vertientes. Una, módulos de desarrollo, como puede ser el módulo Devel, por ejemplo, o el módulo Kint. Son módulos que tienen todo sentido estar en local, pero nunca deberían estar en producción. El problema con esto, que hay gente que cuando están en local los activan, y cuando exportan la configuración, se exporta de que ese módulo ha de estar activo, y cuando suben la configuración a producción y la importan, pues básicamente están activando esos módulos, lo cual es una cagada. Para arreglar esto se usa el módulo config-split, y en el módulo config-split se especifica que sólo en x entornos quieres tener x módulos, como puede ser el Devel, sólo en local, y como mucho en un servidor de desarrollo, si es que debería estar en desarrollo, que yo creo que ni eso, sólo en local. Es una forma de especificar con el config-split qué módulos quieres y cuáles no, en qué entornos. Como digo, me sigue sorprendiendo la de gente que tiene el Devel o el Kint activados en producción, y afectan al rendimiento. No es quizá lo peor, pero sí que afecta bastante al rendimiento, y no de bienestar, porque también es un riesgo de seguridad alto tenerlos ahí puestos. Después están los módulos que no son de desarrollo, pero que sí que son que permiten modificar configuraciones. Y aquí digamos que son los módulos de interfaz, los UI, por ejemplo el views UI, el field UI, son módulos que teniendo activados te permiten que los usuarios, con ciertos permisos, puedan editar partes de la web de configuración. Pues editar las views y cambiar el orden, añadir campos, o que la configuración de un campo de un nodo, por ejemplo, pues cambiarle el label, o añadir un campos, o eliminar campos, son módulos que, para depender de qué webs quizá no te bien, no hacían falta tenerlos en producción. Piensa que cuantos más módulos tengas activados en una web, más lenta va a ir. A ver, si tienes en vez de 10, tienes 12, pues no notas la diferencia, a menos que el módulo esté muy mal hecho y sea un una patada por rendimiento. Pero lo normal es que no se note mucho. El problema es que si en vez de tener 20, tienes 60, pues hombre, pues de 20 a 60, y depende de qué módulos sean, pues se puede notar mucho en temas de rendimiento. Por eso había una recomendación de no tengas activos los módulos que no te hacen falta en ese entorno. Y aquí vienen los módulos de estos, los de UI, que en muchos casos en producción no hay ningún usuario con el rol modeador o administrador que pueda tocar configuraciones. Es más, no deseas que ningún usuario pueda tocar configuraciones de este tipo en producción. Todos estos cambios se hacen en local, se exporta la configuración y se importa. Como digo, esto depende de casuísticas de clientes. A lo que voy es, estos módulos pueden tener su excusa para estar en producción, en muchos proyectos pequeños pueden estar, no hay ningún problema, pero tener el developer o el gint no es excusa y no se debería tener nunca en producción. Y me lo siguen contando en muchos sitios. Así que el tema de módulos, te remarco estos dos básicamente, porque son los que me encuentro más. Después, temas de el settings. El settings local y el settings PHP. Tenemos dos, settings.local.php y settings.php. ¿Por qué tenemos dos settings en Drupal? ¿O por qué deberías tener dos settings distintos en Drupal? Al final Drupal es un CMS, funciona en PHP y dentro de sites.default tenemos un fichero de configuraciones, de las configuraciones básicas. Un fichero php, settings.php con las cuatro configuraciones que tocarían. En verdad no son cuatro, son unas cuantas más, pero si no, o sea, si dejas las que vienen por defecto y modificas las que te hacen falta a ti, al final son cuatro. La típica es por ejemplo el hash del cron. Cuando haces una instalación se genera ese hash. Después, por ejemplo, el directorio donde se guarda la configuración cuando haces una exportación o la importación donde espera Drupal que haya la configuración que se exporta para después importarla. Estas configuraciones como hash o el directorio o el directorio privado, por ejemplo, de ficheros, digamos, son configuraciones que son idénticas en cualquier entorno. Por el final es la misma web que tienes copiada en producción, en pre-producción, en desarrollo, en integración y en cada entorno local de cada programador que trabaja para este proyecto. Hasta aquí bien, con lo cual tenemos el settings.php que es común para todas las webs y con las mismas configuraciones que tienen que haber en todos los entornos. Pero puede haber entornos que no tengan la misma configuración exacta y el caso más típico es la base de datos. Podemos tener una base de datos con un usuario de contraseña o directamente un host. En un caso tenemos que es MayaDB en un Docker y en producción no usamos Docker y no es MayaDB, directamente la conexión con el MySQL y el usuario de contraseña también es distinto. Al final cada entorno puede tener o normalmente tiene un usuario de contraseña y una conexión distinta a base de datos. Así que por eso es bueno tener un fichero settings.local para que cada entorno tenga el suyo y lo puedes modificar y que esto no se incluye dentro de git y que cuando mueves el código de un lado a otro de entornos no se sobrescriba el settings.local y no estés cambiando la configuración, por ejemplo, la base de datos, porque si no te rompería el sitio cada vez que copias el código de un sitio al otro. ¿Qué cosas más aparte de la típica de base de datos? En local, sobre todo, cuando estás en... cuando me refiero local es en desarrollo de... o sea como programador, cuando tienes una copia en tu ordenador para toquetear la web, el típico es desactivar las cachés, desactivar la compresión de CSS, desactivar la compresión de JavaScript. Puedes también especificar qué fichero services que hayamos a este punto para temas de cachés de tweak y también, por ejemplo, si usamos reddit o memcache, esto se puede especificar en el settings general o en el settings local si quieres de que sólo esté activo en producción, por ejemplo, porque reddit y memcache en tu local no lo tienes y en producción sí. Pero al final, ¿por qué he comentado de que tener en tus settings local el desactivar cachés y desactivar compresión de CSS y JavaScript y no hacerlo por interfaz de usuario? Porque en<|vi|><|transcribe|><|vi|><|transcribe|><|cy|>, en tu local no lo tienes y en producción sí. como administrador vas a la página por... o sea, dices navegador por interfaz de usuario y le das al checkbox y le das a guardas y desactivas las cachés y desactivas la compresión. Esto he visto gente bastante que lo hace. El problema es que después te olvidas, expostas la configuración, la subes a producción, impostas la configuración y estás activando o desactivando lo que tenías en tu local. Con lo cual al final acabas en producción con una configuración que es la de local, teniendo el módulo de level activado como he comentado antes y teniendo las cachés desactivadas y teniendo la compresión de CSS y JavaScript desactivada. Cosa que también es muy mala por temas de rendimiento en producción. Así que yo recomiendo que la configuración de interfaz sea la de producción y que en tu local si te hace falta, desactives la caché y desactives la compresión de CSS y la compresión de JavaScript desde el settings.local.php. O sea, básicamente es sobreescribir la variable. Doppel es muy fácil sobreescribir configuraciones específicas directamente desde el settings. También puede ser muy útil, por ejemplo, sobreescribir la configuración del ID que se usa en Google Analytics o cualquier otro módulo que uses. Tú, por ejemplo, quieres que en tu local el ID de Google Analytics esté vacío y que no se envíen estadísticas a tu Google Analytics cuando estés toqueteando en tu local o en desarrollo. Solo quieres que Google Analytics esté en producción. Pues una forma es que el ID en tu local o en desarrollo no sea un ID correcto. Y digo ID de Google Analytics como puede ser cualquier otra cosa de cualquier otro módulo. Que no te interese que estén enviando datos o que se esté conectando a entornos de producción. Y básicamente que sigo viendo mucha gente que no que lo metió todo en el settings.php. Después ese settings lo excluyen del git porque claro tiene que ser un setting distinto por tema, por ejemplo, la base de datos. Pero claro, en local tenemos una configuración en settings distinta que es lo que está en desarrollo que es lo que tenemos en producción y después pasan cosas como que al cooperar de un lado al otro, pues en un sitio tenemos redis pero revienta porque la configuración no es la misma que teníamos en otro sitio. Por favor tengamos un settings.php unificado donde está todo, las configuraciones que tienen que ser siempre las mismas y las cuatro cosas que han de ser distintas en el settings local. Y ese ya no se toca. O lo tocas en tu local si te hace falta. Pero me refiero de que cada entorno tiene su ID y en producción básicamente solo se da el de base de datos y como mucho si quieres activar redis o me encache. Y es que ya está, realmente no hace falta nada más. Y por último sería el tema del el services. Lo digo de memoria, el development.services.yaml que está dentro de sites. No sites default sino sites. Es un fichero que viene por defecto. Digamos que básicamente especifica el backend de las cachés, o sea el backend null de las cachés. O sea se usa después en el settings si quieres desactivar específicamente tipos de caché en concreto. Y aparte de esto sirve para especificar, o sea lo puedes modificar y especificar de que el tweak no tenga las cachés activas, tenga el autorreloj activo que es para que automáticamente intente detectar cambios y mostrar siempre la última versión. Y después el tema del debug de tweak. Que básicamente es que en el HTML que escupe el Drupal esté lleno de comentarios diciéndote de que este fragmento del bloque de tal sitio de HTML se está generando desde este tweak, desde esta plantilla tweak que está en tal directorio. Por ejemplo en el modulo del code que es el que gestiona los campos por ejemplo. Y se está usando esta plantilla que es el tweak que tiene el nombre field tweak. Y te da sugerencias de nombres. O sea al final tener el debug de tweak activo en local, en local, es realmente muy útil. Te ahorra mucho trabajo. Y cuando digo el debug me refiero a lo de en los comentarios y el tema de cachés de tweak desactivadas para no estar en tu local vaciando cachés cada vez que haces cambios del frontend. Y el autorreloj también para no obligarte a tener capacidad de cachés, para que detectes cambios. Esto tiene todo sentido en el mundo, repito, en local. Para facilitarse la vida y desarrollar mucho más rápido y al final al cliente, a quien tú le cobras, le vas a cobrar menos porque tus tiempos de desarrollo son menos. Porque te cuesta menos trabajo hacer cosas en frontend. Es menos engorroso trabajar en Drupal en local de esta forma que no cualquier chorra que cambies en los tweak tener que vaciar cachés. El problema es que últimamente, no sé qué pasa, que me encuentro que esta configuración de local está en producción y tener el debug de tweak activo en producción es malísimo para rendimiento. O sea la web va mucho más lenta. Y se suma de que en muchos casos tiene el debug con el tema de comentarios activo y cualquier persona que vea la web inspeccionando, o sea desde el navegador, botón derecho, inspeccionar HTML, están viendo los comentarios. Eso significa que estás viendo la ruta interna de cualquier plantilla de tweak, de dónde está, si es un módulo custom, si es un módulo contribuido, si es dentro del tema, y un poco las rutas internas del servidor. Cosa que por rendimiento tampoco es muy bueno. Así que yo recomiendo mucho que cada vez que se suba algo a producción, o sea, no cada vez, cada vez que se suba la web a producción, revisar lo del tweak, está desactivado, vale, sí, lo que tenemos en local solo está en local, no acaba estando en producción. Porque realmente me sorprende la de gente que me ha contactado por temas de rendimiento y lo primero que mido es, vale, pues que lo del tweak lo tengo que desactivar, o sea, no tiene ningún sentido que esto esté en producción. Me huelo que es porque la web cuando se desarrolló, se desarrolló con todo esto y se subió, o sea, se copió, pegó, todo en producción, se desplegó y ya está. Y la agencia o freelance que hizo la web, como ya ha cobrado y la web ya está subida, pues ya está, y como cliente final estas cosas no las sabe, solo sabe que la web va más lenta de lo que debería o de lo que le gustaría a él. Y, ¿qué más comentar de esto? Creo que ya está. Lo del tweak, no hay point interface nada, o sea, es todo desde código y en muchos casos la gente novata no sabe que tú puedes desactivar las caches de tweak y tener el debug de tweak activo. La gente novata me refiero a junios que entran en el mundo de Rupal porque vienen de otras tecnologías. A lo que voy es que si esto está desactivado es porque han visto algún tutorial o es un senior y sabe que esto se puede hacer y lo hacen en local. Lo que me cabrea es que esto lo suban después de producción. Porque como digo, por defecto, Rupal no viene con esto activo. Lo has activado tú, manualmente, tocando código en ficheros de configuración. O sea, no es fácil de activar, es fácil de activar pero has de saber cómo se activa. No es de esa interfaz un checkbox de desactivar tweak. Y nada más, que básicamente, creo que hoy ha sido un día de rabieta porque justamente en una actualización de un proyecto es que me lo he encontrado. O sea, tenemos que actualizar de un topal 8 un 9. Y vale, he actualizado esto y aparte me ha salido esto. No tiene las caches activas, no tiene el CSS y el JavaScript de compresión activo, tiene el debug de tweak activo y tiene el módulo Devel y aparte es actualizado con el Kint, la versión antigua, que después se separa como módulo independiente y rentaba. No me sañé que la web vaya lenta, para empezar porque un topal 8 con mucha mierda. Pues que aparte, aunque fue un topal 9, te tengo que poner una configuración decente para que el rendimiento no sea una patada, para que el servidor vaya lo más suelto posible. Porque al final con pocas visitas se te cae la web normal y aparte tienes código custom. Bueno, y nada, creo que hoy ha sido un episodio más tipo rabieta y no sé de qué voy a comentar la semana que viene. Así que no sé, si me das alguna recomendación hablo del tema y si no, me buscaré algún tema así en plan rabieta como hoy. Nada más, buen fin de día, chao.