Así se hizo la web de WPMálaga en 2024

Tras más de 10 años de vida de esta Comunidad, tocaba retomar el viejo drama de no tener la web WPMalaga.org en condiciones. Bueno, tras 8 años de mantener una página estática con un texto de bienvenida y los enlaces a Telegram, Slack, etc., se puede decir que ya tocaba dedicarle un poco de atención.

Entre los que estábamos en este Templo Jedi de WP empezamos a aportar ideas y posibles themes, constructores, etc., pero quedó claro antes de empezar que el compromiso debía ser mantener la web al margen de licencias, plugins de pago y todo servicio que pudiese ocasionar en el futuro un problema de mantenimiento. Por ejemplo, hablando abiertamente, que alguien pusiese una licencia y después decidiese salir de la Comunidad por cualquier motivo.

El escenario era trabajar con casi lo nativo que trae WP, es decir, editor de bloques o la palabra maldita que algunos odiamos: Gutenberg. Por primera vez en muchos años tendríamos que salir de la zona de confort de los themes y builders a los que estamos acostumbrados, ya que lo primero que pensamos alguno fue: “bueno, la montamos con Astra y sus Spectra Blocks o Kadence, tampoco pasa nada”.

Pero no, ya que Astra free es tan básico que no tiene Full Site Edit, por ejemplo. Y para editar en modo Full Site tienes que instalar Gutenberg y un theme compatible. Te acostumbras a algo que ya consideras tan básico, y es que cuando tienes tus flujos de trabajo y tu manera de hacer las cosas, te olvidas de que son herramientas premium, y tienes que volver a aprender cómo se trabaja en WP de manera nativa.

Gutenberg, el builder nativo de WP

En ningún momento nos planteamos utilizar ningún builder, desde luego ni Elementor, ni Divi ni Bricks ni algo así, respetemos el purismo y mantengamos el Templo libre de esas mierdas. Pero lo de Gutenberg necesita que alguien le diga al rey que está desnudo, tantos eventos con Matt y parece que nadie es capaz de decírselo.

No voy a explayarme, porque quienes me conocen saben que odio profundamente a Gutenberg y que considero que está lastrando a WP, así que como estoy más guapo callado, corramos un tupido velo y continuemos.

FrostWP, un theme básico con patrones y FSE

Nos pusimos manos a la obra en la búsqueda de un theme que fuese free, que no tuviese una parte premium (para no quedarnos con la miel en los labios), y sobre todo, que tuviese out-of-the-box la funcionalidad de Full Site Edit, ya que tendríamos que editar no solamente la cabecera y footer, vamos a crear tipos de contenido personalizados y necesitaríamos poder editar sus plantillas específicas.

Tras probar varios themes, encontramos FrostWP, un theme que tiene muchos patrones, una configuración básica, y sobre todo, nos da tranquilidad porque no tiene una versión de pago.

Lo de FrostWP es de traca, siendo de los más valorados, cuando te lo instalas y empiezas a trastearlo te das cuenta de que en el fondo es MUY MUY básico, ni tiene página de opciones, ni tan siquiera te habilita los Menús. Cuando intentas entrar en Apariencia -> Menús y ves que no existe, empiezas a preguntarte por qué es la primera vez que esto sucede después de trabajar en cientos de webs de WP… y es que ahora se hace desde el Full Site Edit.

Al final, después de valorar lo de FrostWP y aunque sea el Dacia Sandero de los themes, y como había que escoger alguno, decidí por mi cuenta tirar para adelante con este, a ver hasta donde llegábamos y no mirar atrás. Nos casaríamos con FrostWP y ya está.

La estructura de contenidos. Los Custom Post Types

Uno de los objetivos de la web era dar la información sobre las Meetups y actividades de la Comunidad: listarlos, dar reconocimiento a los ponentes, tener una web completa al margen del grupo en Meetup.com, que tuviese entidad propia.

No hace falta decir que en una comunidad de WP, que no tuviésemos una web y dependiésemos de servicios como Meetup.com era bastante imperdonable.

A la hora de estructurar contenidos propusimos hacer 4 custom post types que estuviesen relacionados entre sí.

1. Meetups
2. Ponentes
3. Lugares
4. Patrocinadores

Aunque como es normal, cada uno tendría sus campos custom, sobre todo prestemos atención a las relaciones entre ellos, que en principio serían de muchos a muchos (many to many)

