Blog - Page 9 of 9 - GeoDirectory

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.

Las funcionalidades de localización de WordPress te permiten hacer que plugins y temas sean fácilmente traducibles mediante archivos de idioma de WordPress (archivos po/mo).

Esto es especialmente cierto desde WordPress 3.7 y se simplificó considerablemente desde WordPress 4.6.

Se han realizado muchas mejoras en todo el sistema de traducción de WordPress, y sentí que realmente necesitaba una entrada actualizada.

Archivos de idioma de WordPress – La confusión (edición para desarrolladores)

Para los desarrolladores, todo se reduce a cómo indicarle a WordPress de la manera correcta que tienes archivos de traducción.

Como desarrolladores, se nos indicó usar

Sin embargo, en el pasado este sería el único lugar donde WordPress buscaría y si un cliente añadía su propio archivo de idioma allí, ¡en la próxima actualización desaparecería!

Hace un tiempo había un artículo en la web que promovía el uso de una segunda llamada, esta vez usando la función

Esto significaba que los usuarios podían colocar sus archivos de idioma en un lugar predeterminado dentro de la carpeta de idiomas de WP, y la traducción no se perdería al actualizar el plugin.

Archivos de idioma de WordPress – La confusión (Edición para usuarios)

Los usuarios necesitan saber dónde colocar una traducción personalizada para un plugin/tema; el problema es que en el pasado esto podía hacerse en varios lugares.

La documentación de WP indica a los desarrolladores que enlacen a una carpeta dentro de la carpeta de su plugin llamada e incluso así, esto se perderá cuando el plugin/tema sea actualizado.

Algunos desarrolladores añadirían una segunda comprobación en un lugar elegido por ellos, pero a menudo en una carpeta con nombre personalizado dentro de la carpeta de idiomas de WP.

Esto significaba que no había una forma consistente para que un usuario supiera dónde colocar sus archivos de traducción personalizados de forma segura.

Cargando archivos de idioma de la forma correcta (2017)

¡Desde WP 4.6 esto se volvió mucho más fácil tanto para usuarios como para desarrolladores!

Como desarrollador, ahora solo tienes que asegurarte de que estás cargando tus archivos de idioma correctamente, siguiendo la documentación de WP como se indica a continuación:

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin', false, basename( dirname( __FILE__ ) ) . '/languages' );<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme', get_template_directory() . '/languages' );<br />
}<br />

Observa que los ejecutamos en los hooks 'init' y 'after_setup_theme'; esto debería garantizar que todo se cargue correctamente.

Si los ejecutas directamente o antes de sus hooks respectivos, puedes tener problemas con algunas cadenas que no se traducen, y plugins para manipular traducciones o crear sitios web multilingües como WPML podrían no funcionar en absoluto.

Como usuarios, ahora tenemos un lugar conveniente y con un nombre consistente donde podemos colocar nuestros archivos de idioma.

Para plugins: /wp-content/languages/plugins/my-plugin-en_US.mo
Para temas: /wp-content/languages/themes/my-theme-en_US.mo

'my-plugin' y 'my-theme' son el textdomain del plugin/tema (que generalmente se encuentra en el archivo readme.txt del plugin o en el archivo style.css del tema, al inicio).

Esta es una gran mejora respecto al método antiguo y evitará la pérdida de traducción en las actualizaciones en la mayoría de los casos.

En algunos casos, el plugin/tema puede que ya tenga una nueva traducción en tu idioma almacenada en wp.org; si este es el caso, podría sobrescribir tu archivo .mo, aunque en la mayoría de los casos esto será lo deseado.

Puedes contribuir con traducciones en wp.org si el plugin está alojado allí; si es un plugin premium, hay pocas probabilidades de que sea sobrescrito.

Información adicional

WordPress intentará encontrar tus archivos de idioma de WordPress en varios lugares; para un plugin con el textdomain 'my-plugin', primero buscará aquí:

/wp-content/languages/plugins/my-plugin-en_US.mo

Si no encuentra una traducción allí y el plugin especifica dónde encontrar una localmente, buscará allí:

/wp-content/plugins/my-plugin/languages/my-plugin-en_US.mo

Si el plugin no especifica una ruta, WordPress buscará aquí en su lugar:

/wp-content/languages/my-plugin-en_US.mo

La documentación de WordPress debe seguirse, pero en la práctica, desde WP 4.6 ni siquiera es necesario especificar un archivo local si no estás incluyendo ninguno (si están almacenados en el repositorio de wp.org), por lo que podrías simplemente añadir esto:

<br />
// for plugins<br />
add_action( 'init', 'myplugin_load_textdomain' );<br />
function myplugin_load_textdomain() {<br />
  load_plugin_textdomain( 'my-plugin');<br />
}<br />

<br />
// for themes<br />
add_action( 'after_setup_theme', 'my_theme_setup' );<br />
function my_theme_setup(){<br />
    load_theme_textdomain( 'my-theme');<br />
}<br />

