Esta entrada es parte de una serie de entradas de mi experiencia de cómo trasladar de Toolset Types a ACF. No es 100% necesario leer las anteriores, pero si te enfrentas a este mismo traslado, es recomendable que leas las anteriores partes.
- Cambiar de Toolset Types a ACF (parte 1: el por qué) (actual)
- Cambiar de Toolset Types a ACF (parte 2: la estructura)
- Cambiar de Toolset Types a ACF (parte 3: migración)
Llevo tantos años en el mundo de WordPress que he visto cómo los plugins nacían, se compraban, se hacían rebranding, desaparecían, se vendía y morían. He visto muchos plugins dar volteretas para, al final, decidir dedicarse a una sola cosa (que me alegro mucho) y a otros parecer navajas suizas de navajas suizas (cosas sin sentido).
Hace un año, decidí que Advanced Custom Fields (ACF) tenía que ser probado. A pesar de que llevaba mucho tiempo queriendo hacerlo, siempre me había quedado con las ganas. Al final, apostamos por utilizarlo y menudo acierto.
Quédate y te cuento cosas.
¿Qué vamos a hacer aquí?
Empezamos por el principio, para entendernos genial. Mi idea es trasladar todos los campos creados con Toolset Types a Advanced Custom Fields en mi proyecto PC de Adam.
El PC de Adam es básicamente mis paranoias genéricas. Es el sitio donde recopilar todas aquellas tonterías pequeñas que quiero hacer y que pueden estar chulas. Pero se han ido ya de madre. Mi historial de canciones escuchadas, mis discos físicos, fotografías, una estantería física virtual (¿hola?)… los datos han crecido exponencialmente y ya la web se arrastra.
Por supuesto, podría mejorar muchas cosas con Toolset Types. Podría arreglar código y optimizar. Pero creo que he llegado al momento de que prefiero irme con ACF. Luego os contaré cosas para que entendáis por qué.
¿Qué me ha pasado para hacer este cambio?
Desde que entré en el mundillo este, siempre escuché a JuanKa Díaz hablar muy bien de Advanced Custom Fields y de lo bien que se lo montaba para todos los proyectos. Era muy cierto que se veía genial. En las charlas que le he visto, flipaba de cómo estaba tan ordenado, centralizado y administrado de una forma maravillosa. Vamos, que daba gusto verlo.
Luego, otro ejemplo que encontré fue en la WordPress Developers de Sevilla en 2019. Varios desarrolladores del rediseño de Newtral.es contaron cómo habían ofrecido una mejor interfaz en el backend para los usuarios mediante Flexible Content de ACF. Otra vez ACF. Y ahí está la sucedura. Todo se veía super bien.
Llegó el día y la oportunidad de probarlo en varios proyectos. Y que me enamoré. Simplemente que me enamoré. Pero me enamoré por las posibilidades, pero me quedé por todo lo bien que está hecho, está optimizado, no está tan cargante y te permite muchas cosas sin tener que estar detrás de mucho código para ofrecer soluciones rápidas.
¿Qué me ocurría con Toolset Types?
OnTheGo Systems, los desarrolladores de Toolset, son unos cracks. Que eso no quite lo que voy a decir. Pero cada vez que instalaba Toolset Types (y solo Types), ya notaba una pequeña bajada de rendimiento. Corta, pero se notaba de alguna forma. Si instalamos WPML, ya ni os cuento… Y es que me da miedo muchas veces tener en cuenta estos plugins.
WPML me parece el mejor plugin de idiomas que tiene WordPress sin lugar a duda. He probado muchísimos y es el mejor. Pero en rendimiento es un revólver con 5 de 6 balas y estás jugando a la ruleta rusa cada día que pasa. ¿Qué quiero decir? Que se le va la pinza en ciertos proyectos que son simples, que no tienen una cantidad de cosas exageradas y que prácticamente tienen WPML y poco más. Se cae el rendimiento por los suelos, su traductor moderno pierde la sincronización y la lía… muchísimas cosas. Y luego va cojonudo en muchos sitios. Creo que por esto la gente dice que va fatal. Pero yo no lo he estado viendo hasta hace pocos meses.
A Toolset Types le pasa algo bastante triste. Cosa que no es rendimiento, sino que ya no tienen ganas de tenerle cariño al plugins. Gutenberg es el futuro y los campos personalizados son el pasado. Lo entiendo, por supuesto. Pero hay gente que o no quiere pagar el cambio o no le apetece estar cambiando maquetas. Por supuesto, el editor de sitios (FSE) es una maravilla, pero tienes mucha flaquezas aún. Por supuesto que se pueden hacer cosas, pero las justas y necesarias.
Muchas veces, un usuario quiere un backend lo más limpio posible. Hay gente que no le apetece tener que duplicar o meter bloques. Sino llegar, copiar, pegar y publicar. ¿Se ve bien? ¡Me importa una leche! Porque no me falla la plantilla.
Dame cuatro campos donde pueda escribir cosas y no pueda cargarme nada, por favor.
¿Y qué tiene ACF que no te proporciona Toolset Types?
Ahhh… ¿por dónde empezar…? Sé que ya no puedo explayarme, porque me quedaría muy cojo en ciertos temas. Pero cosas que me dan rabia las voy a decir. Voy a darle un barrido al Gutenberg, para ver cómo podemos dejar esto bonito porque tiene para llorar.
Vamos a poner los puntos negativos de Types en rojo, lo que ACF mejora en verde y otros comentarios en amarillo.
Nombres únicos de campos
Bienvenido al mayor entrenamiento mental de la historia
Types: que me da igual que tengas 12 campos que es el mismo campo. PONLE. UN. IDENTIFICADOR. ÚNICO.
ACF: mientras que en el grupo de campos no me repitas el nombre, haz lo que necesites. Confío en ti plenamente.
Esto puede ser una tortura a largo plazo. Imagina que tienes muchos tipos de datos. Y todos ellos tienen una descripción, una foto, muchos campos iguales. A ver, lo ideal es que empezaras el nombre del campo con el tipo de dato para identificarlo. Pero imagina que, por algún motivo, tienes que repetir el mismo campo y se te tiene que ocurrir un identificador nuevo o meter paranoias. Pero espera, que puedes importar campos ya creados (punto para Toolset), pero no puedes ponerle el mismo ID… Tristeza. Me parece correcto por parte de Types, pero si se juntan demasiados campos iguales…
Campo Imagen/Galería
Types: es un timo. No es un campo imagen como tal. Es una cadena de texto. Esto es horrible. Hay cero conexión con el medio real, con su ID de WordPress, de hacer lo que necesites con las tropecientas funciones que tiene WP para los medios. ¿Y la galería? Las URLs separadas por espacios…
ACF: es la imagen como tal. Tiene la ID de la imagen, puedes cambiar en cualquier momento si devolver la URL, la ID o el objeto de la imagen. Puedes hacer lo que quieras con ella. Internamente siempre es la ID y luego te devuelve lo que tú le has pedido. Esto es cine. 🚬
A veces, me da la sensación de que Toolset Types tiene muchísimas funciones internas que no se dejan ver o no son tan públicas como deberían. Pero a mi me da la sensación de que siempre tengo que estar creando funciones adicionales para obtener tonterías. Y lo peor es que si puedo hacerlas yo sin conocer Toolset por dentro… ¿Qué posibilidades tiene que no nos están ofreciendo?
Por ejemplo, mi problema con las imágenes es que ni les pone atributos tan importantes como width, height, loading, decoding, fetchpriority… nada. Se lo puedes poner, por supuesto, pero sigue siendo una URL al medio. Si le pides que te haga una miniatura, se pierde el medio original (cosa que no podrás regenerar la miniatura hasta que lo regenere Toolset cuando cargue)… Es un poco completamente desfasado. Funciona, pero es poco útil… Tienes que inventarte funciones que busquen ese medio a través de SQL para obtener la ID del medio y poder trabajar adecuadamente.
Página de opciones
Una página de opciones es, en términos sencillos, una página más en la administración de WordPress donde añadir metaboxes (cajas para incluir campos) con los campos personalizados para tu web. Esto centraliza muchos datos como, por ejemplo, las redes sociales, el contacto, la dirección. Imagina que aparecen por tropecientas partes de la web y quieres modificarlo en un solo sitio. Si lo tienes todo centralizado, lo cambia en tu página de opciones y automáticamente actualizado en todos sitios.
Types: «no somos un plugin para eso». Eso dijeron. Pero, en resumen, es que se les adelantaron y no querían que les dijeran que se habían copiado de X.
ACF: tenemos, crea todas las que quieras con este simple código de tres líneas. ¿Subpáginas de opciones? Las que quieras también, crack.
La realidad de este apartado es que Toolset Types no tiene 100% la culpa de no tener esta opción. Pero es algo super necesario para este tipo de desarrollos. Sé que hicieron sus «bloques» antes que nadie, que había muchas cosas montadas y se han partido el lomo pasándolo a «Gutenberg». Pero el caso es que su forma en la que asignar los campos (mediante IDs) les ha penalizado en muchas cosas. No podemos evitarlo y es un castigo.
En cambio, ACF decidió ir por el camino WordPress. El de utilizar WordPress para realizar contenido WordPress. Para ellos, les fue más fácil adaptar este apartado porque si abrazas el desarrollo y utilizas WordPress, WordPress te quiere. Pero si te haces un plugin por encima de WP… luego, a la larga, se te hace bola.
Yo he llegado a hacer muchas paranoias para una páginas de opciones. De programarlas con metaboxes/metafields, de utilizar clases muy guays y hasta de montar cosas raras con medias mezclas de Types. Pero esto me añadía tiempo extra innecesario… Que si Select2, que si text editors, que si guardar, que si sanitizas… Nada, nada… Es horrible.
Y luego llega ACF y te pone puertas al campo, funcionales e increíblemente maravillosas.
Campos repetitivos dentro de campos repetitivos dentro de campos repetitivos dentro de campos repetitivos dentro de campos repetitivos
Lo sé, me he colado con el título.
Types: uy, no puedo… Uff y menos si utilizas de que se muestren en plantillas o cosas sin IDs. Quita, quita…
ACF: mete otro más. El único problema es que no te caben en la pantalla. Tendrás que comprar un monitor 20K.
Que siiiii, que lo que digo es una locura. Pero no tanto. Hay veces que necesitas tener estos campos repetitivos dentro de otros campos repetitivos. Y eso es gloria bendita. Cosas como tengo un tipo de dato Personal. De esa Persona del Personal, tiene formas de contacto. (Grupo repetitivo para que añada todas las formas de contacto). Esa persona también tiene 200 correos y depende del país. Grupo repetitivo de grupo repetitivo. Y luego ACF te lo devuelve en un cómodo array. Ains… Enamorado…
Y cómo lo haré
En la siguiente entregas de este hilo, veremos cómo traslado tipos de datos, campos personalizado, estructuras y veremos paso a paso lo que he ido haciendo. Estoy un poco triste por irme, pero ya toca. No queda otra. Ya te he presentado mis motivos y creo que son bastantes razones de peso.
Quédate cerca porque iremos pasito a pasito. Al menos, para ir preparando la integración que lo haga de golpe para mi proyecto y haremos el switch cuando sea el momento. No te lo pierdas o no me olvides. Lo que prefieras.