354 | 7 expertos en WordPress hablan claro sobre el uso de page builders
25 Jan 2023 · 25 min
Podcast episode (WordPress Semanal — ep. 354) in which host Gonzalo Navarro asks seven WordPress professionals whether and when to use visual page builders. The episode defines "Page Builder" (constructor visual) and contrasts external builders (Elementor, Divi, Gantry, etc.) with the native block editor (Gutenberg) and Full Site Editing. Contributors split between caution and pragmatic use: several (David Per Álvarez, Marta Torre) recommend preferring Gutenberg and avoiding external builders due to code bloat, semantics, accessibility and standards; Raúl González distinguishes heavy builders (Elementor/Divi) from lighter block-tooling (Spectra, Kadence, Oxygen) and emphasizes optimization; Xavi Angulo favors Elementor for speed/efficiency but warns about long-term viability of third-party builders; Álvaro Gómez (Automattic) argues Gutenberg is the present/future because it is core, lightweight, extensible and collaboratively developed; Fernan highlights democratization, community support and business/rentability reasons to use builders; Silvia Suria presents Gantry as a lightweight, extensible framework that stores layouts in files (Git-friendly) and works across platforms (WordPress/Joomla). The episode offers practitioner perspectives balancing performance, maintainability, accessibility, ecosystem and project constraints.
Chapters
En el episodio 354 de WordPress semanal vais a escuchar la opinión de 7 profesionales del mundillo WordPress sobre los Page Builders. ¿Conviene utilizar un constructor visual para tu web con WordPress? ¿Cuándo sí, cuándo no y por qué? Vamos allá. Hola, hola. Soy Gonzalo Navarro y Bienvenidos al episodio 354 de WordPress Semanal, el podcast en el que aprendes a crear y gestionar tus propias webs con WordPress en profundidad. Y hoy vais a aprender de 7 grandes profesionales relacionados con el desarrollo, el diseño, la gestión, la optimización de páginas webs con WordPress. Vas a poder escuchar opiniones sobre el uso de los constructores visuales, un tema que tiene mucha chicha y sé que a muchos de vosotros os interesa. Y además lo vais a hacer de profesionales que saben de lo que habla. Vais a escuchar la opinión de desarrolladores full stack, vais a escuchar la opinión de especialistas en optimización del rendimiento de carga de velocidad web, vais a escuchar la opinión de profesionales involucrados en comunidades de WordPress, de personas que trabajan directamente para Automatic, es decir, en el propio proyecto de WordPress. Org, y de personas que coordinan o llevan muchos proyectos a sus espaldas, ya sean como freelance o en su agencia o empresa. Y en un momentito vamos con ellos, que son los protagonistas de este episodio. Pero, pero antes vamos a poner un punto de partida. Vamos a definir muy rápidamente qué es un Page Builder, por si alguien no lo tiene claro. Básicamente un Page Builder, bueno, es en inglés lo que en español diríamos constructor visual, y no es otra cosa que un plugin o un componente de un theme que tú tengas que te va a permitir estructurar y diseñar las páginas y los contenidos de tu web visualmente, colocando componentes a tu antojo, dándole estilos, dándole forma. Básicamente una herramienta para plasmar un diseño en tu web sin utilizar código. Y desde un tiempo a esta parte, el propio WordPress trae también su propio editor visual. El editor que viene de forma nativa llamado Gutenberg, también te permite editar de forma visual los contenidos de tu web. Trae menos opciones por defecto que muchos de los constructores visuales que vais a escuchar en este episodio, pero se pueden ampliar sus funcionalidades con otras extensiones si es que lo necesitas. Y seguramente la gran diferencia que yo veo actualmente es el control que se tiene a nivel estructural, es decir, la posibilidad de implementar un diseño a nivel de toda la web, de la parte de footer, cabecera, zonas que se escapen del propio contenido y que se está empezando a implementar con el Full site editing, que no es otra cosa que diseño global del sitio, diseño global de la web, pero que aún no está maduro, aún no está disponible como una característica madura ni tampoco demasiado extendida, pero sin duda es el camino que lleva este editor. Bien, entonces, por un lado tenemos los Page Builders, los constructores que añadimos aparte, ya sea con un plugin o que viene preinstalado en un tema que añadas a tu web y por otro el editor nativo de WordPress, que lo puedes considerar ya constructor visual y si no lo consideras aún, dentro de muy poco lo vas a considerar. Bien, hecha esta introducción vamos a escuchar la opinión de estos siete profesionales. David Per Álvarez es diseñador y desarrollador WordPress especializado en creación de academias online y nos cuenta cómo él no usaría un builder externo pero con matices.
¿Qué tal Gonzalo, ¿Cómo estás? Un saludo a toda la familia de WordPress Semanal. Soy David Per Álvarez de Silicon Valley y me gustaría compartir muy brevemente mi posicionamiento acerca de los Page Builders. Personalmente yo prefiero no usarlos y la verdad es que el motivo principal por el que yo recomendaría no utilizarlos es porque hoy en día con el editor de bloques y con ciertas colecciones que otros plugins incluyen, no sólo con los bloggers nativos, se puede conseguir casi, yo te diría, el 95% de lo que permite hacer un Page Builder y si además pues tienes la suerte de saber programar, ya te diría que puedes prescindir al 100%. Otro motivo es el clásico que se suele decir que es que ensucian código, y si bien es cierto que no todos ensucian el código de la misma forma, es decir, que añaden 5000 clases y 5000 tags y un montón de estilos y de scripts que a priori no necesitarías para nada, sí que hay algunos que sí que lo hacen, entonces yo recomendaría evitar su uso para no sobrecargar la página de código innecesario. Y finalmente, otro de mi posicionamiento por el cual estoy en contra es porque suelen saltarse a la torrera los estándares de WordPress, es decir, WordPress promueve una forma de trabajar con el CMS o a nivel de programación con el framework y luego estos Page Builder en su mayoría se lo pasan por el forro y hacen un poco lo que les da la gana. Por eso yo diría que casi mejor si se puede no utilizarlos. Pero por otro lado, tengo claro que los Page Builders tienen su público, es decir, hay todo toda la parte de implementadores WordPress, yo soy desarrollador en mi caso, pero es normal que se utilice para por ejemplo, crear landing pages. Yo jamás diría que una landing page se haga programada con código porque no tiene ningún sentido, y en ese caso puedo entender que si alguien no está acostumbrado o acostumbrada a utilizar los bloques, pues utilice un Page Builder. Sea como sea, yo creo que dentro de WordPress hay espacio para absolutamente todos y esa es la magia de WordPress. Así que si quieres utilizar un Page Builder hazlo y yo por mi parte seguiré sin usarlos y te recomiendo que al menos te familiarices un poco con todo el tema de los bloques, que verás que es muy fácil de aprender y en breves seguramente tú también prescindirás de un Page Builder. Un abrazo a todos.
Marta Torres, desarrolladora full stack especializada en WordPress y estas son sus razones por las que no elegiría utilizar un plugin.
De Page Builder Buenas, soy Marta Torre, soy desarrolladora web y me quiero posicionar en este asunto bastante en contra de los banquetadores visuales. Es verdad que depende del usuario del que lo use, pero este tipo de maquetadores visuales. Yo soy muy partidaria de utilizar el editor de bloques, que es algo nativo, que viene con WordPress ya incorporado y creo que da muchas ventajas hacia estos maquetadores visuales. Sí que es verdad que los maquetadores visuales están creados o hechos, según mi punto de vista, para un tipo de usuarios concreto, entonces no se puede comparar un tipo de usuario conmigo como desarrolladora, por ejemplo. Pero sí que es verdad que hay que intentar hacer las cosas un poco bien. Estos maquetadores visuales no respetan para nada los estándares de desarrollo de software a nivel de rendimiento, aunque digan que sí que se puede optimizar Elementor, o que se puede optimizar DIVI, o se puede optimizar no sé, qué tienes que hacer un esfuerzo extra, eso es decir, que un esfuerzo extra requiere tiempo y dinero siempre. ¿Si ya tenemos algo nativo, por qué vamos a extender una cosa que ya la tenemos incorporada en el propio core de WordPress? También a nivel de semántica de HTML, estos maquetadores funcionan bastante mal, no respetan para nada la semántica y eso requiere que por ejemplo, para pintar simplemente un H, un encabezado, lo pinten a través de 30 divs. Es absurdo y no tiene sentido alguno. También a nivel de exclusión de usuarios, este tipo de maquetadores visuales va un poco en contra de la accesibilidad web y de la sostenibilidad, porque utiliza también bastante JavaScript y bastante cosas de movimiento que no son necesarias y que hacen que el mundo vaya un poco peor, porque eso va en contra de la huella de carbono o de unos usuarios que tienen unas condiciones o unas necesidades especiales. Pues esto es todo. Podría contar muchas más cosas de por qué no me gustan los maquetadores visuales, pero creo que que con esto ya es suficiente. Muchas gracias.
Raúl González es especialista en optimización de webs WordPress para que tengan el mejor rendimiento de carga posible y desde ese punto de vista nos analiza el mundillo de los constructores visuales.
Hola Gonzalo, muchas gracias por invitarme a tu podcast. En el tema de builders yo voy a hablar desde mi especialidad que es el rendimiento web, la optimización de WordPress. Tenemos que diferenciar los builders en dos grupos. Por un lado los builders que son pesados, tipo Elementor y Divi, que además de pesar mucho porque pesan un mega y pico cada uno y pues es que además cargan todo el código en toda la URL. Después tenemos otro tipo de builders tipo Guttermere con un plugin de bloques tipo Spectra o Kadence, o incluso otro tipo de builder como Oxígeno, que con este pues podemos crear toda la web desde cero con él. En fin, la ventaja de esto último es que sólo cargan el código de los bloques que se usan, con lo cual pues son mucho más ligeros que Divi y Elementor, Usemos unos o usemos otros, igualmente hay que optimizarlo porque todos cargan CSS, todos cargan JavaScript y fuente, en fin. Total, que da igual que use. Obviamente cuanto más pesado sea el builder pues más tareas de optimización hay que hacer y bueno, también puede surgir más problemilla y tal y cual. Si en el caso de que hagamos una web desde cero, pues hombre, yo personalmente estoy a favor de usar los builders y como yo uso pues recomiendo Gutmer más Spectra. Este plugin de bloque es muy completo y muy ligero, que alguien requiere de un diseño mucho más currado, obviamente pues habrá que tirar de builders tipo Elementor, pero usemos uno o usemos otro, igualmente hay que optimizarlo. En fin, espero que este consejo sea de utilidad. Yo estoy por ahí siempre en Twitter también tengo una newsletter en la que doy muchos consejos de optimización de WordPress. ¿En fin, que cualquier cosilla que tengáis, cualquier preguntilla me preguntáis vale? Venga, un saludo.
Xavi Angulo es desarrollador web con WordPress, hace mantenimientos, optimización y seguridad y además es investigador independiente OSINT Open Source Intelligence o Investigación desde Fuentes abiertas. Y Xavi nos habla de su preferencia por Elementor, pero sin cerrarse a ninguna opción y además de la importancia de tener en cuenta la viabilidad a largo plazo.
¿Hola Gonzalo, qué tal? Buenos días, buenas tardes, buenas noches. Me imagino que para ti y para cualquier oyente que nos esté escuchando ahora en estos momentos. Bueno, pues puedo hablar por casi todos los builders que nombraste en Twitter, porque casi todos los he utilizado. Me he acostumbrado a uno porque lo veo más sencillo, más rápido, pero claro, es según la persona, la persona que vaya a crear la web. Hay gente que se ve cómoda con Guttenberg porque ya viene nativo y demás. Yo estoy empezando a utilizar, bueno, estoy empezando, llevo ya bastante tiempo utilizándolo Gutenberg, porque son proyectos que he tenido la oportunidad casualmente de. De no tener que meter tanto diseño y demás. Aunque sí que es cierto que en estos últimos meses me estoy dando cuenta cada vez más de que hay bastantes recursos para poder hoy en día con Gutenberg hacer muchas cosas. Luego, con el que más he utilizado y que me gusta muchísimo, sobre todo para hacer, para digamos, si tengo que por tiempo tengo que ser más ágil, es con Elementor, porque desde hace poco, por cierto, era organizador de Elementor Zaragoza y por circunstancias y demás he abandonado un poco esa fila, sigo con la comunidad de WordPress, pero he dejado un poco de lado, no de lado, digamos que no me da la vida para seguir con elementos, con la organización de Elementary. Yo seguiré utilizando la herramienta, por supuesto. Digo que he utilizado todos porque por ejemplo Divi también, además, de hecho Divi fue mi primer builder cuando empecé a trabajar con WordPress y los demás, ahora estoy tocando bricks, también estoy experimentando un poco, lo que pasa que estoy toqueteando, que de hecho estoy en una comunidad española que han creado hace poco, tenemos un Discord por si te invito yo personalmente, aunque no soy del grupo y demás, pero no llevo el servidor, pero te invito a ti o al oyente a visitarlo y bueno, prácticamente ya te digo, lo estoy revisando, probando en local y un poco así por tantear un poco a ver qué tal va. Brick de momento me está gustando, pero sigo entre comillas siendo fiel a Elementor, si tengo que elegir un builder, yo insisto un poco en que Gutenberg está ahí también, no es por nada, simplemente porque me está dando mucha satisfacción, sobre todo en WPO, tener optimizada la web, pero sí es cierto que a la hora de diseñar veo que me atasco muchísimo, tengo que estar tirando de código, si es un proyecto que necesita un poco de agilidad en cuanto tiempo, como dije antes, tengo que presentarlo y demás, cuanto antes o porque le urge el cliente, Ahí tengo el problema que necesito, prefiero utilizar algo como Elementor porque me veo más suelto con Elementor y porque tengo muchas posibilidades, Elementor cada vez está creciendo más y no para de crecer y eso es bueno también. Entonces bueno, ahí lo dejo entre tira y encoge, Yo tampoco soy, no me gusta ser de un builder solo, aunque Elementor está ahí, siempre lo digo, pero no soy de tirar de un builder y la verdad, repito que creo que la raíz de todo esto también, que siempre hay un tiro y encoge con los builders y con el código y con WordPress y demás. Yo creo que cada uno debe de organizarse o hacer un estudio antes de crear una web y revisar todo desde arriba abajo, no es plantearte solamente hacer la estructura, empezar a meter las páginas, fotos de textos y tal, sino ver también en un futuro posible qué es lo que pueda pasar con la web, porque a lo mejor el cliente no quiere proseguir o tú no quieres proseguir con tu proyecto llevando un mantenimiento, sino olvidarte un poco de eso, aunque es un error, pero bueno, está feo que lo diga yo que llevo mantenimiento, pero bueno, hay proyectos que no hay que dejarlas a la deriva como los barcos en un futuro hay que tener en cuenta que si a lo mejor, supongamos por H por B cierra esa compañía de build, no siguen desarrollando como pasó hace poco, lo vi con King Composer hace unos años que dejaron de seguir desarrollándolo y todos esos proyectos se han quedado entre comillas tirados, que necesitan otra vez rehacer toda su web con otro Wheeler o incluso con Gutenberg. Entonces, quiero decir, esa es mi opinión que hay que revisar un poco también es algo que no podemos esperar, no sabemos qué puede pasar con un Builder a la hora de saber si el desarrollo sigue o no, pero pasa igual con WordPress, que siga allí por supuesto que tiene un una cota de Internet bastante cogido por el tema de que es más sencillo, la curva de aprendizaje más rápida, pero claro, puede ocurrir que ocurra algo grave dentro de desarrollo, es algo que no podemos prever. Entonces, no sé, hacer un pequeño estudio de mirar primero antes de comenzar a crear páginas webs con un Builder y ver lo que está pasando y qué actualizaciones están haciendo. También digo Builder como con cualquier plantilla o plugin. Bueno, no sé, espero haberte respondido a lo que quería comentarte. Un placer por supuesto participar contigo. Ya sabes que llevo mucho tiempo que te sigo y tu podcast sobre todo, o sea que un abrazo fuerte y nada, nos vemos por tus cursos. Hasta luego.
Álvaro Gómez Trabaja desde hace 15 años con WordPress, primero por su cuenta y desde hace 4 para Automatic. Actualmente es voluntario full time del proyecto WordPress. Org con Automatic como su sponsor. Así que Álvaro nos explica desde dentro por qué considera que el editor de Gutenberg es presente y futuro. Hey.
Hola Gonzalo, ¿Qué tal? Estábamos hablando por Twitter de editores visuales y me dijiste a ver si te podía grabar un audio de por qué yo había mencionado Gutenberg y aquí voy. Vale, pues mis razones son y sin quitar valor al resto de los editores visuales, yo sí animaría a la gente a tirarse a la piscina con Gutenberg y probarlo y darle una oportunidad, entre otros por los siguientes Primero, porque es parte del núcleo de WordPress y es literalmente el futuro. Puede que cambien las cosas, puede que el editor vaya por un lado o por el otro, pero es mucho más probable que tenga continuidad Gutenberg, el editor de bloques, que literalmente cualquier otro plugin que depende de una empresa particular que en un momento determinado pueden tomar una decisión de que no les compensa o cambiar una política de precios o qué sé yo que os voy a contar. Lo segundo, porque no es solo un editor, no es un editor visual, sino que además es el editor de contenido de WordPress. Es tanto un editor de contenido como un creador de temas. Es las dos cosas. Y lo tercero porque tenemos por delante la fase 3 y la fase 4 en la que van a introducirse cosas como edición colaborativa y multidioma. Y todo esto se va a crear por encima de lo que existe ahora. En la medida que aprendas a utilizar Gutenberg y a extenderlo y a usarlo en general o a usarlo para construir webs para clientes, todas estas mejoras te van a resultar más familiares y las vas a conocer y las vas a aprovechar más. Siguiente motivo, porque es ligero. Yo no he hecho benchmarking ni cosas de este tipo últimamente, pero mi experiencia dando soporte en WordPress. Com por ejemplo, es que en general es muchísimo más ligero. Lo siguiente que está relacionado también es por la integridad de la forma en la que se guardan los datos. Esto se ha mejorado mucho en el caso de los editores visuales que antiguamente tiraban de shortcodes y si lo desactivabas quedaba bastante terrible el contenido. Me consta que esto ya no es así, pero es que en el caso de Gutenberg literalmente estás utilizando etiquetas HTML y comentarios HTML, así que incluso en el caso de que tuvieras que exportar ese contenido a cualquier otro CMS o servirlo tal cual en un momento dado es perfectamente interpretable y aprovechable, o sea que integridad de datos. El siguiente motivo es porque al ser un estándar existen miles de blogs bloques que se pueden usar. Si tú utilizas un editor visual concreto y estás buscando un bloque, un widget, una funcionalidad determinada y no está disponible para ese editor, pues te quedas atascado. En el caso de Gutenberg existen bloques para cualquier cosa y en el peor de los casos siempre lo puedes construir tú o siempre puedes pedirle a alguien que te lo construya y le va a resultar más fácil que investigarse un editor visual concreto. Y además hay otra cosa que me gusta mucho que es que Gutenberg te permite instalar un bloque desde el propio editor. Tú estás editando, vas al insertador, al inserter, buscas, escribes algo y si no está instalado en tu página te va a listar los bloques de terceros que existen en el repositorio que tú puedes instalar y lo puedes instalar en el momento y sin recargar el editor tienes tu bloque. No mola mucho eso, no me consta que lo hagan otros editores, pero puedo estar equivocado. Y además de estos bloques de terceros que están disponibles hay hay plugins que modifican y extienden el propio editor. Por ejemplo hay un plugin que se llama EditorsKit que añade funcionalidades extra muy interesantes que aún no están en el núcleo de WordPress y que puedes usar a día de hoy en tu página. Al ser un estándar es más fácil de extender y hay más gente trabajando en ello. Y el último motivo es porque el desarrollo de es 100 % colaborativo y transparente, está en GitHub y cualquiera puede abrir un issue y cualquiera puede escribir un pull request y cualquiera puede opinar en cualquiera de los debates. Mientras que la mayoría de los editores visuales pertenecen a una empresa y al final las decisiones que se toman son conversaciones internas y no es tan fácil colaborar. En el caso de Guteberg, si a ti te falta o te sobra algo del editor o encuentras un bug o cualquier otra cosa, es mucho más fácil formar parte del proceso. Bueno y esa es mi chapa. Un abrazo. Chao.
Fernandíez es coordinador de proyectos webs en la empresa Frikitech, con experiencia en la gestión de más de 100 proyectos y es parte activa de la comunidad de Uber WordPress Bilbao. Fernan me envió dos audios, uno con los inconvenientes que ve en utilizar los builders, que yo creo que eso está ya muy bien cubierto por otros profesionales, y otro con las ventajas. Vamos a escucharlas.
Hola Gonzalo, encantado de participar en tu podcast y de poder dar mi opinión acerca de por qué los constructores visuales, por qué los editores visuales para WordPress pueden ser una buena solución para un proyecto. En primer lugar yo creo que nos permiten conseguir resultados profesionales o aparentemente profesionales a cualquier persona sin que tenga realmente demasiados conocimientos en diseño web, en desarrollo web, en maquetación. Yo creo que de esta manera permite y va un poco alineado con la mentalidad de WordPress o con el espíritu de WordPress de que cualquier persona pueda crear su página web y en este caso pueda crear su página web con una apariencia profesional. Yo creo que es importante democratizar el acceso a ese contenido y el acceso a esos resultados a todo el mundo y es parte de la gracia de WordPress también. Por otro lado, existe un ecosistema de plugins add ons, hay foros de soporte, hay tutoriales, hay incluso meetups y grupos de apoyo de estos editores visuales que permiten que si me encuentro por ejemplo en el mantenimiento de una página, pueda tener recursos en Internet o personas incluso que me puedan ayudar, donde poder consultar, donde poder tener información. Es decir, existe también una comunidad de apoyo y existe mucha información documentada para poder hacer ciertas cosas, para poder solucionar ciertos problemas. Y creo que a nivel de soporte es algo que está cubierto con una programación a medida, por ejemplo, si no somos programadores y nos encontramos con el mantenimiento de una página web que está hecha desde cero a medida, si hay algún problema, es verdad que igual nos va a costar más poder llegar a la solución. Y por último, creo que de cara a profesionales del sector, a un desarrollador, a un maquetador, a un diseñador o una diseñadora o una agencia, permite que algunos proyectos puedan llegar a ser rentables. Porque es verdad que trabajar en determinados proyectos con una programación hecha a medida, con una programación desde cero o con elementos muy personalizados, requiere de muchas horas de trabajo y a veces el presupuesto que está sobre la mesa no lo puede cubrir y tenemos una necesidad de que realmente el trabajo esté hecho. Hay que pensar que al final, en ocasiones, una web no es más que un canal para hacer otras cosas, para vender más, para comunicarse mejor, para tener un mayor reconocimiento de marca. Y en el fondo igual hay otras fases del proyecto posteriores, como una campaña de publicidad, por ejemplo, que son incluso más importantes que el hecho de que una web está construida de una manera o de otra. Así que creo que es interesante tener un poco perspectiva, verlo desde arriba y ver todas las posibles ventajas que nos puede ofrecer trabajar con este tipo de herramientas.
Silvia Suria es CTO de Esencial Sistemas S L, domadora de plataformas de comercio electrónico y otros dragones, y nos va a explicar por qué usa Gantry como framework y constructor visual para sus proyectos y por qué deberías usarlo tú también.
Gantry fue en mi caso la elección ganadora después de estudiar varios frameworks del mercado, los más importantes en ese momento. Durante seis meses estuve probando Divi Bakery y otros muchos hasta que me quedé con él. Las razones que yo estuve barajando no solamente fueron la facilidad de uso, la curva de aprendizaje pequeña en comparación con otros del mercado, sino que también ganó de largo, por ejemplo, que es muy liviano a la hora de cargar en el frontal, su versatilidad, su facilidad a la hora de ampliarlo con secciones nuevas, la facilidad que te da para trabajar con elementos externos como sliders o cualquier otro y la capacidad que te da para, por ejemplo, meter shortcodes, código PHP, código TWIG HTML. En el momento en el que yo empecé a trabajar por ejemplo con Gantry, no se podían poner los widgets en cualquier sitio, solamente en las zonas reservadas a widgets. Pues Gantry en ese momento me permitió poner el widget donde yo quisiera. Todo esto fue antes de que WordPress sacara Gutenberg, con lo que yo podía hacer lo que ahora nos permite hacer Gutenberg sin tenerlo y además restringiendo mucho más y sacando mucho más lo que era el trabajo de un maquetador que el trabajo de un programador y el trabajo de un copywriter. Por si todo esto fuera poco, una vez que has aprendido a utilizarlo, te das cuenta de que puedes también utilizarlo con los mismos conocimientos en un Joomla. Entonces no necesitas aprender a utilizar un framework para WordPress y otro para Joomla. Yo en mi caso, yo trabajo muchísimo más con WordPress que con Joomla, cada 50 WordPress que toco, a lo mejor toco un Joomla y me daba un montón de coraje para un Joomla que tenía que hacerle algo de diseño o lo que sea, vamos, más que diseño de implantar una plantilla, pues tener que aprender lo que necesitaba para implantarlo en Joomla. Con Gantry pues se ha acabado, porque los mismos conceptos sirven para uno que para otro. Aparte de todo esto, Gantry es Open Source, con lo cual es algo a tener también en cuenta y darle un positivo más. Y después la documentación que tiene en Gantry. Org es genial, yo aprendí a hacer todo con esa documentación y con la documentación de Twig. Y lo mejor de todo es que el diseño no se guarda en base de datos, sino en archivos, con lo cual lo puedes meter todo en Git y hacerle versiones y demás. Entonces para mí es genial, incluso lo coges de un proyecto, te lo llevas a otro y sigue funcionando aquello. Esto es todo, si tenéis dudas sobre Gantry me podéis escribir. Venga, un saludo, hasta luego.
Y hasta aquí la opinión de estos siete grandes profesionales a los que agradezco muchísimo que se hayan pasado por WordPress semanal, de los que podéis seguir aprendiendo con los enlaces que os voy a dejar en las notas del episodio. Ahí podéis ver sus perfiles de Twitter, sus páginas web, sus newsletters. Recordad que podéis acceder a todo esto escribiendo en vuestro navegador gonzalonabarro es 354, que es el número de este episodio. Si os gusta este formato de episodios, decídmelo, podéis contactarme porque surgió un poco casi que de casualidad. Esto fue a raíz de un tuit que publiqué y estos profesionales y otras personas se interesaron y al final pues ha salido este episodio colaborativo tan chulo que espero hayáis disfrutado. Como siempre, antes de irme, darte las gracias por estar ahí. Recuerda suscribirte al podcast desde la aplicación que lo escuches, compartirlo con las personas a las que pienses que le pueda gustar WordPress semanal y si quieres aprender a crear y gestionar webs con WordPress de forma profesional, con vídeos paso a paso y con soporte personalizado, pásate por gonzalonabarro. Es nada más por este episodio, nos seguimos escuchando. Adiós.
More from Gonzalo
518 | Redes sociales, precios personalizados, audios desde Drive y temas de bloques (Q&A)
513 | Por qué sigo usando estos plugins después de tantos años (y cuáles he abandonado)