Ya no es tan locura: Cambiar de Toolset Types a ACF (parte 2: la estructura)

Hace un año decidí lanzarme a cambiar de Toolset a ACF porque ya olía a muerto en las noticias de Toolset. Por motivos de la vida (y de que tenías otras mejores cosas que hacer), lo he pospuesto pero veo que ya Toolset ha abandonado la toalla al 100%. Pensaba que sería una pausa para rehacer cosas, pero dos años después, mantenimiento y que descanse en paz. Gracias por lo que han dado tantos años y cierren al salir.

Como desarrollador, uno quiere estar actualizado de todas las noticias e información, pero hay veces que se nos escapa. El cambio a ACF lo empezamos cuando Toolset ya cojeaba, porque estuvo mucho tiempo cojeando y no dando nada nuevo mientras que sus competidores seguían creciendo y aumentando características. Pero esta vez no ha llegado el «aviso». Sé que Toolset son plugins 100% de pago y caros por lo que fue/es y no mucha gente lo toma como primera opción o, incluso, como opción. Se murió y ni siquiera fuimos a su entierro.

Total, que ahora tengo proyectos que un día morirán «supuestamente» (porque dicen que van a mantenerlo, pero ¿cuánto tiempo va a aguantar la gente pagando 100-250$ por absolutamente «mantenimiento»? ). Sigo con la fuerte convicción de irme a ACF, no tengo dudas. Sé que estoy escribiendo esto quejándome de que se ha muerto un plugin de campos personalizado y me voy a otro plugin de campos personalizados.

Y estoy llorando porque voy a empezar por mi proyecto más grande que tengo con Toolset que es mi PC. Sí, llorando, porque estaba preparando una funcionalidad nueva bastante extensa, pero, para mi suerte, eso lo hice en tablas separadas, bloques separados y sin dependencias de Toolset. Pero espérate, que hay cositas

Pero espera, que te lo cuento.

Siendo desarrollador, ¿por qué no lo haces nativo con WordPress?

La pregunta tiene más razón que una madre. Si WordPress lo permite nativamente y no cambiará en el tiempo (al menos, no se le espera, creo, ya no sé), ¿por qué no crear las cajitas de metaboxes, meta fields y todo para que nunca caduque? Tienes tiempo porque son proyectos propios, no tienes fechas de entregas y no tienes nadie que te de por saco para que acabes ya de ya de ya (triple ya, rápido y furioso).

Respuesta corta: Lo haría, pero no me apetece. Quiero algo que sea rápido y que se actualice, que añade funciones y cosas interesantes. Cosas que yo vaya viendo, probando y funcionando. Cosas que no se me ocurrirían.

Porque tú quieres utilizar al máximo WordPress, pero hay cosas que es mejor delegar. No digo que no se pueda o que sea mejor dejarlo a un plugin, pero te pongo un par de casos.

Imagina tener un campo de relaciones entre un post y otro. (Cómo voy a echar de menos el de Toolset…). Relaciones de 1 a muchos, de muchos a muchos, etc… Está muy bien hacerlo manual y completamente nativo, pero, al menos, en este ejemplo necesitas:

• Diseñar cómo vas a relacionarlo
• Decidir dónde guardarlo: postmetas, tabla separada, etc..
• Crear su meta box y añadir los campos.
• Añadir una funcionalidad para poder seleccionar los relacionados: que no se elija a sí mismo, que no se pueda elegir más de 1 si es una relación 1-1, que lo almacene, una interfaz útil.
• Detectar la relación y mostrarla en el panel de admin para que estén sincronizados.
• Acciones de añadir y quitar relaciones.
• ¿Campos de relación adicionales…?

Y seguro que faltan más cosas. Todo eso para una funcionalidad. Y las relaciones es algo un poco más costoso y lioso, pero se puede hacer. Ahora bien, mi problema es que lo haces orientado para que sirva para cualquier tipo de dato y funcionará. Pero claro, tienes que crear toda una funcionalidad completa para un solo objetivo. Si empiezas a ir añadiendo campos personalizados, funcionalidades y otros, vas a tardar más en crear la interfaz de uso que el propio objetivo que tienes.

Relegar ciertas funciones a los plugins más fuerte o conocidos siempre ayudará a mejorar nuestra forma de trabajar. Si yo relego toda la gestión de campos personalizados a ACF, habrá un equipo independiente mejorando, revisando, arreglando errores, añadiendo funcionalidad… DE TODO. Sin que yo esté perdiendo el tiempo en reinventar ruedas, mochilas y refrescos.

