Mi carta a los Reyes Magos de WordPress en 2024

Termina un año bastante activo a nivel de comunidad en la zona de la Costa del Sol, la zona donde vivo. En este momento hay activos 3 Meetups diferentes, en Málaga capital, Marbella y Alhaurín de la Torre, y con buena participación por parte de los compañeros, que han continuado dando vida a un grupo muy estable que siempre aporta lo mejor.

Este año incluso hemos tenido la visita de la Alta Mesa de WordPress, incluyendo al mismísmo Matt, al cual tuvimos la ocasión de conocer en persona en Fuengirola hace un par de meses.

Incluso algunos compañeros de comunidad estuvieron presentes en Madrid en el State of the Word, en la primera vez que se celebra fuera de USA. Se podría decir que, aparte del buen clima, los «popes» de Automattic algo habrán visto para volcarse tanto con la comunidad de nuestro país…

A lo que voy, habiendo anunciado cosas interesantes, los usuarios de WordPress todavía tenemos unas carencias históricas y aquí os hago mi personal Carta a los Reyes Magos, imposible totalmente hincarle en diente en un único año, pero son algunas reivindicaciones de cosas que echo en falta en mi día a día como usuario de WordPress.

Soporte Multiidioma

Una asignatura pendiente desde el nacimiento de WordPress ha sido la posibilidad de diseñar una web con diferentes idiomas, lo cual no es posible «out of the box» de una manera sencilla y decente. Si quieres darle una solución con cierto nivel de profesionalidad, tienes que recurrir a plugins pesados y de pago como WPML, Multilingual Press o Polylang, todos ellos de pago.

Nosotros desde hace años tenemos una licencia multidominio y lifetime de WPML, que sabemos que consume bastantes recursos y tiene bugs, pero antes de invertir en otro plugin, esperaremos a que algún día se implemente de manera nativa en WordPress.

Sí, sabemos que va para largo, pero bueno, a lo tonto ya llevamos más de 15 años con WordPress y en Ducktoy solo en los últimos 2 años hemos superado los 50 proyectos anuales, es decir, somos del team WordPress y estamos en ese barco, evidentemente.

Particularmente nunca he entendido cómo otros CMS como Joomla, Prestashop incluso Wix tienen bien solventado en el core el tema de multiidioma, y en WordPress hará falta reunir las 7 bolas de dragón para que esto suceda. En fin, yo lo tiro ahí porque esta noche nos tomaremos las uvas de nuevo y cuando haya que pedir un deseo, alguno como yo seguiremos reivindicando un poquito de por favor con este asunto.

Pulir Gutenberg y fijarse en los constructores visuales

Ya sé que es un sacrilegio lo que estoy planteando, me quedó patente cuando estuvimos el evento con Automattic: a los que usamos constructores visuales como Elementor nos miran con verdadero desprecio, por encima del hombro.

Me da la impresión de que hoy en día, para ser pura sangre y ser digno entrar en el Gran Salón de Odín, hay que usar solo bloques.

Y los bloques… perdona que te diga, están todavía muy verdes, tienen verdaderos problemas de usabilidad y una curva de conocimiento bastante complicada, no ya para nosotros los que trabajamos cada día con WordPress, sino para el cliente final.

Una de las cosas buenas de WordPress es que vino a democratizar el tema de la web 2.0, donde un usuario final con poca experiencia podía montarse una web sin ser programador, lo que ahora se llama no-code.

Pensemos un momento en el vetusto Visual Composer (WP Bakery). Tan despreciado hoy en día, debemos reconocer que si hoy en día WordPress es el verdadero ganador de la batalla de los CMS y con una cuota de mercado superior al 40%, una parte del mérito se la debemos a este editor tan primitivo y tan robusto a la vez.

Te guste o no, es un hecho que todavía hay montones de webs con WP Bakery y sus sucedáneos como Zion Builder, Avada, Fusion, Enfold, etc., y ese plugin ayudó muchísimo a que los diseñadores eligiésemos WordPress para nuestros proyectos. Al César lo que es del César, reconozcámoslo.

Y todo esto viene a que no estaría mal que el equipo que desarrolla Gutenberg o Editor de Bloques considerase que los plugins como Elementor, Divi o Bricks les han hecho un adelantamiento en toda regla; les llevan años de ventaja.

Luego podemos discutir sobre los problemas de cada builder, que si son pesados, que si meten mucho script, que si cargan mucho el DOM… está bien, luego se pueden optimizar también, pero a nivel de posibilidades, potencia y facilidad de uso por el cliente final, son imbatibles y verdaderamente un modelo que ha impulsado más el uso de WordPress.

En mi humilde opinión, los diseñadores seguimos usando WordPress a pesar del editor de bloques, que continúa ahí seguramente mejorando, y que supuestamente será la apuesta de futuro y la que terminará consolidándose a largo plazo.

Pero ojito, que todavía cuando entras al repositorio oficial, el plugin más descargado es el Editor Clásico. Alguien debería mirarse el ombligo con esto.

Tomarse en serio el Full Site Editor

Decir que el Editor de Bloques tiene muchos bugs en realidad es ser bastante generoso y moderado. Particularmente, no tenemos una web donde sea fácil trabajar con bloques para diseñar cosas que no sean posts.