Es decir, un meetup puede tener varios ponentes, varios lugares (aunque no es lo normal), y varios patrocinadores. Y a la inversa, un mismo ponente, lugar o patrocinador estará vinculado a más de un meetup. Todos se relacionan de manera bidireccional con campos tipos “relationship”. Dependiendo del enfoque, esta relación se puede definir como “parent-child” o simplemente como “relationship”, como en este caso, donde no habría padres ni hijos.

Esta es la estructura de CPT que planteamos:

Para crear los Custom Post Types, cada maestrillo tiene su librillo. Nosotros en el estudio utilizamos JetEngine, un plugin comercial de Crocoblocks, que es una maravilla porque tiene bloques, se integra bien con Elementor y Bricks, y además disponemos de licencia lifetime y multisitio. Estamos muy acostumbrados a JetEngine y aquí lo echaríamos de menos, pero antes de conocerlo usábamos Pods Frameworks, el plugin más free que te puedes encontrar para estas cosas.

Con unos cuantos años de trayectoria, este plugin es veterano y permite crear los CPT, custom fields, custom taxonomies, templates, etc.

Como había olvidado cómo trabajar con Pods, este proyecto me ha servido para reencontrarme con él, que aún lo tenemos en muchos sitios antiguos, y recordar cómo trabajábamos antes.

Creados los CPT y los correspondientes Custom Fields en cada uno, hicimos también los cambios relacionales y comprobamos que al crear Meetups, Ponentes, Patrocinadores y Lugares y conectarlos entre sí, la relación podía verse desde ambas partes de manera recíproca:

Un vistazo por el diseño y primeros pasos

Como se unieron algunas compañeras y compañeros al Templo, pensé hacer un vídeo de on-boarding y explicar lo que veníamos haciendo, cómo son las maquetas y lo que teníamos hecho hasta ese momento.

Si os queréis ahorrar los 60 minutos que dura el vídeo y cómo me meto en un jardín sobre la paridad, aquí os dejo unos pantallazos de la maqueta realizada en Figma.

Con esto ya más o menos definido a nivel visual, empezamos a trabajar en equipo por un lado introduciendo la información, por otra parte realizando las consultas a base de datos, y por una tercera vía dando estilo a los diferentes bloques.

En la medida de lo posible hemos usado los bloques que ofrece Pods, no obstante es complicado trabajar las consultas en las que se saca más de 1 item de diferentes CPT, como por ejemplo los listados de Meetups que sacan datos relacionales de ponentes, lugares, etc.

Para esos casos hemos definido dentro del functions.php del child-theme unos shortcodes que consultan la base de datos y ya nos devuelven el un bloque HTML con todo dentro: divs, imágenes, enlaces, textos, etc.

Hay otros casos en los que hemos usado los templates de Pods, como por ejemplo, en generar el bucle dentro del grid de Meetups o de Ponentes. Para los que uséis JetEngine, me estoy refiriendo a los Listing grids.

Esta combinación de código, shortcodes, templates y bloques es un poco compleja de explicar, pero hemos seguido la norma de complicarnos la vida lo menos posible. Si vemos que con templates de Pods nos vamos a liar mucho, lo hacemos a código. Por ejemplo, hemos creado funciones que devuelven la fecha en un formato más amigable, como “Viernes 21 de junio”, en lugar de “24 junio, 2024”. Eso lo hemos hecho a través de shortcodes, no con Pods.

Sobre el Full Site Edit: la muerte a pellizcos

Como sabéis, desde hace un tiempo WordPress incorporó el Full Site Editing, y luego fue bautizado como Site Editor, pero ya sabéis, aunque la mona se vista de seda, sigue siendo igual de confuso y mal enfocado. No voy a repetir lo de siempre, pero a veces vendría bien mirarse un poco el ombligo y fijarse en cómo lo están haciendo Elementor o Bricks, ya que el editor es muy poco intuitivo y por si no os los esperábais, aquí viene otro giro de guión: utiliza Gutenberg.

Basta de quejas, esto son lentejas y es lo que hay. Hemos creado plantillas para la home, para el archivo de meetups, para el archivo de ponentes y archivo de blog. Y plantillas individuales para las meetups, ponentes, lugares y posts.

Como partes de la plantilla tenemos 1 header y 1 footer, paremos de contar ahí.