Con un gestos de campos personalizados, me da todo desde una interfaz ya pensada, trabajada, con toda su lógica pensada de la mejor forma y yo solo tengo que rellenar cositas, clicks, opciones, marcar checkboxes y en dos minutos tengo todo montado para añadirle mi lógica adicional. Ya sea mostrar un campo, realizar cálculos y montar bloques del editor personalizados para jugar con todos esos datos de forma automática. Hay que saber apostar, tener claro los riesgos y levantar cabeza si nos equivocamos.

No hablemos más, ¿cómo empezamos?

Así me gusta, a pringarse. Lo primero que siempre te recomiendo es una copia de seguridad por si la lías. No deberías, pero ten cuidado. Si puedes trabajar en un entorno de desarrollo local, hazlo sin dudar. Si no puedes, pues tendrás que tener mucho cuidado y habrá tiempos que la puedes liar. Habrá momentos de desactivar/activar, pero se pueden hacer. Pero esto solo es para valientes.

Instala Advanced Custom Fields

Parece que me quiera reir. Pero no. Tengo que recordarte que instales la última versión, que nos vamos a poner a tope y tiene que estar instalado. Si usas la versión PRO, recuerda entrar en ACF > Actualizaciones (ACF > Updates) y revisa que tu licencia está añadida y activa. Si no lo está, añádela de nuevo y comprueba si hay actualizaciones para empezar con la última versión.

Crear los tipos de datos y taxonomías con ACF (CPT UI) o nativos o como quieras

Si lo teníamos todo con Toolset Types, hay que empezar a quitar dependencias. Toolset tiene la habilidad de obtener control de tipos de dato y taxonomías creadas con otras entidades, pero los otros plugins no suelen ser tan abusivos. Pero tenemos que usar la ventaja. Lo que vamos a hacer es dividir nuestra pantalla en dos y vamos a poner en una ventana el creador de tipo de dato en un lado y el tipo de dato en la pantalla de edición de Toolset.

Vamos a copiar, sobre todo, el slug o enlace permanente. Luego copiaremos todo lo necesario como añadirle el plural, singular y todo lo que quieras como iconos, posiciones y otros campos. Si es una taxonomía, recuerda elegir que si quieres que se comporte como una categoría o taxonomía. ¡No pulses en Publicar en ACF todavía! Espera ahí.

Los dos plugins no pueden estar activos creando el mismo tipo de dato o taxonomía, por lo que desactivaremos el tipo de dato en Toolset y, luego, activaremos en ACF. Este cambio será prácticamente invisible para los dos. Recuerda lo invasivo de Toolset, se mantendrá todo bien.

Una vez que has revisado y confirmado que todo está exactamente igual en Toolset, volverás al listado de tipos de dato de Toolset y pondrás el cursor encima. Ahí aparecerá el botón para desactivar el tipo de dato (mejor que entrar editar de que esté activo, en borrador/draft, etc…).

Una vez lo pulses, ve de nuevo a la ventana de ACF y darle a publicar. Verás que no te dará errores. Si no desactivas primero Toolset, ACF te dirá que ya existe un tipo de dato creado (por otro plugin o por código personalizado).

Si vuelves de nuevo a la lista de Toolset, verás que está activo de nuevo. Pero ACF ahora tiene el control y Toolset pasa a ser el pasivo.

¿Hemos sobrevivido? Sí, hasta aquí sobreviviremos porque todo esto no tiene mucha enjundia. Si tienes más tipos de datos o taxonomías, ¡a duplicar! No te preocupes por tus datos, de verdad. Los dos plugins utilizan lo más cercano al core de WordPress y sus tipos de datos y taxonomías están en buen recaudo. El problema será con los campos personalizados (spooooileeeerrrr).

Duplicar la estructura de campos personalizados

Bueno, yo no sé tú, pero yo acabo de trasladar 10 tipos de datos y 10 taxonomías. Casi nada. Pero ya verás que si vas entrando a cada uno de los nuevos tipos de dato y taxonomías creados por ACF verás que está todo ahí. Somos felices por el momento. Ahora toca, seguramente, lo más tedioso: los campos personalizados.

En este apartado, tendremos que estar un poco más tranquilos y pensativos. Vamos a cambiar de tercio la cosa y muchos de los campos no coincidirán. Pero ACF nos ofrece mucho más que Toolset y mejor montado, así que tendremos que ser más astutos y pensando cómo organizaremos ciertos datos.