En lo referente a la edición de widgets, los problemas ya rozan el absurdo. Parece mentira que nadie ponga remedio al montón de problemas que hay. Otro plugin que no falta en nuestro repertorio es Widgets Clásicos, que por si no lo conocéis, es el Editor Clásico pero para los widgets y sidebars.

Y para terminar de redondear los productos mal acabados, entra con fuera el Full Site Editor, ahora bautizado como Site Editor. Le han quitado el Full, porque en realidad es más bien Ful que Full…

Si tuviese que dar un ejemplo de un «quiero y no puedo», no se me ocurriría mejor ejemplo que esta funcionalidad, tan necesaria en WordPress, pero que nos han metido de una manera muy torpe, sin bajarse de la burra con los bloques, y para la cual hay que ser usuario bastante avanzado, a pesar de lo cual a medio camino seguramente te rendirás y volverás a diseñar los headers y footers con tu theme de toda la vida, o con un builder en condiciones.

En mi estudio actualmente tenemos muchísimas webs hechas con Elementor Pro, alguna todavía con WP Bakery, y actualmente estamos empezando con Bricks Builder; este último va tomando posiciones como builder principal, ya veremos… pero en general todos ellos están muy por encima a nivel de facilidad y usabilidad.

Sí, sé que no estoy haciendo amigos precisamente entre los desarrolladores del MAKE de WordPress, pero de nuevo, un poquito de humildad y alegría, miremos las soluciones comerciales y cómo han implementado todo esto, y aprendamos y saquemos lo bueno de cada una… y si finalmente hay que tirar los bloques, darle otro enfoque o hacer un Elementor ligero y nativo, creo que deberíamos darle al menos una pensada…

Custom Post Types de manera nativa

Otro de los factores determinantes para el despegue de WordPress como framework para hacer todo tipo de webs fueron los Custom Post Types.

De pronto se nos abrió un mundo de posibilidades, WordPress ya no estaba limitado a los Posts y Páginas. Y empezó a utilizarse para webs de inmobiliarias, venta de coches, eventos, servicios, incluso tiendas online.

Porque Woocommerce, la tienda online por excelencia para WordPress, está basada en el Custom Post Type más famoso que existe: los productos.

Pues actualmente todavía WordPress no dispone de manera nativa de creación y gestión de Custom Post Types, algo realmente necesario, aunque en lo relativo a la otra piedra angular relacionada, los Custom Fields sí dispone de unas funciones bastante escasas.

A mí no me preocupa mucho esto porque se pueden crear en el functions.php o con plugins, pero ¿no da un poco de fatiga a estas alturas andar así?

Es decir, nosotros empezamos con Custom Post Type UI, luego pasamos por Pods Framework y ahora somos felices usuarios de una licencia multisite y lifetime de JetEngine, tenemos ya solucionado esto «pa’tólavida» y no miramos atrás, pues con Crocoblocks lo tenemos todo tan fácil y a mano…

Pero cuando pienso hoy día cómo sería para un usuario que tenga que generar el snippet o valorar comprar un theme en Envato porque tiene un custom post type para un sencillo portfolio, que realmente vemos la gran carencia que todavía existe en ese campo.

Y de la organización de todo esto a nivel MySQL, mejor hablamos otro día. En WordPress casi todo se mete como registro en la tabla «wp_posts»… otra cosa para hacérselo mirar, de cara al rendimiento y a una mejor organización.

La Media Library, esa gran asignatura

Precisamente hablando de organización, me viene a la cabeza esta asignatura pendiente: mejorar la Biblioteca de Medios, con carpetas y subcarpetas, etiquetas, etc.

Habiendo cumplido 25 castañas, ¿cómo es posible que aún esté así de mal? En webs con miles de imágenes y archivos, es bastante difícil trabajar y no duplicar recursos.

Este año parece que van a abrir este melón, ya era hora, así que a ver si no la lían integrándola otra vez con sus dichosos bloques.

Las funcionalidades básicas para SEO

Que hoy en día uno de los plugins más descargados sea Yoast SEO ya dice mucho también sobre este tema.

No existe de manera nativa la opción de meter un meta-title, un meta-description o sencillamente poner una entrada como no-index.

Y tenemos que recurrir a plugins para esto.

Por cierto, nosotros usamos RankMath, que tiene fama de ser pesado y consumir muchos recursos, pero lo utilizamos para cosas básicas: titles, descriptions, open-graph, crear los sitemaps, etc.

De paso, tampoco estaría mal en las Settings añadir unas casillas para el custom code como puede ser Analytics, Tag Manager o los pixeles de conversión.

Eso es todo, amigos

Y por ahora, lo dejamos aquí. Que nadie me malinterprete, soy de WordPress como el que más.

Reconozco el gran trabajo de miles de personas para tener una herramienta como la que tenemos, y que cada día está mejorando.

Ya me gustaría a mí tener conocimientos para poder aportar cosas en el desarrollo, pero mi escaso nivel de PHP no me lo permitiría.

Lo que humildemente puedo aportar es mi opinión como usuario que cada día paso horas dentro de WordPress, en multitud de instancias diferentes y con diferentes problemáticas y necesidades.

Cierto que a veces soy un poco bruto escribiendo, solamente es mi opinión personal y basada en mi experiencia.

Firmo la carta deseándote un Feliz 2024 lleno de éxitos.

Ilustración de Imagen Destacada generada por AI con Bing Chat Create

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll al inicio