 Bienvenidos de nuevo a la ya presión, José Arcos, mi querido José Arcos. Este señor que tenéis aquí, lo voy a leer porque si no se me... Es un desarrollador web especializado en WordPress y trabaja en la empresa de consultoría Equiden para el Centro de Computación de las Naciones Unidas. Y ya estaría. El tío hace un montón de cosas, desarrollador, formador online, organiza eventos, forma parte de la comunidad de WordPress Vuelva, ayuda en traducciones y viene aquí a contarnos. Pues este tema que ha dado mucho de sí, así que esperemos que nos hable de bloques, de patrones y de un montón de cosas. Así que muchas gracias José. A te dejar que se siente todo el mundo. Bueno, buenos días. Muchas gracias por elegir la charla de este humilde servidor. Me gustaría que esta fuera la primera de muchas charlas, no introducida por mí, o sea, no charlas mías, sino de muchas charlas que hablen sobre temas basados en bloques. Porque hasta ahora solo he visto una que hable sobre temas basados en bloques en español, que se introdujo en la WorkCann ni Caragua 2021 y que hablaba un poco de full-site editing y temas basados en bloques. Sí que hay muchas charlas de bloques, de hecho, Mau va a hacer una hoy y hay muchísimas charlas sobre creación de bloques, extensión de bloques, etcétera. Pero claro, los temas basados en bloques es como el siguiente paso, ¿no? Y por eso doy esta, que será un poco introductoria, lo siento para aquellos que venían a picar código, como decía, a aquellos que quieran extenderla. Pues un taller, por ejemplo, de una horita sería algo bueno para meternos más de lleno. Bueno, vamos a hablar de temas basados en bloques y en general de temas en este año, en el año 2022 o de aquí en adelante, o incluso un poquito hacia atrás, cosas que han ido siendo ya comunes en nuestros días. Hablando de temas basados en bloques, pues muchas personas o muchos desarrolladores nos tememos de que se han acabado los temas de Wordpress, tal y como los conocíamos, y que ahora hay que aprender un paradigma nuevo. En partes es así, pero todavía los temas van a seguir viviendo. De hecho, los temas de Wordpress han muerto, larga vida, los temas basados en bloques. Porque eso es lo que tendremos en un futuro muy próximo o incluso ya en el presente. ¿De qué hablamos cuando hablamos de temas basados en bloques? Bueno, ya habréis escuchado hablar sobre este famoso archivo, el theme.json. Es el archivo por defecto, bueno, el archivo más importante de un tema basado en bloques. Y en este archivo cada vez se irán definiendo más cosas. De hecho, este lo he sacado del tema 2022. La mayoría de los ejemplos de código están en este tema, en el 2022, que es el tema que viene con la versión 6 de Wordpress. Y el theme.json de 2022 tenía estas cositas y aparte ya se han introducido alguna nueva. Vamos a ir hablando de ellas poco a poco. Lo primero, obviamente, la versión, eso cae por su peso, ¿no? Y luego hablamos de custom templates, settings, styles y template parts. Vamos a hablar primero de lo más importante, muy brevemente, como decía, esto va a ser una chala un poquito introductoria, ¿no? El objetivo de este archivo, del theme.json, un archivo.json, como bien sabéis, un archivo estructurado en el que se definen por así decirlo varias cosas. Y en este caso para el tema se van a definir, pues, por ejemplo, lo que vemos aquí, que como decía, cae por su peso, ¿no? Cosas tan básicas como, por ejemplo, los estilos. Ahora vamos a hablar de qué tipos de estilos tenemos en un archivo o en un tema basado en bloque. Pero cambia un poco el paradigma. Hasta ahora casi todos los estilos los hacíamos puramente CSS. A partir de ahora se pueden definir o se pueden predefinir estilos en un JSON. Y lo siento por aquellos desarrolladores de la vieja escuela. Ahora se escribe en JSON. Pero bueno, no pasa nada. Estamos aprendiendo, estamos reinventándonos continuamente. El settings, pues, también, por así decirlo, sería algo así como estilos y incluye muchas más cosas. Después, si queréis, podemos echarle un vistazo al theme.json del 2020.json. Y las cosas interesantes aquí, pues, yo diría que son estas dos. Y la que cambian por completo el paradigma de lo que hasta ahora ha sido el desarrollo de temas en WordPress. Las template parts y las custom templates. El problema de los temas de WordPress, creo que estamos todos de acuerdo, es que no había definido un sistema de plantillas como tal. Si nos ponemos a pensar en otros CSS como Groupal o en frameworks más modernos como Laravel, tienen un sistema de plantillas, incluso PrestaShop, tienen un sistema de plantillas para vergüenza propia nuestra de los desarrolladores de WordPress, no teníamos un sistema de plantillas como tal. Teníamos puro PHP, HTML y algunas funciones de la API de WordPress, que las usábamos continuamente, aparte de nuestro querido loop. Casi todos conocéis el Wild, HavePos, Depos y todo eso, el famoso loop de WordPress. Bueno, esto ha cambiado prácticamente por completo con los temas basados en WordPress y lo que ahora sí tenemos es un sistema de plantillas. ¿Nos guste o no? Por fin tenemos un sistema de plantillas, tanto que hemos estado pidiendolo, pues ahora a lo mejor nos arrepentimos, ¿verdad? A ver lo pedimos tanto. Bueno, es lo que queríamos. Como decíamos, tenemos estas cositas, el template part, lo vamos a hablar ahora que es de lo más importante, y aparte el CIN.jso continúa evolucionando, y aparte de eso ya se pueden definir los patrones, que fue algo que vino antes de los temas basados en bloques, los patrones también se pueden definir ya en el CIN.jso. Como decía, este tema fue creado en 2021, aunque sea 2022, el tema 22, pero se creó en 2021, ya en menos de un año ha salido o tenemos una nueva opción en el CIN.jso, se quiere decir que está en continua evolución. Esto de que esté en continua evolución, lo vamos a repetir durante la charla, y puede ser un handicap que vamos a hablar al final de ello. ¿Cuál es la estructura básica de un tema basado en bloques? Como decíamos, vamos a cogerla del 2022 y la vamos a desglosar. Veíamos aquí, por ejemplo, las templates, ¿no? Y fijaos aquí qué interesante. Esto es casi nuestro querido sistema de jerarquía de plantillas en Wordpress, aquel árbol que muchos conocéis se han dado charlas muy interesantes, y no recuerdo mal Juan Hernando Mauricio. Muchos habéis hablado de esto en muchas Wordpress, del sistema de plantillas, de la jerarquía de plantillas en Wordpress, y realmente se sigue utilizando. El índez PHP pasa a ser índez HTML, y luego pues todas las plantillas y toda la jerarquía que queramos usar. El archive, el 404, tenemos luego páginas y páginas en concreto, páginas específicas, search, single, pero ya no son PHP, ahora son HTML. Y vamos a hablar de algo muy interesante sobre ese HTML. Antes de ello, vamos a seguir degluzando. Decíamos que teníamos estilos predefinidos, nuevamente estilos en JSON. Sé que rompe un poco el paradigma, tenemos que reconstruirnos continuamente para seguir evaluando nuevos desarrolladores, y ahora tenemos que acostumbrarnos a definir estilos en JSON. No es malo, ¿eh? Si seguimos haciendo las cosas bien, tiene mucho potencial. Y luego tenemos las partes, como el header, el footer y headers y footer secundarios, o opcionales, también aquí iría al sidebar si lo tuviéramos, etcétera, ¿no? Finalmente hablábamos de los patrones, que hasta ahora los patrones se definían, por ejemplo, en el Functions PHP, un patrón de bloques era algo muy fácil de hacer. No íbamos al editor de Gutenberg, creábamos nuestros bloques, seleccionamos, por ejemplo, un grupo o un grupo de colunas, nos llevamos al bloque padre, copiábamos, y ahora nos llevamos a una función de PHP y le decíamos, esto quiero que sea un patrón de WordPress, un patrón de bloque, perdón. Y eso aparecía en la izquierda, junto a la función de los bloques, aparecen bloques o patrones. Bueno, ahora se definen, seguimos usando PHP para patrones, creo que no quedará mucho en que pasen a ser puramente HTML, no me citéis en esto. Y creo que, y entonces, como decíamos, lo incluimos aquí en la carpeta de patrones. El resto ya es un poco lo que hemos tenido siempre, ¿no? Entonces, se sigue siendo el archivo en el que definimos la cabecera, por ahora. Tampoco me citéis en eso, pero yo creo que el CIN.json llegará a ser el archivo en el que citemos la cabecera. El índez PHP deja de ser requerido, deja de ser requerido si no me equivoco, bueno, si no me escucháis. Deja de ser requerido a partir de las 6.1. De hecho, el track, el ticket de track, ya no, tampoco me citéis en esto, me voy a decir muchas cosas. El ticket ya está cerrado, se quiere decir que en la próxima versión, supuestamente, los temas basados en bloques, no van a requerir índez.php. De hecho, si abrimos este índez.php, bueno, no lo voy a hacer porque no lo tengo en su ordenador, pone precisamente un comentario que dice que este archivo no será requerido en el futuro, hay un track hablando de eso. Pulsamos en el track y dice, no, el track ya está cerrado, esto ya hace tiempo que se solucionó. Así que el 2023 probablemente no tenga índez.php. Luego, nuestro querido archivo función PHP va a seguir estando con nosotros durante mucho tiempo, ese no lo vamos a dejar. Y recordamos que esto no tenía nada que ver con la charla, las funcionalidades van en los plugins, no en los temas. El función PHP no es para meter ahí a cascoporro de todo lo que nos ve. Bueno, entonces, aparte de eso ya, cada uno define como quiera, por ejemplo, los assets, fuentes, imágenes, vídeos. El 2020 shoot tiene una forma muy curiosa de definir las fuentes, que por cierto, también lo hace en el zin.json, le podéis echar un vistacito porque lo hace de una forma muy curiosa lo de incluir fuentes nuevas. Y otra recomendación que no tiene nada que ver, las fuentes si pueden ser siempre auto-ospedadas mucho mejor que consumir de Google Fonts o consumir de fuentes externas. Bueno, esta es la estructura básica de un tema de Wordpress. Vamos a hablar ahora de los estilos en concreto. Y hay tres tipos de estilos en un tema basado en Wordpress. Los que define el core de por sí, que son los de, lo habréis visto, las clases UWP, Guion Block, Guion Paragraph, UWP, Guion Block, Guion BlockWord, o lo que sea. Están por defecto en hojas de estilo que están en el core de Wordpress. En cada versión de Wordpress esos estilos pues están, los hereramos. Luego los que definiría el tema, que esos sí son los que irían, pues aquí en el styles, o mejor dicho, en el zin.json y donde los definamos. Y luego, y esto es lo que ha roto por completo el patrón en Wordpress es que por fin los usuarios tienen el control del diseño. O para nosotros los desarrolladores, lamentablemente los usuarios tienen el control del diseño. Bueno, ahora con el full site editing, con los temas basados en bloques, con el editor en bloques, los usuarios pueden definir sus propios estilos dependiendo de la libertad que le dé el bloque, el desarrollador del bloque, dependiendo de la libertad que le demos los desarrolladores de temas. Y esto es algo muy interesante, porque por ejemplo hay algunos sitios en los que un mismo bloque puede tener dos, tres, cuatro estilos distintos. Por ejemplo, ahora esta semana estaba trabajando en un sitio en el que un slider de citas, el típico block quote o quote de citas que tenía la imagen, la cita o la frase de alguien y el nombre de la persona, que era azul en un sitio con una imagen de fondo en otro sitio y blanco en otro sitio. Bueno, pues esos estilos predefinidos los podemos definir en el tema y entonces el usuario selecciona esos estilos. Esa es la potencia que pueden tener los temas basados en bloques. ¿Cuál es el problema aquí? Pues que vamos a necesitar por así decirlo el famoso reset.css que usamos o que usan casi todos los front-end, casi que vamos a necesitar los mejores en proyectos propios. No estoy diciendo que sea obligatorio, pero a muchos a lo mejor eso quizá ira evolucionando, como decía. Esto es casi algo experimental, todavía estamos empezando, entonces irán saliendo muchas funcionalidades y iremos adaptando nuestra forma de trabajar. Pero claro, si nosotros la ventaja que tiene los estilos en el core ahora es que si un desarrollador crea un tema en blanco y se pone a hacer bloques y se pone a hacer cositas, las columnas van a funcionar. Ya hago tres columnas, por defecto las tres columnas van a estar sin yo aplicar ningún sistema de grid ni aplicar ningún framework.ss las columnas van a funcionar porque el core ya tiene sus propios estilos para cada bloque. Ahora, que yo quiero que esas columnas sean cajitas con un bordel radius o que tengan sombras, pues ahí llaman los estilos en el tema, ¿verdad? Bueno, tengamos en cuenta esto porque nosotros como desarrolladores tendremos que adaptarlos si no nos gustan los padding, los margin lo que sea y luego tendremos que crear nuestros propios estilos. Y siempre tengamos en cuenta que es lo que queremos darle al usuario y que es lo que no. Veía por ejemplo de una agencia de desarrollo world que se llama TenApp, muchos la conoceréis pues ellos crearon el sitio de la campaña del actual presidente de Estados Unidos o el sitio de gobierno y ellos limitaron mucho lo que es la experiencia que tiene el usuario. Bueno, básicamente lo han quitado. Todo lo que daba Gutenberg se lo han quitado y ahora básicamente lo que tiene es pongo aquí un título le cambio a lo mejor negrita o itálica o le cambio el color a la letra pero no pueden jugar con todo lo que te da a Gutenberg. Entonces, esa limitación que ellos han hecho podemos hacer a nosotros desarrollando temas o desarrollando una extensión para WordPress limitando lo que el usuario puede hacer. La cuestión es que es lo que WordPress le da que no le quiten los desarrolladores. Si WordPress la nueva evolución le está dando a los usuarios el poder tampoco somos nosotros nadie para decirle a los usuarios no, esto no lo toque. ¿Qué podríamos hacer? Trabajar un poco con los permisos de usuarios no, para que quizás no tengan acceso a ciertas cosas pero bueno, un editor va a poder simplemente manipular todo lo que hay en el core o en el editor. Simplemente repetimos que como desarrolladores vamos a tener que tener en cuenta estos estilos y que queremos darle al usuario para que estilice. Vamos a hablar ahora de las plantillas que como decíamos en la disrupción, ¿no? He tocado tanto el mando que ya ha 6 y 6. Juan Hernando, por favor. Aquí, vale. No venga, no venga. Al regalo. Esta es la plantilla index.html del 2022, ¿vale? O sea, este es el sistema de plantilla que tenemos actualmente en los temas basados en bloque. Lo que vemos aquí es HTML y un montón de comentarios. La verdad es que es una locura. Yo cuando he empezado a investigar un poco el tema he dicho, ¿dónde está loop? Pues este es el loop, nuevo de WordPress. El loop de WordPress no es un while es un comentario de HTML. Es un WP query y ahora aquí los argumentos que teníamos en el ARX. Veo que hay gente incluso echándose las manos a la cabeza. Bueno. Si yo tuviera que escribir esto no lo sabría escribir porque hay muchas cosas, ¿no? Que tenemos que tener en cuenta. Aprendimos PHP, aprendimos HTML, hemos aprendido el lenguaje. Se puede aprender. ¿Qué es lo que creo que va a ocurrir? Bueno, voy a dar una solución a esto, no os preocupéis, ¿eh? Pero lo que creo que va a ocurrir es que nuestros editores favoritos, Visual Studio Code de código que usemos tendrán extensiones que nos digan, crea el loop de WordPress, que ya lo hay en PHP, ¿no? Crea el loop de WordPress con estos argumentos y entonces básicamente tendremos como code snippets, ¿no? Que nos facilitarán eso. Creo que es lo que va a ocurrir. Probablemente ya hay gente trabajando en ello, no lo sé. Si alguien quiere trabajar en la sala en ello, adelante que lo comparta. Yo no tengo tiempo, lo siento, pero bueno, sería estar bien. Entonces, si volvemos atrás, pues WordPress query empieza aquí, termina, bueno, aquí es la paginación de WordPress query y termina aquí el WordPress query. Es decir, todo esto es el famoso loop de WordPress. Ahora, pues, con comentarios en los que le metemos los bloques. Por ejemplo, esto es un grupo de Gutenberg. Estos son columnas de Gutenberg. Aquí tenemos metadata, ¿no? De la fecha, por ejemplo, del POS, etcétera. Bueno, si investigamos un poquito de temas basados en bloque, el HTML del 2022, etcétera, son todas las plantillas así. Como decíamos, es una disrucción total de lo que teníamos, pero al menos por fin tenemos un sistema de plantillas. O sea, esto es mejor de lo que teníamos antes. Simplemente tenemos que aprender una nueva forma, un nuevo sistema. Sé que parece, asusta ver esto y decir tengo que crear un loop de WordPress y tengo que aprender una nueva forma de hacerlo o incluso no hay por dónde cogerlo esto porque no tiene lógica. Pero ya hay soluciones. Por ejemplo, el plugin create blockchain. Este plugin, lo que nos haría es nosotros nos vamos a nuestro instalación de WordPress en el local donde la tengamos. Hacemos nuestros bloques, hacemos nuestras plantillas en el full site editing y le decimos que queremos exportar el tema. Y entonces este mismo tema, o este mismo plugin mejor dicho, nos genera las plantillas que hayamos hecho. El indie HTML, el archive, el page barra lo que sea, etc. Entonces, ésta sería la solución que hay actualmente. Creo que es una solución que está para quedarse. Pero como desarrolladores no nos gustan las interfaces gráficas. Entonces no creo que vaya a ser la definitiva. Porque esto lo que requiere es que nosotros como desarrolladores nos vayamos a una instalación de WordPress y nos pongamos hacer cosas, entonces exportemos un tema. Bueno este plugin ya lo puedes instalar. Está en el repositorio. Aquí ponía tengo a apuntar aquí. Aquí ponía el logo y este es el nombre ClipBloxing y la apariencia que tiene es aquí. En apariencia ClipBloxing, estas son las opciones que teníamos por ejemplo. Bueno es interesante que ya tengamos soluciones para luchar contra esto. O para evitar tener que escribir este código directamente. Pero creo que no va a ser la definitiva. Se va a quedar probablemente, no sabemos si se integrará o no en el core, probablemente no, pero aquí la tenemos. Vamos a crear temas basados en bloques. Ahora esa pregunta, no? Queremos crear temas basados en bloques? Alguien en la sala quiere poner un tema basado en bloques en producción ahora mismo en la web de un cliente o bueno en la suya sin la nuestra. Mi web por ejemplo está ahora mismo el tema 2021 o 2020. No vuelvo a valer y no hay nada. Está en el servidor de mi casa alojada. La pregunta es esa, no? Queremos alojar, o sea, queremos crear temas basados en WordPress. Yo ahora mismo no lo haría para un cliente. Yo. Que lo estoy haciendo, sí, pero que no lo haría. Porque lo estoy haciendo en el tema por así decirlo corporativo y me han dado esa libertad, estamos investigando y si en el futuro pues eso no sirve para aprender estupendo. Claro, lo que decíamos. ¿Cuáles son las desventajas de un tema basado en bloques? Pues que le dan más poder al usuario que eso es más peligroso. Ayer citábamos a Alfred. El mayor domo de Batman que decía que un gran poder conlleva una gran responsabilidad. Claro, si el usuario tiene mucho poder lo que puede hacer es romper el sitio. Probablemente si el usuario no tiene experiencia técnica y nosotros le hemos dejado un sitio muy bien maquetado con nuestro editor se pone a mover columnas, se pone a tocar paddings, margins, rompa el sitio por eso tenemos que tener en cuenta todo eso de los estilos. ¿Y cuál es el otro problema? Como decíamos, esto está en completa evolución. A mí me rompe la cabeza que aparezca esto, beta en el core de WordPress cuando instalamos una versión final. Hay un ticket de hecho en el track de WordPress que precisamente pide eso, que se dejen de poner cosas experimentales en el core porque pudiera estar rompiendo lo que siempre hemos defendido lo que siempre nos hemos sentido en WordPress que es la retracompatibilidad. A día de hoy un tema basado en WordPress va a diferir mucho de un mes a otro, de un año a otro porque está en completa evolución. Sería peligroso, bajo mi punto de vista entregarle en llave en mano un cliente un tema basado en WordPress y nosotros desprendernos. Ahora si vamos a tenerlo, si es un tema en completa evolución puede ser que sea una buena audiencia. Esos son los escenarios en los que yo plantearía un tema basado en WordPress. Como decíamos, está en fase experimental hay poco contenido todavía de temas basados en WordPress en español y hay pocos en inglés, pero si os interesa he creado este gist que en 9 minutos o en 8 minutos se publicará un Twitter programado soy hacker en mi cuenta de Twitter un gist con una lista de enlaces que os pueden servir para conocer un poquito más. Todo en inglés prácticamente pero bueno, está el Handbook de WordPress que se puede traducir, así que si buscamos voluntarios para traducir el Handbook de WordPress bienvenidos sean de los temas de bloque y hay uno de los recursos muy interesantes que es FullsiteEditing.com que es de una core contributor que ha hecho la mejor documentación que ya mucha de ellas está en el Handbook de Blockchain, pero ahí hay mucha información. Como decía Juan Hernando soy José Arco, soy desarrollador WordPress en Naciones Unidas bueno, en el centro de computación de Naciones Unidas y trabajo para aquí, muchas gracias por asistir a mi charla. Llevo la misma camiseta, sí pero tienes más y la barba, miren normalmente me afeito no engañas, es mucha marketing es verdad lo que muestras ¿Preguntillas? Aquí seguimos, dicen por aquí Sí Hola, gracias José por la charla al igual cuando salió Gutenberg hubo una gran resistencia por parte de los usuarios desarrolladores, en este caso los veo exactamente igual con lo cual mi pregunta es muy concisa ¿Amerita todo este cambio de paradigma y tecnología para que simplemente el usuario lo mismo que hacía en el vaquen ahora lo haga en el frontend? Sí, de hecho citando a Fernando que hace un ratito dio una charla muy interesante ahí, millones de usuarios o miles de usuarios de Elementor WordPress Backgrey, DB no pueden estar equivocados, es decir, los que necesitan los usuarios al fin y al cabo es eso, es tener el control lo que ahora le está dando el core de WordPress a través del editor de de bloques y toda esta nueva experiencia del full site editing es ese poder a los usuarios que a nosotros como desarrolladores nos asusten es normal, sobre todo a los que hemos trabajado como freelance y los que tenemos que mantener sitios en los que el cliente está continuamente tocando el sitio pero al fin y al cabo era la evolución a la que iba WordPress y si no lo hacía el core de WordPress ya lo estaban haciendo empresas de tercero entonces creo que sí que merecerá y creo que nosotros tendremos que adaptarnos, es decir si queremos algo muy de vero pre-friendly vamos a Laravel y nos vamos a la LaraCon el año que viene en vez de la WordPress sería una decisión horrible claro no sé pero tú puedes compartir una reflexión sobre ello también totalmente de acuerdo hola qué tal sí es una pregunta un poco capciosa porque es como para cambiar la manera como lo planteamos claro, y nosotros estamos desarrollando ya, intentamos estar estamos en Gutenberg, estamos con el FSE y la pregunta que a veces me hago es ¿la pesadilla es para los desarrolladores o es para los diseñadores es decir que lo estamos planteando mucho así pero en realidad yo por lo menos el problema que tengo es cómo garantizarle al diseñador que después cuando el que meta el contenido va a respetar el diseño que él ha preparado y un sistema de diseño, editora hostia que también es otro punto creo una de las charlas de la work on en Estados Unidos que fue hace una semana o no me acuerdo precisamente hablaba de eso, de diseño para el editor de bloques o para el full site editing que tenemos todo depende de la libertad que le queramos dar al cliente al usuario, al administrador del sitio y de lo que nosotros vamos a decirlo así, nosotros como desarrolladores estamos dispuestos a acceder en darle al usuario ese poder, y están dispuestos los diseñadores en darle al usuario ese poder yo creo que es la evolución a la que va, pero hay sitios en los que no queremos por ejemplo un sitio de editorial no queremos que no salgamos de no se, se me ocurre un periódico si ya están definidos los estilos ahí los desarrolladores tendremos que hacer el trabajo como el que citaba antes de TenApp de limitar lo que el usuario puede hacer o no puede hacer entonces yo creo que es más trabajo para nosotros en ese sentido nos facilita el desarrollo de un tema nuevo nos complica la libertad que le vamos a dar a los usuarios creo que saldrán soluciones para eso poco a poco, como decimos, estamos todavía en beta pero saldrán soluciones para limitar de hecho ya se puede hacer, ya se pueden bloquear bloques valga la redundancia en los que decimos que este bloque está sin no lo toques, y luego está algo que se nos olvida casi siempre que es enseñar un poco, no, guiar al aprendizaje a los usuarios finales que el training por así decirlo, el entrenamiento al usuario es casi tan importante como en nuestro desarrollo, si nosotros le entregamos algo al usuario que decimos aquí lo tienes haz lo que te dé la gana con él, seguramente lo rompa porque no sabe qué tiene que hacer con él pero si le dejamos las pautas guiadas pues no tenemos que preocuparnos de la libertad que le hemos dado alguna nuestra pregunta José, llévatelo a ti mismo cuando hablaste de la estructura de las plantillas que hay cambios que ahora pasaron a ser HTML hay mayor intervención del navegador en este caso digamos, hay algún conflicto con ese estándar digamos que el renderizado sigue siendo en el backend entonces el resultado final va a ser casi el mismo porque esta estructura de plantillas aquí al final el cabo no se interpreta directamente porque un navegador no sabe lo que es esto, para un navegador esto es un comentario, es decir que esto lleva un motor de renderización por detrás el código PHP convierte eso en el HTML final así que para digamos, la estructura final de HTML es la misma de hecho ahora es más fácil seguir una buena semántica en HTML porque ahora sí que lo vemos todos antes era pues el Game Template par de un lado, el Game Template par de otro y al final nos llevamos complicando mucho la vida ahora las plantillas son mucho más sencillas y entonces la semántica a seguir es mucho más fácil una última pregunta bueno ahora, dos últimas preguntas bueno José, muchas gracias por la charla ¿qué crees como desarrollador conflictos de maquedades visuales y ahora el full setting que ha sido como un boom para aquellos usuarios que no controlan tanto técnicamente yo creo que ha enriquecido mucho WordPress que tiene una empresa como en su momento visual composter o WP Backery Elementor creo que por citar Elementor me da una camiseta donde está db, beaver, builder etc yo creo que han favorecido mucho el desarrollador WordPress y tenemos el 40% de la web gracias a esos maquetadores que WordPress lo hiciera era cuestión de tiempo yo como desarrollador antes era muy reticente, ahora lo he terminado entendiendo si no puedes con el enemigo, un ETAL que WordPress finalmente ofrezca todo lo que ofrezcan a esos maquetadores creo que no va a pasar y creo que esos maquetadores seguirán teniendo su cuota de mercado y algunos como Elementor pues irán migrando a sus propias soluciones autoospedadas pero yo creo que es sano que si hay ese tipo de plugin que yo no os voy a usar o que los uso limitadamente pero que hay muchos usuarios que tienen ese objetivo Hola, mira la pregunta es respecto a los estilos has comentado que venían unos estilos ya predefinidos en el core y aparte están los estilos de los bloques estos estilos como se gestionan se cargan todos en todas las páginas solo se cargan cuando los bloques se cargan es un poco cargar solo que hace falta que es lo que se debería hacer pues, creo que está en experimental la opción de cargar estilos en línea no sé si ya está a final pero creo que el objetivo y por ahí, para optimizar el código era cargar estilos en línea por cada bloque cargado en la página pero hasta ahora había si no recuerdo mal, en 2021 hasta ahora había un CSS con todos los bloques pero se terminará haciendo que el estilo se cargue inline en la página por ejemplo, si tu usas el bloque de párrafos de columnas y de block quo solo esos estilos se cargarán por lo tanto, reduce mucho el tamaño del HTML final y todo va en el mismo archivo que es en el HTML, no carga otro archivo que sería el CSS y lo veo bien, o sea, hay gente que se ha llevado las manos a la cabeza pero lo veo bien porque al fin y al cabo ayuda a la optimización del sitio bueno, pues, muchas gracias