Hemos definido algún patrón con bloques que se han usado en más de una página, así podemos instanciarlos y editar globalmente para que se aplique a todos.

El ejemplo más claro es el bloque de “Síguenos”, con su biznaga de fondo. Sí, es una biznaga.

Mi opinión sobre este tema es que el editor de bloques no está pensado para el usuario final ni de coña. Pero es que para los diseñadores tampoco. En todo caso, para desarrolladores que ponen poco interés en el diseño o que no les importa que su diseño sea tremendamente aburrido y falto de opciones.

Y le falta tanto, tantísimo, que hoy día para mí no es una opción válida para trabajar. Ojo, como siempre, es mi opinión como cuñadísimo de WP.

CSS y Media Queries

Para terminar, tuvimos que arreglar bastantes estilos en CSS dentro del custom.css del child-theme. Sí, tuvimos que hacer un child-theme con un plugin de usar y tirar, porque FrostWP no trae child-theme.

Tampoco trae opciones responsive, así que a base de Media Queries ha quedado una estupenda hoja de estilo con varios breakpoints.

Qué difícil es salir a trabajar fuera de tus themes conocidos, ya que en lo referente a las opciones, configuraciones de maquetación nativas, WordPress es un auténtico páramo si no comienzas por instalar un buen theme, para empezar. La curva de aprendizaje es tan empinada que si no fuese por los themes de pago, builders y demás, dudo que hubiese alcanzado la cuota de mercado tan enorme que tiene.

Y por si acaso, quiero aclarar que usar themes de pago no significa usar themes multipropósito de Envato. Me refiero a nuestros queridos Astra, Generate Press, los starter themes que tantas opciones de personalización tienen, aquí son unos benditos y se les echa de menos como a una madre, con sus opciones responsive, sus configuradores, etc… ay, qué morriña!

Acelerando, que es gerundio

¿Cómo entregar una web sin optimizar? Nos lloverían palos. Así que ya sobre la bocina empezamos a buscar un plugin para caché bueno, bonito y gratuito. Y otro para optimizar las imágenes y servirlas en formato WEBP. ¡Cómo añoro mis queridos WP Rockert, Perfmatters e Imagify, con sus preciosas licencias y qué a gusto las pago!

Estuvimos probando el como Hummingbird y Smush, con resultados muy malos, casi tan malos como no usar nada.

Finalmente hemos instalado WP Fastest Caché para opciones de caché en general, y para convertir y optimizar imágenes un plugin gratuito llamado Converter for Media.

Dentro de lo gratuito, petardean bastante, sin ir más lejos el día de la presentación de la web dejó de funcionar el menú responsive de móvil, fue borrar caché y de nuevo volvió a aparecer. Ya veremos cómo va, que si no le quitamos la aceleración y tan panchos.

Se puede optimizar más, pero a mí con esto me vale.

Chorprecha final: la accesibilidad

Como guinda, ¿a quién no le va a gustar cumplir con la norma de accesibilidad WCAG 2.1 nivel doble AA? ¿A quién no le va a gustar? Después de hacer un testeo, solamente nos marcaba algunos pequeños fallos de contraste y alguna imagen que no tenía atributo ALT, así que esto fue un juego de niños.

En cuestión de 1 hora más o menos ya pasaba el testeo de WAVE sin ningún error. Pero esto no cae del cielo: es consecuencia de hacer el trabajo teniendo en la cabeza las buenas prácticas, el trabajar enfocado en una buena experiencia y mirar de reojo al SEO. Porque las buenas prácticas on-page enfocadas a la accesibilidad también son fantásticas para el SEO…

Conclusión

Pues nada, este es más o menos el recorrido que hemos hecho los compis de WP Málaga. Yo me he puesto el primero porque soy tan mandón que he propuesto el theme, la estructura de diseño y bastantes cosas sobre el estilo de la web. Me he metido en todos los fregaos donde me podía meter a opinar.

Mis compañeros de aventuras en esta web Héctor López, Fran Calderón, Simón Serrano, Jorge Gaspar y Angie, en primer lugar muchas gracias por aguantarme en el grupo con mis frikadas, no dudéis que juntos sacaremos esto adelante y será una web de referencia dentro de la Comunidad WP.

Como Bonus Track, os dejamos con “Bloques a Go-go”, la canción de SUNO elaborada con IA por @antitodo (quién será ese loco):