Advanced Custom Fields es un plugin fantástico utilizado por millones de personas que convierte WordPress en un CMS full-stack, permitiéndote crear grupos y tipos de campos personalizados ilimitados y añadirlos a cualquier tipo de post personalizado.
Sin embargo, no son muchos los que conocen los límites de escalabilidad de Advanced Custom Fields.
Con bastante frecuencia nos preguntan si GeoDirectory utiliza Advanced Custom Fields para gestionar los campos personalizados de los listados.
Cuando respondemos que GeoDirectory tiene su propio sistema de campos personalizados integrado, se preguntan por qué decidimos "reinventar la rueda".
La respuesta para nosotros es muy clara: la escalabilidad de Advanced Custom Fields es bastante limitada para crear directorios.
Pensamos que quizás, al ser usuarios, no son conscientes de lo que ocurre internamente y los desafíos de escalabilidad que puede presentar un directorio web.
Sin embargo, hace no mucho tiempo nos encontramos con una encuesta en un popular grupo de WordPress en Facebook, donde las opciones para votar por el "Mejor Directorio" eran: GeoDirectory, algunos otros temas de directorio disponibles en marketplaces populares, y también estaba la opción ACF + FacetWP.
Cuando vimos los resultados, nos quedamos perplejos, por decirlo suavemente: ACF + FacetWP tenía muchos más votos de los que habríamos esperado.
Se suponía que las personas que votaron no eran simples usuarios, sino desarrolladores web y expertos en WordPress.
Por esta razón, decidimos que era el momento de explicar por qué NO es una buena idea usar Advanced Custom Fields para un directorio.
Y por qué los desarrolladores web no deberían ofrecer esa solución a nadie, a menos que no les importe proporcionar soluciones rápidas y escalables a sus clientes, que puedan crecer de forma sostenida.
Límites de escalabilidad de los campos personalizados de WordPress
WordPress utiliza por defecto la tabla de base de datos wp_postmeta para almacenar los datos de campos personalizados, y crea 1 fila por cada campo personalizado utilizado en una entrada.
Además de eso, WordPress añade una gran cantidad de datos extra en esta tabla por cada entrada, cada uno de los cuales utilizará 1 fila de la tabla.
Si has dedicado tiempo a optimizar consultas SQL, sabrás que eso no es un escenario ideal para cosas como directorios y filtros.
De hecho, la estructura de base de datos predeterminada es potencialmente un enorme cuello de botella para sitios web con muchas entradas y campos personalizados.
Se considera uno de los puntos débiles de WordPress.
Esto se debe a que, para filtrar entradas por campos personalizados, es necesario unir la tabla wp_post con la tabla wp_postmeta en la consulta.
Cuanto más crezcan las tablas, más lentas se volverán las consultas.
Lo peor de todo es que si quieres filtrar por dos valores meta, necesitarías unir la tabla post_meta dos veces para hacerlo en una sola consulta.
Esto puede consumir la memoria del sistema y ralentizar todo, excepto en un directorio pequeño.
Límites de escalabilidad de Advanced Custom Fields
El plugin Advanced Custom Fields es perfecto para cualquier sitio web con un número bajo o moderado de publicaciones, páginas y campos personalizados en general.
Sin embargo, salvo en contados casos excepcionales, los directorios son todo lo contrario.
Tienen un número muy elevado de publicaciones y potencialmente también un número muy alto de campos personalizados.
El principal problema de escalabilidad de Advanced Custom Fields es que crea 2 filas en la tabla wp_postmeta de tu base de datos por cada campo personalizado añadido a un listado.
También añadirá varias filas en postmeta correspondientes a su propia configuración.
Esto significa que añadirá más del doble de filas en la tabla wp_postmeta de tu base de datos en comparación con el uso del sistema de campos personalizados predeterminado de WordPress.
Realizamos una prueba rápida que debería ayudarnos a explicar mejor este asunto.
Creamos un nuevo sitio web de WordPress, eliminamos la publicación «Hola mundo» y la página de muestra, e instalamos Advanced Custom Fields.
Creamos 1 grupo y 5 campos personalizados, y publicamos 3 entradas usando cada una los 5 campos personalizados.
Después de esto, nuestra tabla wp_postmeta ya contaba con 83 filas.
Es una locura.
Imagina el número de filas para un directorio con 300.000 listados y cinco campos personalizados.
Con ACF, tu tabla wp_postmeta contaría un mínimo de 3.000.000 de filas
¿Cómo escala GeoDirectory?
Es muy sencillo: creamos una tabla personalizada para cada uno de nuestros tipos de publicación personalizados.
Ejemplo: wp_gd_gd_place_detail
En esta tabla guardamos todos los campos personalizados y sus datos, en una fila por cada publicación.
También desarrollamos nuestra propia API en PHP para consultar nuestras tablas personalizadas, del mismo modo que WordPress tiene su propia API en PHP para consultar las tablas predeterminadas de la base de datos wp.
Esto significa que GD, en la mayoría de los casos, solo necesita hacer un JOIN entre la tabla de publicaciones y nuestra tabla.
Luego podemos filtrar esos resultados por CUALQUIER campo personalizado.
Podríamos filtrar por 20 campos personalizados, mientras que ACF, incluso con facetWP (que acelera las cosas pero sigue teniendo la limitación de base), tendría que hacer JOIN de múltiples tablas una y otra vez para realizar el mismo trabajo en una sola consulta, usando muchas veces más memoria del servidor para la misma consulta.
Conclusiones
Entonces, si comparamos GeoDirectory con WordPress o WP + Advanced Custom Fields, vemos que:
WordPress
1) Requiere un JOIN de tabla adicional por cada campo personalizado por el que se quiera filtrar.
2) wp_postmeta crece rápidamente, ralentizando las consultas
WP + ACF
1) Requiere un JOIN de tabla adicional por cada campo personalizado por el que se quiera filtrar.
2) wp_postmeta se vuelve el doble de grande en comparación con usar WordPress solo
GeoDirectory
1) No se requiere ningún JOIN
2) GD no añade información a wp_postmeta, por lo que no genera volumen innecesario.
3) La base de datos que almacena los datos de los listados cuenta con 1 fila por publicación
WordPress es conocido por esta limitación en la forma en que almacena los datos. En la mayoría de los casos, este sistema funciona bien, pero cuando se trata de grandes directorios, simplemente no es la solución adecuada.
Por eso con GeoDirectory puedes crear un directorio con millones de listados, mientras que con WP + Advanced Custom Fields tienes suerte si logras crear un directorio con unos pocos cientos de listados antes de empezar a ver graves problemas de rendimiento.
Estos son los límites de escalabilidad de Advanced Custom Fields que nos llevaron a decidir no usarlo en GeoDirectory, y por eso tú tampoco deberías usarlo.
Si tienes alguna pregunta, no dudes en hacerla en los comentarios de abajo.