Espero que esto aclare un poco el tema de las traducciones y, si tienes alguna pregunta o algo que agregar, por favor deja un comentario a continuación.

Actualización septiembre 2019

Esto se ha añadido como campo personalizado predefinido en la V 2.0.0.67. El fragmento de código a continuación solo funcionará si se usa GeoDirectory V1.

El problema

Hoy un miembro hizo una solicitud un tanto inusual: está usando GeoDirectory para gestionar un festival local y está listando cosas como alojamiento para el evento. La solicitud era mostrar la distancia en cada listado hasta el evento principal, para que los usuarios tengan una idea clara de lo lejos que estará el evento desde cada listado. Hago algo muy similar en uno de mis propios sitios, que es para una sola ubicación: listo la distancia al aeropuerto y la distancia al pueblo principal. Hasta ahora simplemente había dejado que los usuarios introdujeran esta distancia manualmente, lo cual suele ser incorrecto y tengo que corregirlo.

La solución

Este parecía el momento perfecto para crear un nuevo campo personalizado, llamémoslo
#1 Podríamos simplemente añadir el campo y dejar que el usuario introduzca coordenadas GPS; podría ser, por ejemplo, un campo de
#2 En el caso de este usuario, solo necesita mostrar la distancia a un lugar sin que el usuario tenga que saber siquiera de la existencia del campo, así que al añadir el campo personalizado lo configuraría como un campo de

El código

Esta publicación te explicará cómo solucionar el problema «This page didn't load Google Maps correctly. See the JavaScript console for technical details.» con Google Maps.

Si estás utilizando GeoDirectory, consulta nuestra documentación aquí.

Si quieres leer más sobre el problema, visita nuestra entrada del blog aquí: https://wpgeodirectory.com/google-maps-api-key-and-new-limits/

Si has visto el mensaje «This page didn't load Google Maps correctly. See the JavaScript console for technical details.» o cualquiera de los siguientes mensajes:
“Esta página no ha cargado Google Maps correctamente.”
“Google Maps ne s’est pas chargé correctement sur cette page.”
“Google Maps non è stata caricata correttamente.”
“Google Maps wurde auf dieser Seite nicht richtig geladen.”
“При загрузке Google Карт на этой странице возникла проблема.”

Lo más probable es que necesites esta corrección; si estás usando WordPress, hemos creado un plugin que debería solucionar esto para la mayoría de los usuarios cuyo plugin o tema está causando este problema, puedes encontrarlo aquí: CORRECCIÓN DE CLAVE API DE GOOGLE MAPS

Si no estás usando WordPress, deberás encontrar tu llamada a Google Maps en el código fuente y añadir la clave de API. Puedes encontrar instrucciones para crear una clave de API aquí. Una vez que tengas tu clave de API, añádela a tu llamada al archivo de Google Maps maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE

Espero que esto te haya resultado útil; los comentarios siempre son bienvenidos.

The GeoDirectory Team.

Nos complace anunciar el soporte para Snazzy Maps en nuestro complemento Custom Google Maps (1.0.5).

¿Qué es Snazzy Maps?

Snazzy Maps es un recurso online que permite a los usuarios personalizar los colores, la saturación y otras opciones de estilo de sus Google Maps.

Las opciones de personalización se ofrecen en forma de diferentes estilos de mapa diseñados por diversos autores en la web.

Además de editar mapas con Snazzy Maps, los usuarios pueden crear sus propios estilos de Snazzy Maps para utilizarlos en sus sitios web o aplicaciones.

Todos los mapas personalizados también ofrecen imágenes satelitales de alta resolución y soporte vectorial tanto para dispositivos web como móviles.

Con estas funciones, tanto empresas como desarrolladores pueden crear mapas visualmente atractivos para sus proyectos sin necesidad de conocimientos de programación.

¿Por qué añadimos soporte para Snazzy Maps en GeoDirectory?

Hace poco más de una semana, uno de nuestros miembros, `Pieter Ravelli`, nos llamó la atención sobre el sitio web, y caló hondo en el equipo, por lo que fue elevado a lo más alto de nuestras tareas de desarrollo.

Esto define nuestra filosofía aquí en GeoDirectory. Si un miembro puede sugerir algo que beneficie a todos los miembros, lo añadiremos encantados.

Importar estilos de Snazzy Maps en GeoDirectory

Añadir estilos de Snazzy Maps al complemento Custom Maps de GeoDirectory es relativamente sencillo.

Primero, ve a snazzymaps.com y encuentra o crea un estilo que te guste.
Una vez que estés en la página que te gusta, verás un botón de copiar. Haz clic en él.
A continuación, ve a la configuración de GeoDirectory y dirígete a GD>Custom Google Maps>Manage Styles y haz clic para editar el mapa que deseas cambiar.
En la pantalla de edición de estilos de mapa, haz clic en el botón
Now your new map styles will be used on your site.

Are you using Snazzy Maps with GeoDirectory? If yes, which style are you using? Let us know in the comments down below.

El plugin de directorio para WordPress más avanzado y escalable del mundo