 Para diseñar y desarrollar con WordPress es importante entender cómo WordPress trata los contenidos y cómo estructura sufronte para que nuestros temas se adapten a nuestros contenidos. Con esta ponencia entenderás cómo funciona un tema de WordPress clásico, su estructura de archivos, su motor de plantillas, las jerarquías de contenidos y sobre todo cómo se adaptará a todo esto en el futuro cercano a Gutenberg. Bueno, futuro cercano, no, el presente. Bueno, esta charla nos la va a dar Dario, que es diseñador y desarrollador web experto en WordPress, formador tanto en LinkedIn, LinkedIn Learning como en su plataforma personal de cursos de WordPress y PostCaster en PostEye Podcast que hace con el amigo Juan Cadillaz. Como diseñador y desarrollador Wix en actualidad blog donde gestiona más de 50 sites de alto rendimiento. Hola, ¿qué tal? Buenas tardes. No se te oye, no se te oye, el micro lo tiene desconectado mientras tanto voy a comentar, oye es el día de los problemas, ahora sí, Dario, mientras tanto voy a comentar hoy es el día de los problemas que la charla de Gerardo, Gerardo que la ha dado, ha dado completa, se ha quedado guardada y sin problema se va a publicar a las 7 y 20, ¿vale? A las 7 y 20. ¿Qué quiere decir esto? Que vamos a tener cinco minutitos menos de preguntas, Dario, te voy a meter prisa, ¿vale? Entonces nada, simplemente recordaros que cuando por acortar un poco la zona de preguntas y acotarlo lo máximo posible, que sepáis que cuando acabe la charla tendréis a Dario en las salas de Zoom para que hable con vosotros y demás, ¿vale? Y para las preguntas que no den tiempo. Efectivamente, para las preguntas que no den tiempo, os metéis ahí y demás. Pues nada, Dario, te dejo con la familia. Perfecto, muchas gracias. Pues hola a todos, bienvenidos a esta ponencia donde vamos a hablar un poco de anatomía de un tema de WordPress. Básicamente ya me han presentado, pero a modo resumen, soy diseñador de desarrollador especializado en WordPress, WooCommerce, todo el ecosistema WordPress. Como proyectos personales, ahora mismo estoy en post-type podcast. Hasta mí me cuesta pronunciarlo con Juan Cadíaz que anda por ahí por el chat. Un saludo. Y también ando con Labs, que es, digamos, como una plataforma, un club privado, una academia online diferente donde hago directos trasteando con códigos, rompiendo cosas, sobre todo rompiendo cosas. Y nada, en esa estamos. También ando de formador en esa propia academia y en LinkedIn Learning que también me cuesta pronunciarlo a mí. Y nada, yo vengo a hablar de temas de WordPress para que entendáis, sobre todo antes de empezar a hacer un tema o a modificar un tema, que entendáis cómo funciona toda esta arquitectura que hay por detrás de WordPress, el motor de plantillas, cómo se comporta, la lógica que hay detrás para que podáis modificarlos o incluso crearlos desde cero. Lo primero que hay que entender es que es un tema de WordPress. Y al final, el resumen de Wikipedia que todos conocemos es que es un conjunto de ficheros que nos permite cambiar la apariencia y funcionalidad de nuestro sitio web hecho con WordPress o lo que es el aspecto, la parte visual de WordPress, ¿vale? Toda la parte front. Dependiendo de qué diseño le demos o qué funcionalidad le demos, podemos crear blogs, podemos crear sitios web corporativos, podemos crear tiendas online, catálogos, lo que nos de la gana, ¿vale? Digamos que en este tema, de este tema, depende la funcionalidad al final del sitio web. Que no os engañen porque al final un tema con dos ficheros lo tenemos construido. Está el CSS e index PHP. El index PHP se encarga de traer toda esa funcionalidad que le consultamos a WordPress y él está el CSS de darle diseño o apariencia a toda esa información. Pero la realidad es que tanto uno como el otro son imprescindibles, no es que si le quitamos el style simplemente se vea feo y ya está. Y es que en el core, en el propio core de WordPress, hay una función que se encarga de comprobar que existe un style CSS. Si no existe un style CSS directamente nos va a dar un error en la pestaña de apariencia de WordPress de este tema hasta corrupto. La parte fundamental de un style CSS es el código. El código sobre todo la parte superior, que es el comentario que tiene toda la información de ese tema. Quien lo ha creado, que versión es la licencia, tags, descripción, todo eso que vemos cuando vamos a apariencia en un tema. Lo habréis visto mil veces dependiendo del tema que estáis instalando. El index es la plantilla más genérica. ¿Y por qué digo plantilla más genérica? Porque hay otras muchas, ¿vale? Pero tenéis que entender que el index solamente se ejecuta si no hay otra plantilla más específica para el contenido que queremos visualizar. Es decir, tenemos una jerarquía de contenidos o una jerarquía de plantillas. Lo primero que tenemos que entender es que WordPress funciona en base a la URL que le solicitamos y a la configuración que tiene asignada en el panel en ajustes de lectura. Básicamente WordPress, cuando le solicitamos por URL un contenido, consulta según la columna de la izquierda. Es la home, es el front page, es un 404, una página de búsqueda, es una categoría, un autor que me estás intentando pedir qué contenido quieres. En base a eso empieza a buscar la plantilla más específica para ese contenido y va desplazándose hacia la derecha hasta llegar al índex PHP, que es la más genérica. Es decir, si no hay ninguna que se haya encontrado antes, utiliza el índex PHP. Un ejemplo rápido. Intentamos abrir la categoría Noticias. Category Guión Noticias.php. Si ese archivo no existe en nuestro tema, vamos a Category Guión 33, suponiendo que el ID de esa categoría sea el 33.php. Si tampoco existe, abrimos el genérico, que es Category PHP, que aplica todas las categorías de WordPress. Que no existe, Archive PHP sería el más genérico para este tipo de contenido. Y finalmente, si este tampoco existe, abriríamos con índex PHP. Creo que es bastante sencillo, bastante gráfico cómo funciona el flujo de jerarquía de plantillas y tenéis que tenerlo muy en cuenta. Yo esto me lo imprimí cuando empecé para entender cómo funcionaba la jerarquía de plantillas. Quiero que entendáis que hay diferentes tipos de plantillas. Por un lado tenemos las plantillas estructurales, las típicas que usábamos en PHP y PHP, por ejemplo, con includes, para no repetir contenido sobre todo. Se corresponden con el geader, el footer, el sidebar y otras cosillas que veremos más adelante. Y la función principal es evitar duplicar contenido. Es decir, no tenemos que tener este contenido 30 veces y cada vez que queremos modificar el geader tener que modificar 30 archivos, sino que modificamos geader PHP y tenemos modificado ese geader en todo el site. Footer y sidebar son otros dos ejemplos, ¿vale? Básicamente de forma visual, si una web fuese esto, tendríamos el geader, sidebar y footer, ¿vale? para que tengáis el esquema visual en la cabeza. Pero también tenemos plantillas de contenido. ¿Véis ese contenido en blanco? Pues ahí van las plantillas de contenido. Y es que esas plantillas de contenido corresponden concretamente y exactamente al contenido que estamos intentando visualizar. Home PHP, Page PHP, Single PHP, Archive PHP. Y estas son las plantillas de contenido nativas de WordPress. Esto lo interpreta WordPress de forma nativa. Como digo, son específicas del contenido que vamos a mostrar. Y hay un montón de ellas. O sea, para casi cualquier tipo de contenido que imaginéis en WordPress tenéis ahí una plantilla específica, un error 404, un Archive, un Category, una taxonomía, un Single Search, lo que es de la gana. Simplemente hace falta saber un poquito de inglés para entender cuál sería la plantilla que queremos utilizar. Os dejo un enlace con toda la información del motor de plantillas, donde tenéis todos. Y además, vamos a ver la especificidad de las plantillas. Es una palabra bastante complicada, pero que define muy bien lo que pasa con estas plantillas. Y es que todas las plantillas genéricas pueden ser mucho más específicas gracias a estas terminaciones. Es decir, imagina que tenemos Page PHP que ataca todas las páginas de WordPress, a todos los tipos de contenido página de WordPress, pero queremos atacar solo a la página de contacto. Eso podemos hacerlo con PageGionContacto.php o con PageGion47, si el id fuera 47, y de igual manera con todas las plantillas que hemos visto antes. AutorGionDarioBf.hp sería mi página de autor en ese WordPress, CategoriegionNoticias.hp sería para la categoría de noticias, y así sucesivamente. Pero además, si esto se nos queda corto, que fijaos que ya da mucho juego, podemos crear nuestras propias plantillas con un simple comentario en PHP en la parte superior de la plantilla, TemplateName y el nombre de la plantilla, podemos crear nuestras propias plantillas. Por ejemplo, TemplateNameContacto sobre mí o lo que nosotros queramos, y el archivo se llamará como nosotros queramos también. Como veis, es bastante potente y bastante sencillo de entender más o menos. Otra parte vital del motor de plantillas o del sistema de plantillas de WordPress, el loop. Habréis oído hablar del loop de WordPress, del loop de query, de mil historias que se mezclan por ahí, pero en resumidas cuentas el loop de WordPress es el que determina qué contenido debe mostrar en base a lo que le hemos solicitado por URL y la configuración que tenemos asignada en el váctem. Básicamente, ese loop va a buscar contenidos y mientras haya contenido que mostrar, vuelta y vuelta, vuelta y vuelta. Esto es lo de siempre, ¿no? Me llaman bucle, ahí pronto entenderás por qué, me daré cuenta de qué, de qué te llaman bucle, efectivamente, me llaman bucle, ¿no? Y empezamos otra vez, muchachada, no, y ahí a tope. Básicamente, busca el contenido que queremos mostrar y vuelta y vuelta hasta que se queda sin contenido para mostrar, si estaba por paginación, pues mostrar a paginación, etcétera, etcétera. Este loop, más o menos, es sencillo de entender. Tiene un if, si hay artículos, empezamos a mostrar y mientras hay artículos mostramos uno y otro y otro y otro y otro y en caso de que no haya, mostramos un error de que no hay contenido para mostrar. No es complejo, pero hay que entender básicamente porque es el corazón del contenido en WordPress, ¿vale? Otro archivo importante de nuestros temas, Functions PHP. Aquí metemos todas las funcionalidades propias de ese tema y repito, propias de ese tema y es que, aunque sea el último punto, quiero recalcarlo lo máximo, solamente se ejecuta cuando el tema está activado. Si cambiamos de tema, todas esas funcionalidades las perdemos. Nos curramos un custom post, nos curramos un backend brutal, nos curramos lo que queramos. Si cambiamos de tema, esa funcionalidad se ha perdido. Esas funcionalidades que son propias de ese sitio web, por favor, llevároslas a un plugin y entiendez que esto se muere, ¿vale? Básicamente es fácil entender, es un fichero, se comporta como un plugin, es decir, podemos añadir mejoras y funcionalidades al todo el site y puede ejecutar funciones, tanto del propio WordPress, del API de WordPress como de PHP. No hay mucha complicación. Una de las formas de cambiar configuraciones por defecto de WordPress, ya sabéis que WordPress hace muchas cosas de forma nativa, pues esas configuraciones las podemos matizar desde este fichero. Como digo, las cosas propias del site a un plugin para que no mueran cuando cambiemos de tema o rediseñemos el site, ¿vale? Si no, ya sabéis, ahora que están tan de moda, están estos espezantes por si usáis el fontios PHP y cuidadín, ¿eh? Que estos, cuando visitan, no perdonan. Modularización, otro aspecto clave del diseño o desarrollo de temas de WordPress. Y es que el dividir y vencerás sigue siendo una máxima hoy en día. Y es vital dividir en archivos, organizar los archivos, tenerlo todo lo máximo lo máximo organizado. ¿Por qué os voy a hablar de modularización? Os he puesto aquí el típico minijuego de átomo, molécula, ecosistema y todo esto que está ahora el Tommy Design, que básicamente lo que dice es reutilizar el código en diferentes plantillas, ¿vale? En WordPress, ¿cómo hacemos esto? Con un template part y con el get template part en la parte donde queremos recuperar ese contenido. Básicamente son funciones nativas de WordPress, ¿vale? Son los incluides de PHP hechos por WordPress. Lo bueno que tienen es que son compatibles con ChildDems y con todo el ecosistema de WordPress. Es decir, si hacemos un incluide en un tema y luego hacemos un ChildDems ese incluide se va a romper. Sin embargo, si lo hacemos con template part va a funcionar por la compatibilidad entre tema hijo y tema padre. ¿Qué son las template parts? A modo de resumen. Podemos modularizar y es compatible con ChildDems, como digo. Básicamente tenemos que crear un archivo con un nombre punto PHP, por ejemplo, artículo punto PHP que sería el template part genérico y si queremos hacerlo un poco más específico podría ser, por ejemplo, artículo guión home o artículo guión contenido, lo que nosotros queramos. Y ese sería un poquito más específico. Es decir, seguimos teniendo un poco esa jerarquía de contenidos que hemos visto antes incluso dentro de los propios template parts. Y es que un ejemplo muy claro de esto son las típicas cartas, cartas que mostramos en la home, mostramos también en el blog y mostramos en otros sitios. Esto lo que hacemos es especificar artículos punto PHP es, por ejemplo, para el single mientras que artículos guión home es para las cartas de la home. Artículos guión blog sería para las cartas del blog y así sucesivamente podríamos especificar todo lo que queramos. ¿Cómo recogemos ese archivo donde hemos metido un trozo de código diferente con esta función de aquí? Get template part y llamamos al Slack y al name de especificidad en caso de que lo haya. ¿Vale? ¿Qué queremos traer los artículos, el template part para los artículos de la home? Get template part, article home y eso nos trae ese archivo que hemos creado anteriormente. ¿Por qué os explicó esto? Porque hay que organizar los temas. Que un software sea sostenible o sea mantenible que el tiempo significa que está organizado. Si no lo organizamos, cuando retomamos Darío, Darío se está cortando el audio. Mira a ver que sí, está con las manitas y hace y de repente hace han llegado los negros. A ver, habla, habla. Hola, hola, probando. No te muevas más, venga. ¿Qué vamos a organizar? ¿Qué vamos a organizar? ¿Qué vamos a organizar? ¿Los assets o estáticos? ¿Archivos TSS? Se sigue cortando, Darío. Ha sido ponerte y ha hecho así. El cable de los chinos, no he tocado nada. Ahora, quieto. Perfecto, pues sigue. Venga, seguimos. Como decía, vamos a organizar los assets y estáticos, los template parts y los customs. Vale, todos los archivos están en customs. Los vamos a organizar también en carpetas. Hay muchas organizaciones y cada uno tiene que buscar la suya. Básicamente yo te aconsejo que tengas dentro de tu tema una carpeta de includes donde metas todas las librerías o cosas externas de PHP que vayas a utilizar. Los assets donde metas una carpeta con los JavaScript, con los TSS, con los web fonts, con todo lo que tengas. Y una carpeta para los template parts y así los tienes localizados y fácilmente accesibles. Y luego, en la misma raíz tengas todo lo demás, tengas todas las plantillas que componen tu tema. Y llegamos al punto clave, ¿vale? Hid un poquito rápido para llegar a esta parte. Gutenberg. Todo esto como os ha aprendido, muy guay, PHP, que template parts, todo este tema, muy bien pero ahora está cambiando la cosa. Ahora estamos con Gutenberg, Gutenberg para acá, bloque para allá, conjunto de bloques, bloques reutilizables, un montón de cosas nuevas y diferentes. ¿Cómo afecta esto a la anatomía que acabo de explicar? Básicamente, se viene el full site editing. Esto es que vamos a poder editar todo el sitio a través de Gutenberg, ¿vale? Pero para que entendáis cómo funciona esto es una fase experimental, es decir, tener en cuenta que todavía están desarrollo, que todavía están estamos trabajando en ello, como diría alguno, ¿no? Básicamente ahora mismo si instalamos el plugin de Gutenberg, el plugin que no el core, lo que hacemos es ir a la configuración de Gutenberg y activar esa opción que pone edición completa del sitio, dentro de experimental, ¿vale? Como resumen rápido, sigue la misma jerarquía de plantillas, no se llaman plantillas como tal, sino que se llaman block templates y la misma idea de template parts con una ligera, con un ligero matiz, y es que ahora se llaman block template parts, como veis está todo orientado a bloques, ¿vale? Estos templates se crean con Gutenberg, directamente se copia su contenido y se guarda un HTML plano, y lo vamos a ver. Esto significa diosa PHP, vamos a ver un poco después todo esto, ¿vale? Cambio respecto al tema tradicional, antes comentábamos que teníamos una organización con todos los template parts, con todo el tema, con todo lo que llevábamos ahí, ahora aparecen un par de carpetas nuevas, una es block templates y otra es block template parts, que es donde Gutenberg va a buscar esos template parts cuando activamos la edición completa del site. Dentro de esas carpetas vamos a tener HTMLs planos, que se han generado desde el propio Gutenberg, es decir diseñamos con Gutenberg, copiamos, vamos a la parte de código de Gutenberg, copiamos todo ese contenido y lo guardamos en un índice HTML, en un single HTML, en un page HTML, si os dais cuenta los nombres son iguales, las plantillas son las mismas funcionan exactamente igual, y los block template parts de igual forma geader HTML, footer HTML y demás. Como veis todo esto es bastante nuevo, están todavía desarrollándolo y vamos a ver cómo avanza, pero el futuro es todo bloques obviamente. Block template parts, como decía geader HTML, footer HTML y sidebar HTML, básicamente las plantillas estructurales que os he explicado antes. Si volvemos a la parte visual corresponderían a esto, antes eran PHP y ahora son HTML, el funcionamiento es exactamente igual, de igual manera block templates o las plantillas que tenemos por ahí en el motor de plantillas clásico, home HTML, page HTML, single HTML, archive HTML, etc. Son específicas de ese contenido que vamos a mostrar, exactamente igual funciona igual. Pequeños matices template definido en el backend se carga a los block templates que generemos en el tema, ¿vale? Aquí tenemos una edición nueva que funciona desde el propio backend desde el backend de WordPress podemos ir a las plantillas de Gutenberg y modificar ahí esas plantillas ignorando las que tenemos creadas en el tema. Así que hay que tener cuidado con esta jerarquía nueva que se añade a la que veíamos anterior. Ya no vamos plantilla por plantilla sino que directamente si hay una en el backend las demás las ignoramos, ¿vale? Digamos que es un nuevo nivel. ¿Alguna duda que se nos plantea o que se nos puede plantear? ¿Cómo va a funcionar el loop? Y es que todo está en desarrollo, así que todos son dudas. ¿Cómo va a funcionar el loop? La paginación la especificidad de las plantillas personalizadas, todo esto que acabo de explicar ¿Cómo va a ir ahora? Pues básicamente funcionará muy parecido pero con bloques. Es decir, si queremos hacer un custom loop, tendremos que hacer un bloque que responda a esa necesidad. Si queremos hacer una cosa especial, tendrá que ser un bloque que responda a esa necesidad y es que todo va a funcionar con bloques en este nuevo sistema. ¿Significa que esto va a cargarse los temas tradicionales? ¿No tiene por qué? Son dos formas de trabajar diferentes lo que se está hecho en PHP, los temas clásicos funcionan con base PHP también, son formas de trabajar diferentes lo que se supone que viene para esto es digamos para facilitar la entrada del usuario medio, entonces yo creo que está bastante guay. ¿Alguna referencias o enlaces de interés? Y ya con esto termino, por un lado el handbook del propio Gutenberg donde tenéis ahí explicado todo esto de la nueva etapa de Gutenberg y cómo va a funcionar, y el repositorio de GitHub donde están haciendo 10 experiments donde ya está por ejemplo 2020 adaptado a 100% temas bloques y hay cuatro más creo que son, a mí me gusta de vez en cuando echarle un ojo y sobre todo hacer pruebas con ello y tal y oye, pues lo echáis un vistazo y hasta aquí la presentación espero que haya quedado claro, cinco minutos de pregunta con Matrón, ¿has visto? Me ha portado bien yo creo. Ha quedado clarísimo Oye, está pasando todo bien, perfecto, aviso de entrada que he dicho antes que en la charla de Gerardo era la 720, no mentira mentira cochina, vamos a ponerla a las 18.50, de ahí que vamos a quitar cinco minutos de echarla, cinco minutos de la siguiente que va a presentarnos y después vamos a meter la charlita de 10 minutos de Gerardo que no se ha perdido porque tenemos unos técnicos que no nos los merecemos, son los mejores el equipo de streaming tremendo, bueno pasamos pasamos al turno de preguntas ¿Qué opiere la pregunta? ¿En las plantillas recomendarías estructurar el código por la función que se realiza o que realiza? Más o menos entiendo por donde va la pregunta, pero yo diría que no, o sea, las plantillas las tienes que estructurar en base a lo que van a visualizar, o sea, si van a visualizar este tipo de contenido, que respondan a esa visualización, si van a responder a otra visualización, que vayan a esa visualización. La funcionalidad como lo digo, si puedes, en el 99% de los casos debería de ir a un plugin. Funcionalidad en el tema caca, vienen los del meme estos, a verte. No, la funcionalidad en los temas, es lo mejor que existe. Bueno pues David Pérez vuelve a preguntar, una pregunta. Ah no, lo ha preguntado dos veces y me ha despistado, muy mal, David Diego, ¿qué digas? Marta Torre pregunta ¿Cuándo recomiendas hacer plantillas de página personalizada y cuándo usar una plantilla global para todas? Sí, responden a una necesidad global que sea genérica, si es algo muy específico, muy concreto lo haces personalizada. Yo suelo hacer personalizada, la típica contacto.php cuando es una que está muy elaborada por ciertas métricas o porcientos análisis y la necesito reciclar si o si a futuro en el mismo proyecto porque tiene unas necesidades muy concretas. La típica es muy difícil que utilices hoy en día una plantilla tan específica, pero una página de contacto, donde tenemos un mapa con una API, con lo que sea bien podría ser una plantilla personalizada para ese caso concreto, ya que en ese proyecto va a seguir funcionando a través de un contacto, o sea de ese sistema. Imagina que funciona con una pinterna de, yo que sé déjelo localización de cosas muy chungas que se ven por ahí. En ese caso concreto pues debería de ser específica y debería mantenerse como tal. Ahora mismo hay dos preguntitas de la misma persona así que voy a leer las dos preguntitas y vamos a acabar por aquí, ¿vale? Porque nos pilla el toro, que nos pilla el toro viene por ahí corriendo. OneRoll dice el código que has mencionado en tu exposición se carga todo al mostrar mi sitio al usuario y después ha preguntado cuando desactivo y borro el plugin se borra ese código de mi sitio web también se borra las tablas de la base de datos y si no ¿cómo hago para borrar lo que ya no uso? Todo lo que vuelques en las plantillas todo lo que vuelques en las plantillas se va a visualizar al usuario siempre y cuando no lo metas en condicionales que restringan esa visualización es decir, tu aguerpes le puedes preguntar ¿el usuario actual es un administrador? porque si no no quiero mostrarle cierta información entonces si no haces ese tipo de cosas por defecto va a mostrar todo lo que muestra en la plantilla en relación a las otras preguntas si desactivas y borras un plugin el código desaparece obviamente porque estás primero desactivando con lo cual WordPress no lo va a intentar cargar y si lo borras directamente el código ya no está ni en el servidor, entonces desaparece también se borran las tablas las tablas de la base de datos si el que ha programado el plugin lo ha programado bien sí, porque hay un hook precisamente que se encarga de esto de cuando desactivamos desde el backend un plugin o incluso lo eliminamos que borre todos sus registros y que lo haga como debe ser si lo borras desde FTP directamente pues no va a conseguir ejecutar esa función pero si está bien programado y cosa que debería o deberían hacer todos los plugins, sí que eliminaría todo su registro para no dejar su huella bueno pues nada perdón por las prisas pero ya tenemos que cortar recordo las preguntas que queden ahí estaremos FTP, te meteros en la sala de zoom y seguís con las preguntas que hayan quedado en el tintero bueno pues muchísimas gracias a Zario ha sido todo un honor y un placer estar aquí presentando a vosotros y gracias a los del chat que han felicitado porque les ha gustado la ponencia más alegro que les haya gustado y para lo que necesiten perfecto