¿Qué es Drupal?¿Competencia de Wordpress?

Bienvenido o bienvenida a este primer episodio del podcast Drupalizate. En este primer episodio intentaré responder la típica pregunta de qué es Drupal, para qué sirve, es lo mismo que webcast o atacan al mismo tipo de cliente o de público objetivo. A ver, este tipo de preguntas me han hecho dos tipos de personas distintas. La primera es cuando yo intento explicarle, cuando alguien me pregunta a qué te dedicas y digo hago webs, y uy pero webs esto es muy genérico, y digo vale hago webs en Drupal específicamente. La siguiente pregunta es qué es Drupal y digo justamente por eso no te he dicho que las hago con Drupal porque ahora tengo que explicar qué es Drupal. A una persona que no es técnica, que no sabe nada de tecnología y que tampoco me aporta nada a explicarle. Pero bueno, de explicárselo a vaya gente, al final se me ha quedado algo. Y el otro tipo de personas son clientes que realmente no sé cómo llegan a mí y me dicen de yo quiero una web. Y vale sí, pero qué tipo de web, porque yo trabajo con Drupal. No, es que me importa un carajo, me importa un pimiento en qué tecnología, yo quiero una web. Vale, porque quieres que te haga la web, porque en algunos casos no tiene sentido hacerlo con una tecnología que realmente no es para este caso de uso. Porque se le ha de dedicar más tiempo, se le ha de dedicar más dinero, o sea tendrá mayor coste básicamente. O que realmente hay cosas que no se pueden hacer o que son más complejas de hacer. Por poner un ejemplo, si quieres una página básica, una landing page, no tiene sentido hacerla con Drupal. Si quieres un sistema con varias landing pages, pues aquí ya podemos hablar, por ejemplo. O si quieres un blog, depende de cómo te salgas la cuenta, montar un WordPress. Bueno, volviendo al tema que me ha ido por las ramas. ¿Qué es Drupal? ¿Cómo se definiría? Tenemos que empezar por lo que es un CMS, que supongo que si has llegado aquí es que algo sabes. Pero para quien no sepa, es un Content Management System, o sistema de gestión de contenidos, sería la traducción al español, hablando en cristiano, gesto de contenidos. Y básicamente, WordPress y Drupal son un gesto de contenidos, o se consideran como gestos de contenidos. Y a medias, ¿y quién es un gesto de contenidos? Un gesto de contenidos, de forma muy resumida, se podría decir que es un sistema, un código, que se instala en un servidor y te da ya una web hecha. Pero para que se considere como un gesto de contenidos, esta web tiene que tener, digamos, unas funcionalidades mínimas. Estas funcionalidades han de ser, primero, que permita hacer login a usuarios y registrar usuarios. Que estos usuarios tengan permisos o roles de usuario para gestionar qué cosas pueden hacer y qué cosas no. Por ejemplo, tener un usuario que puede comentar en los artículos del blog, o tener un usuario que pueda editar o crear contenido en la web, o tener un usuario administrador que pueda instalar o cambiar configuraciones de la web. De momento estoy hablando como gestión de usuarios, pero la parte importante, que es lo que da nombre al CMS, es gestión de contenidos, no de usuarios. Y básicamente, los usuarios que se han dado de alta tienen acceso a editar, por ejemplo, contenidos, a crear contenidos. Que básicamente es, la web te sale un formulario, le das a editar, vas al formulario, pones los textos, imágenes, lo que toque, le das al botón de guardar y la misma web ya te ha publicado una URL bonita, con un texto, una imagen. Y el usuario no tiene ni idea de programación, pero ¡anda! Mira, puede gestionar una web él solito. Eso es un gesto de contenidos. Como digo, WordPress es un gesto de contenidos, Drupal depende, la definición oficial, digamos que sí, que también es un gesto de contenidos, aunque por ejemplo, yo estoy un poco allí de que sí, pero no. Y hay gente que también comparte mi opinión de que Drupal, más que un gesto de contenidos, es un CMF, o sea, no con S, sino con F, de framework, que es Content Management Framework, lo que sería, como sería la traducción, un framework de gestión de contenidos. Que básicamente, digamos, que es una base de código, que también te da lo mismo que un gesto de contenidos normal, gestión de contenidos, o sea, permite editar páginas, permite crear usuarios, gestión de permisos de usuario, pero aparte de esto, digamos que es más básico que al instalarlo, no te da todo ya hecho, que es mucho más configurable que un gesto de contenidos al uso y que también es mucho más flexible. Te permite, a partir de esta base, construir casi cualquier cosa. O sea, básicamente puedes construir tu propio gesto de contenidos. Con lo cual, ya estamos viendo que por esa descripción, Drupal es mucho más flexible, mucho más configurable, puedes hacer muchas más cosas que con WordPress. También, de la misma forma, Drupal es mucho más complejo que WordPress. Eso significa también, por desgracia, que Drupal es bastante más caro que WordPress. O sea, hacer una web en Drupal, seguramente, te va a salir más caro que hacer una web en WordPress. Y hasta aquí, me dias, bueno, pues como cliente, pues no quiero Drupal. No tiene sentido si me va a salir más caro. Aquí también me quiero añadir un par de datos. Hay un par de estadísticas, o un par, no unas cuantas, pero hay referencia a la del año pasado, de 2021, que es una estadística de uso de tecnologías de gestión de contenidos, digamos, a nivel mundial de temas de web. El que destaca más, la tecnología que destaca, que gana por mucho a las demás, es WordPress. WordPress tiene el 43% de uso a nivel mundial. O sea, digamos que el 43% de todas las webs del mundo son WordPress. 43. No llega al 50%, pero poco le falta. La segunda tecnología que destaca más es Shopify. En 2021, Shopify era la segunda con un 4,4. La segunda es un 4,4. La primera que es WordPress es un 43, a diferencia es abismal. Y la pregunta aquí es ¿dónde está Drupal? Drupal está bastante más para abajo y tiene un uso de 1,3 a nivel mundial. 43, WordPress, 1,3, Drupal. Es aún más abismal la diferencia. Ya intentaré arrajar un poco de luz a por qué hay esta diferencia tan abismal y por qué estoy recomendando Drupal en este podcast. A ver, básicamente, WordPress en sus inicios, a día de hoy aún, pero digamos que está más pensado para webs más simples. Está pensado en un inicio para blog o también para las típicas páginas que yo digo que son las de quienes somos, dónde estamos, qué hacemos. Son webs empresariales de cuatro páginas, o sea, cuatro URL, la home, una página de servicios, una página de quienes somos y una página de contacto con un formulario. Son las típicas webs de cuatro páginas, literalmente, en un único idioma o como muchos dos idiomas y que tienen texto y un formulario de contacto. Puntas a cabo. Son las típicas webs que te cobran entre 50 y 300 euros. Cuando te hacen en WordPress, instalan un tema gratuito o de pago y en una mañana o un día te lo han creado. Por eso digo que WordPress es para webs más simples y también para precios mucho más reducidos. También, como digo, se puede hacer para temas blog. Tú instales un WordPress pelado y te genera un blog y puedes automáticamente, o sea, pones textos y se publican los artículos del blog sin tocar configuración y, por supuesto, nada de código. Ahora bien, cuando quieres hacer cosas más hechas a medida, el precio se puede complicar. El precio se dispara y la complejidad del proyecto, pues, en WordPress a veces se queda corto. Dupas, por el contrario, la complejidad no le afecta tanto porque es muchísimo más flexible, pero claro, al final es para proyectos pequeños no vale la pena usar Drupal porque te vas a enmascar la broma. Por eso cuando me ha llegado un cliente que le es igual la tecnología, digo, ya, prefíneme tu proyecto porque quizá no tiene sentido trabajar esto en Drupal. O por tiempo, porque esto lo quieres en una semana y en Drupal esto va a tardar más tiempo porque me estás contando. O por presupuesto, que básicamente casi siempre es por presupuesto, porque no se ajusta a que esta bot me han dicho que se puede hacer por movimiento, 1000 euros, y yo, pues no, porque en Drupal te va a hacer mucho más caro. Y en primer principio, la parte de las configuraciones y las cosas que son más a medida es, digamos, el público al que está enfocado. A ver, cómo defino esto. WordPress tiene muchos plugins gratuitos y de pago, aunque son de un pago, digamos, relativamente bajo, pero bueno, digamos que gratuitos y de pago, enfocados a tareas, digamos, bastante concretas. Después, los temas, también hay temas visuales, o sea, cómo se ve la web, los clorines, si es bonita o no el tema, o si eso es a la derecha o a la izquierda, digamos, de forma muy simplista. Los temas visuales pueden ser gratuitos o de pago, y WordPress, realmente, es una de las ventajas que tiene, tiene un gran mercado de temas y de plugins. Comparado con Drupal, pues, ahora no me miro los números, pero, WordPress gana por goleada, o sea, por cantidad, tiene muchos más webs que Drupal. La diferencia es, WordPress está pensado para, ah, pues si hay un tema hecho, lo instalo y le cambio como mucho un color y ya está. Es más pensada para ser webs rápidas y baratas. Drupal, por el contrario, casi todos los temas y módulos, Drupal se llaman módulos, no plugins, casi todos, por no decir el 99%, son gratuitos de comunidad. Drupal o RG, que ya hablaré en otro episodio de esta comunidad, y porque te puede interesar, forma parte de ella, pero básicamente, en Drupal, casi todo, o por no decir todo, como he dicho antes, es gratuito, es open source, es de código abierto. Y además del tema del tema, los temas visuales, digamos que los que hay gratuitos, que tú puedes instalar y que la huella se vea más o menos decente, digamos que hay pocos. O sea, visualmente, es bastante más pobre que web, pero ¿por qué? Porque está más enfocado a webs hechas a medida. Está más enfocado a webs que tienes un diseñador o una agencia que has contratado y esa agencia contrató un diseñador, te hace un diseño a medida y 
usas un tema, que hay varios, sobre todo, por ejemplo, más conocidos en el Boostup, pero hay varios más, que lo usas como tema base. Y a partir de aquí se construye el tema visual para tu empresa. Drupal está más pensado para ser cosas a medida. Como he dicho, es más un framework que un gesto de contenidos al uso. Y esto es uno de los motivos por los que es más caro en Drupal, porque básicamente, en casi cualquier proyecto, más que instalar un tema visual y ya está, es hacer el tema visual. Te hace falta un equipo de frontend y un diseñador para que te quede bien visualmente la web. Por eso es tan caro comparado con WordPress. Y por otra cosa más, básicamente, no sé si te ha quedado más o menos claro la diferencia entre WordPress y Drupal. Por ejemplo, también, esto no lo he contado, ¿qué tipos de proyectos se pueden hacer fácilmente en Drupal? Dicho de otra forma, ¿en qué proyectos te diría yo que no te metas en Drupal o si te metes en Drupal? A ver, por ejemplo, webs muy simples, como he dicho antes, de cuatro páginas, en Drupal no le veo sentido. Un blog en un único idioma tampoco le veo sentido. Es mejor que WordPress en ese sentido, ¿vale? Un e-commerce depende de la complejidad. O sea, si quieres muchas cosas hechas a medida, se puede mirar. Pero si quieres un e-commerce simple, realmente no te vale la pena. No creo que valga la pena. Es mejor un WordPress o un Shopify si es un web en e-commerce realmente simple. Por ejemplo, tuve un cliente de que se hizo un e-commerce en Drupal y acabó pasándose a Shopify después de tener la web hecha en Drupal, ¿vale? Es un ejemplo. He tenido dos clientes que lo mantienen en un e-commerce en Drupal sin ningún problema. Pero como digo, depende de cada caso de uso y realmente si aprovechas toda la potencia de Drupal. Porque si no la aprovechas, básicamente, solo vas a tener las partes malas de este gesto de contenidos. ¿Qué otros proyectos? ¿O dónde tiene sentido? Por ejemplo, en webs multidiomas. Drupal es muy potente en el tema de multidiomas. Y 8 webs está creo que en 18, 19 o 20 idiomas. Una burra de idiomas. La misma web. En un web de esto te acortas las venas para ser una web con tantos idiomas. Otro tipo de proyectos, por ejemplo, como digo, está más enfocado al tema empresarial de Drupal. Está muy pensado para temas de hacer deploys en varios servidores, por ejemplo, con interacción continua. O sea que básicamente en Drupal todas las configuraciones que haces en tu local o en servidores de desarrollo se exportan a código, a Git, en este caso esto te puede sonar un poco cachino si no es un poco técnico. Digamos que se exportan a código, se ponen en el repositorio, se suben al servidor donde se desplega, en este caso, por ejemplo, a producción y se importan. Esto básicamente reduce los errores humanos porque en web es conocido de varias agencias que lo que hacen es los cambios que se hacen en desarrollo o en local lo replican manualmente en producción. Esto significa que la web está caída pues más tiempo del que debería, por ejemplo, una hora o una mañana hasta que se apliquen todos los cambios y que es propenso a errores, de que te dejes alguno de los pasos. Esto en Drupal no pasa. Los deploys están mucho mejor pensados y básicamente se pueden testear mucho más fácilmente. Es una de las otras ventajas. Está más pensado para proyectos, como digo, grandes que requieran un despliegue entre entornos. A mí, solo por esto, ya me ha ganado como técnico. La gestión entre entornos es un chapo. Y el tema de multibiemba también, yo que estoy acostumbrado aquí en Cataluña a catalán, español o español inglés. O sea, casi todas las webs han sido multibiomas, las que he hecho yo. Mínimo dos idiomas. Así que realmente es muy simple hacer esto. Por ejemplo, otra de las inconvenientes que tiene web es que no sé si lo han arreglado, pero cuando estuve yo en su día con esto no. Cuando haces un deploy de una web con otro dominio, en web no te cambia el dominio, con lo cual tienes una web con un dominio nuevo, por ejemplo, en el servidor de desarrollo tienes un dominio distinto que la de producción, y si pasas la base de datos de un servidor a otro te mantienen los dominios antiguos. Esto en Drupal no pasa. En Drupal todas las URLs son relativas, a menos que la hayas puesto en el código picado a fuego como absoluto. Pero es una ventaja, esto en el tema de los deploys, de que todo sea relativo. Y básicamente te ahorra muchísimo tiempo como desarrollador. Me he ido por las ramas. Proyectos. Si es multidioma, yo tiraría por Drupal. Si te hace falta una gestión de configuraciones, tiraría por Drupal. Si te hace falta que sea una cosa compleja, por ejemplo, que un e-commerce tenga un blog que aparte sea multidioma, con cinco idiomas todo, que tenga un buscador avanzado con búsquedas facetadas, y no sé, no sé más decir. Esto al final con Drupal, por ejemplo. Otro proyecto en el que estuve era, por ejemplo, una web que en verdad eran 150 o 160 o 70, no, ciento y pico webs dentro de la misma plataforma, que era el mismo Drupal que gestionaba esto, ciento y pico dominios separados, y el contenido se compartía entre distintas webs. Esto en Drupal. Y realmente había código, pero había muy poco código hecho a medida. O sea, era básicamente configurar módulos. Esto en web no puedes hacerlo. Como digo, al final es web más complejas, web hechas a medida, con diseños hechos a medida. En web también puedes hacer diseños hechos a medida, pero hasta cierto punto, si quieres hacer algo hecho a medida, ¿por qué sigues haciendo web? Quizá no tiene tanto sentido. Web tiene sentido cuando no son cosas hechas a medida. No es mi opinión, pero... ¿Qué más temas? Por ejemplo, internet. Hecho varias internets, que al final es una gestión de datos de usuarios, o gestión de becas, por ejemplo, o gestión de datos de museos internos. También, o sea, en Drupal realmente es muy fácil hacer esto. Y no sé, no se me ocurren más casos así. Por ejemplo, tema de buscadores también. Otro tema, en vez de e-commerce como tal, webs de escaparate. Yo les llamo webs de escaparate. Sería un e-commerce, pero sin pasar a dar pagos. Por ejemplo, una webscaparate de 30.000 productos, con nueve idiomas, que básicamente permite al usuario normal, pues quiero buscar este código de referencia, o busco por título. Encuentro el producto, voy a la página, veo las características del producto, y fotos, y manuales, y PDFs, y garantías, y lo que sea. O sea, documentación de producto, y no puedo comprarlo. Pero veo toda la documentación del producto. Eso es una webscaparate, que le digo yo. Y eso en Drupal también es muy fácil de implementar. Por ejemplo, se montan básicamente con el módulo e-commerce de Drupal, pero como es inflexible, básicamente no activas las partes de checkout, ni el carrito, ni los precios, ni nada de esto. Solo activas productos, y como muchas variaciones, si es que te hacen falta. Y nada, que me estoy alargando mucho, que pensaba que sería un episodio más corto. Si tenéis más dudas respecto a una cosa que no quedó clara en este episodio, me podéis contactar en Twitter o en LinkedIn, buscáis mi nombre, Robert Menetray, o en mi web menetray.com, y me contactáis por allí, y me decís, hey, mira, que tengo esta duda que no me ha quedado clara, si la puedes responder en otro episodio, y yo encantado y os la respondo. Y nada más, que si te gusta esta temática, pues suscríbete. A puede ser si usas Apple o Spotify, dame 5 estrellas. Y poco más. Hasta el siguiente episodio.