Esto provocará que tengamos que cambiar la plantilla, principalmente por las funciones de Toolset, pero sobre todo para mejorar cosas. Si recuerdas la primera parte, vamos a tener mejores bloques con los que luego trabajar con mejores funciones como las del core de WordPress, obtener imágenes y ejecutar funciones para obtener toda la información sin tener que hacer funciones adicionales para buscar IDs de medios o ejecutar una función explode de una cadena de texto de URLs de imágenes. (Sí, tengo muchas funciones para intentar optimizar y quitarme líos de Toolset).

No quiero liarte, ponte a duplicar grupos y tal. Lo bueno es que aquí no tendrás que desactivar campos y no deberías. Toolset Types guarda los campos personalizados con un prefijo en la base de datos. ¿Qué quiere decir? Que si un campo creado con Toolset Types le llamamos ‘camiseta-color’, en la base de datos estará en la tabla de postmeta pero como ‘wpcf-camiseta-color’. wpcf (WordPress Custom Field) es como se llamaba en un principio Toolset Types. No te hace falta utilizar la función types_render_field si quisieras, pero con ella te ahorras tener que poner ‘wpcf-‘ todo el rato. Ya veremos esto a futuro cuando migremos la información.

Duplicar las relaciones (relationships)

No pensaba ponerlo, pero no quiero dejarte tirado. En este caso, no voy a hacerlo porque en esta web no tengo relaciones (ya sufriré en otro proyecto bastante grande…). Pero te voy a intentar ayudar a trasladar.

Tenemos un poco de problemilla aquí. Pero no te asustes todavía. La función de Relaciones de Toolset era el motivo más fuerte por el que seguía utilizando Toolset. Es una locura lo que puedes con editor de relaciones (uno-muchos, muchos-muchos, uno-uno…), campos intermedios, editor y creador dentro del mismo editor del tipo de dato: una sencilla maravilla.

Pero vamos a tener que bajar las expectativas y hacer downgrade (bajar de versión). ACF aquí flojea un poquito, pero se pueden hacer ciertas cosas. Los campos intermedios ya te puedes olvidar, por desgracia. La idea más loca que se me ocurre es que tengas que hacer un tipo de dato de relaciones y meter campos personalizados ahí. No es una locura, es como lo hace ACF de forma interna. Si lo has usado, verás que crea una relación con slug y es un tipo de dato falso que añade en sus propias tablas y donde guarda los campos personalizados.

¿Qué podemos hacer en ACF? Tenemos el campo Relaciones. Te recomiendo empaparte de esto porque tienes que entenderlo. ¿Funciona igual? Más o menos. ¿Hay que hacer un poco de ingeniería? Sí, pero teniendo cuidado.

Cuando crees este tipo de campo personalizado, recuerda siempre que, si quieres conectar y sincronizar entre los posts del tipo de dato (que sea una relación, vamos), tendrás que tener el campo en el primer nivel: sin grupos, sin estar dentro de campos repetitivos. Y es que tiene sentido. Si te acuerdas de Toolset, no puedes (no podías) tener grupos repetitivos dentro de grupos repetitivos porque no sabía dónde apuntar. Pues justamente es por eso, porque la relación de un campo no es viable para ACF. Pero todo OK, no creo que quieras poner relaciones bidireccionales en un grupo repetitivo. Creo.

¿Has dicho bidireccional? Claro, que sincronicen entre ellos. Lee esa entrada de bidireccional que te va a flipar. Sobre todo el apartado de problemas conocidos. Y es que aquí tienes que hacer los siguientes pasos:

1. Crea el campo de la relación: ya sea noticias relacionadas, likes relacionados, etc. tu campo y guarda.
2. Ve a la pestaña de Avanzado (Advanced), marca la opción de Bidireccional (Bidirectional) y guarda.
3. Vuelve a la pestaña Avanzado (Advanced) y en Campo objetivo (Target field) añade el propio campo de la relación Y GUARDA. Verás que está marcado como Este campo (This field).

Verás que he sido un poco agresivo con guardar… Es que si quieres que funcione… Si añades las relaciones antes de hacer cualquiera de esos tres pasos, nunca jamás se sincronizarán. Tendrás que quitarlas todas, guardarlas y volver a ponerlas. En ese momento, ya estará todo sincronizado y podrás hacer las actualizaciones posibles.

¿Y ya? ¿Ya está?

Por hoy (o por esta entrada), lo vamos a dejar aquí. A lo mejor tú no lo sabes, pero llevo 2 horas haciendo el traslado y escribiendo esto. Además, que dice esto que vas a tardar más de 12 minutos en leer esto, por lo que descansemos un poco. El próximo paso será el traslado de información de campos de Toolset a ACF y, más adelante, actualizaremos nuestro tema y plugins si usan Toolset Types.

¿Todo bien? Espero que sí. Nos vemos a la próxima. 😜