Blog - Page 9 of 9 - GeoDirectory

Advanced Custom Fields est un plugin fantastique utilisé par des millions de personnes qui transforme WordPress en un CMS full-stack, vous permettant de créer des groupes de champs personnalisés et des types illimités, et de les ajouter à n'importe quel type de contenu personnalisé.

Cependant, peu de personnes connaissent les limites de scalabilité d'Advanced Custom Fields.

Il nous est souvent demandé si GeoDirectory utilise Advanced Custom Fields pour gérer les champs personnalisés des annonces.

Lorsque nous répondons que GeoDirectory dispose de son propre système de champs personnalisés intégré, ils se demandent pourquoi nous avons décidé de « réinventer la roue ».

Si la réponse nous semble évidente, la scalabilité d'Advanced Custom Fields est assez limitée pour la création d'annuaires.

Nous avons pensé que peut-être, en tant qu'utilisateurs, ils n'ont pas conscience de ce qui se passe sous le capot ni des défis de scalabilité qu'un annuaire web peut poser.

Cependant, il n'y a pas si longtemps, nous sommes tombés sur un sondage dans un groupe WordPress populaire sur Facebook, où les options pour voter pour le « Meilleur Annuaire » étaient : GeoDirectory, quelques autres thèmes d'annuaire disponibles sur des marketplaces populaires, et il y avait également l'option ACF + FacetWP.

Quand nous avons vu les résultats, nous étions pour le moins perplexes : ACF + FacetWP avait recueilli bien plus de votes que nous ne l'aurions imaginé.

Les personnes ayant voté n'étaient pas censées être de simples utilisateurs, mais des développeurs web et des experts WordPress.

Pour cette raison, nous avons décidé qu'il était temps d'expliquer pourquoi ce n'est PAS une bonne idée d'utiliser Advanced Custom Fields pour un annuaire.

Et pourquoi les développeurs web ne devraient pas proposer cette solution à quiconque, à moins qu'ils ne se soucient pas de fournir des solutions rapides et scalables à leurs clients, capables de croître de manière durable.

Limites de scalabilité des champs personnalisés WordPress

WordPress utilise par défaut la table de base de données wp_postmeta pour stocker les données des champs personnalisés, et crée 1 ligne pour chaque champ personnalisé utilisé dans un article.

Par ailleurs, WordPress ajoute de nombreuses données supplémentaires dans cette table pour chaque article, chacune d'entre elles occupant 1 ligne de la table.

Si vous avez déjà passé du temps à optimiser des requêtes SQL, vous savez que ce n'est pas une situation idéale pour des fonctionnalités comme les annuaires et le filtrage.

En réalité, la structure de base de données par défaut représente potentiellement un énorme goulot d'étranglement pour les sites web comportant de nombreux articles et champs personnalisés.

C'est considéré comme l'un des points faibles de WordPress.

En effet, pour filtrer des articles par champs personnalisés, vous devez joindre la table wp_post à la table wp_postmeta dans votre requête.

Plus les tables grossissent, plus les requêtes deviennent lentes.

Pire encore, si vous souhaitez filtrer par deux valeurs méta, vous devrez joindre la table post_meta deux fois pour effectuer cela en une seule requête.

Cela peut consommer la mémoire système et ralentir considérablement tout ce qui dépasse un petit annuaire.

Limites de scalabilité d'Advanced Custom Fields

Le plugin Advanced Custom Fields est parfait pour tout site web avec un nombre faible ou modéré d'articles, de pages et de champs personnalisés en général.

Cependant, à quelques rares exceptions près, les annuaires sont exactement le contraire.

Ils comportent un très grand nombre d'articles avec potentiellement un très grand nombre de champs personnalisés également.

Le principal problème de scalabilité d'Advanced Custom Fields est qu'il crée 2 lignes dans la table wp_postmeta de votre base de données pour chaque champ personnalisé ajouté à une annonce.

Il ajoutera également plusieurs lignes postmeta appartenant à ses propres paramètres.

Cela signifie qu'il ajoutera plus du double des lignes dans la table wp_postmeta de votre base de données par rapport à l'utilisation du système de champs personnalisés WordPress par défaut.

Nous avons effectué un test rapide qui devrait nous aider à mieux expliquer ce point.

Nous avons créé un nouveau site WordPress, supprimé l'article « hello world » et la page exemple, puis installé Advanced Custom Fields.

Nous avons créé 1 groupe et 5 champs personnalisés, et publié 3 articles utilisant chacun les 5 champs personnalisés.

Après cela, notre table wp_postmeta comptait déjà 83 lignes.

C'est incroyable.

Imaginez le nombre de lignes pour un annuaire avec 300 000 annonces et cinq champs personnalisés.

Avec ACF, votre table wp_postmeta compterait un minimum de 3 000 000 de lignes

Comment GeoDirectory passe-t-il à l'échelle ?

C'est très simple : nous créons une table personnalisée pour chacun de nos types de publications personnalisés.

Exemple : wp_gd_gd_place_detail

Dans cette table, nous enregistrons tous les champs personnalisés et leurs données, dans une ligne par publication.

Nous avons également développé notre propre API PHP pour interroger nos tables personnalisées, tout comme WordPress dispose de sa propre API PHP pour interroger les tables par défaut de la base de données wp.

Cela signifie que GD, dans la plupart des cas, n'a qu'à faire une jointure entre la table des publications et notre table.

Nous pouvons ensuite filtrer ces résultats par N'IMPORTE QUEL champ personnalisé.

Nous pouvons filtrer par 20 champs personnalisés, tandis qu'ACF, même avec facetWP (qui accélère les choses mais conserve tout de même la limitation fondamentale), devrait effectuer des jointures sur plusieurs tables encore et encore pour accomplir le même travail en une seule requête, en utilisant plusieurs fois plus de mémoire serveur pour cette même requête.

Conclusions

Ainsi, si nous comparons GeoDirectory avec WordPress ou WP + Advanced Custom Fields, nous constatons que :

WordPress
1) Nécessite une JOIN de table supplémentaire pour chaque champ personnalisé par lequel vous souhaitez filtrer.
2) wp_postmeta grossit rapidement, ce qui ralentit les requêtes

WP + ACF

1) Nécessite une JOIN de table supplémentaire pour chaque champ personnalisé par lequel vous souhaitez filtrer.
2) wp_postmeta devient deux fois plus volumineux comparé à l'utilisation de WordPress seul

GeoDirectory

1) Aucune jointure n'est requise
2) GD n'ajoute rien à wp_postmeta, et n'y crée donc pas de données inutiles.
3) La base de données stockant les données des annonces compte 1 ligne par publication

WordPress est connu pour cette limitation dans la façon dont il stocke les données. Dans la plupart des cas, ce système fonctionne bien, mais lorsqu'il s'agit de grands annuaires, ce n'est tout simplement pas la bonne solution.

C'est pourquoi avec GeoDirectory, vous pouvez créer un annuaire avec des millions d'annonces, alors qu'avec WP + Advanced Custom Fields, vous avez de la chance si vous pouvez créer un annuaire avec quelques centaines d'annonces avant de commencer à constater de sérieux problèmes de performances.

Voici les limites de scalabilité d'Advanced Custom Fields qui nous ont poussés à ne pas l'utiliser pour GeoDirectory, et pourquoi vous ne devriez pas l'utiliser non plus.

Si vous avez des questions, n'hésitez pas à les poser dans les commentaires ci-dessous.

Les fonctionnalités de localisation de WordPress vous permettent de rendre les plugins et les thèmes facilement traduisibles via les fichiers de langue WordPress (fichiers po/mo).

C'est vrai notamment depuis WordPress 3.7 et c'est devenu bien plus simple depuis WordPress 4.6.

De nombreuses améliorations ont été apportées à l'ensemble du système de traduction de WordPress, et j'ai estimé qu'un article remis à jour s'imposait vraiment.

Les fichiers de langue WordPress – La confusion ( Édition développeurs )

Pour les développeurs, tout se résume à la façon d'indiquer à WordPress que vous disposez de fichiers de traduction de la bonne manière.

En tant que développeurs, on nous a dit d'utiliser « load_plugin_textdomain() » et de le pointer vers notre fichier de langue dans le dossier de notre plugin.

Cependant, par le passé, c'était le seul endroit où WordPress regardait et si un client y ajoutait son propre fichier de langue, celui-ci disparaissait à la prochaine mise à jour !

Il y a quelque temps, un article sur le web préconisait d'effectuer un second appel, cette fois avec la fonction « load_textdomain() », pour pointer vers un fichier dans le dossier des langues de WP, et c'est ce que beaucoup de personnes ont fait (nous y compris).

Cela permettait aux utilisateurs de placer leurs fichiers de langue à un emplacement prédéfini dans le dossier des langues de WP, et la traduction n'était ainsi pas perdue lors de la mise à jour du plugin.

Les fichiers de langue WordPress – La confusion ( Édition utilisateurs )

Les utilisateurs doivent savoir où placer une traduction personnalisée pour un plugin/thème ; le problème est que par le passé, cet emplacement pouvait être plusieurs endroits différents.

La documentation WP indique aux développeurs de créer un lien vers un dossier appelé « languages » à l'intérieur de leur dossier de plugin, mais le développeur peut utiliser le dossier « lang » et même dans ce cas, cela sera perdu lors de la mise à jour du plugin/thème.

Certains développeurs ajoutaient une seconde vérification, là encore à un emplacement choisi par le développeur, mais souvent dans un dossier au nom personnalisé dans le dossier des langues de WP.

Cela signifiait qu'il n'existait aucun moyen cohérent pour un utilisateur de savoir où placer ses fichiers de traduction personnalisés en toute sécurité.

Charger les fichiers de langue de la bonne façon (2017)

Depuis WP 4.6, c'est devenu bien plus simple, aussi bien pour les utilisateurs que pour les développeurs !

En tant que développeur, vous devez simplement vous assurer que vous chargez vos fichiers de langue correctement, en suivant la documentation WP ci-dessous :

<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 />

Notez que nous déclenchons ces actions sur les hooks 'init' et 'after_setup_theme', ce qui devrait garantir un chargement sans problème.

Si vous les déclenchez directement ou avant leurs hooks respectifs, vous risquez de rencontrer des problèmes avec certaines chaînes non traduites, et les plugins destinés à manipuler les traductions ou à créer des sites multilingues, comme WPML, pourraient ne pas fonctionner du tout.

En tant qu'utilisateurs, nous disposons désormais d'un emplacement pratique et au nommage cohérent où placer nos fichiers de langue.

Pour les plugins : /wp-content/languages/plugins/my-plugin-en_US.mo
Pour les thèmes : /wp-content/languages/themes/my-theme-en_US.mo

'my-plugin' et 'my-theme' correspondent au textdomain du plugin/thème (généralement indiqué dans le fichier readme.txt du plugin ou en haut du fichier style.css du thème).

Il s'agit d'une nette amélioration par rapport à l'ancienne méthode et cela évitera, dans la plupart des cas, de perdre les traductions lors des mises à jour.

Dans certains cas, le plugin/thème peut déjà disposer d'une nouvelle traduction dans votre langue stockée sur wp.org ; si c'est le cas, elle pourrait écraser votre fichier .mo, mais dans la plupart des situations, c'est ce que vous souhaiterez.

Vous pouvez contribuer aux traductions sur wp.org si le plugin y est hébergé ; s'il s'agit d'un plugin premium, il y a peu de chances qu'il soit écrasé.

Informations complémentaires

WordPress tentera de trouver vos fichiers de langue WordPress à plusieurs endroits ; pour un plugin avec le textdomain 'my-plugin', il cherchera d'abord ici :

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

S'il ne trouve pas de traduction à cet emplacement et que le plugin indique où en trouver une en local, il cherchera là :

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

Si le plugin ne spécifie pas de chemin, WordPress cherchera ici à la place :

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

La documentation WordPress doit être suivie, mais en réalité, à partir de WP 4.6, vous n'avez même pas besoin de spécifier un fichier local si vous n'en incluez aucun (s'ils sont stockés sur le dépôt wp.org), vous pouvez donc simplement ajouter ceci :

<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 />

J'espère que cela clarifie un peu les choses concernant les traductions, et si vous avez des questions ou quelque chose à ajouter, veuillez laisser un commentaire ci-dessous.

Mise à jour sept. 2019

Ceci a été ajouté en tant que champ personnalisé prédéfini dans la V 2.0.0.67. L'extrait de code ci-dessous ne fonctionnera qu'avec GeoDirectory V1.

Le problème

Aujourd'hui, un membre a formulé une demande quelque peu inhabituelle : il utilise GeoDirectory pour gérer un festival local et répertorie des éléments tels que des hébergements. La demande consistait à afficher la distance depuis chaque annonce jusqu'à l'événement principal, afin que les utilisateurs sachent clairement à quelle distance se trouve l'événement par rapport à chaque annonce. Je fais quelque chose de très similaire sur l'un de mes propres sites dédié à un seul lieu : j'indique la distance jusqu'à l'aéroport et la distance jusqu'au centre-ville principal. Jusqu'à présent, je laissais les utilisateurs saisir cette distance manuellement, ce qui était souvent inexact et nécessitait des corrections de ma part.

La solution

Cela semblait être l'occasion idéale de créer un nouveau champ personnalisé, appelons-le « Distance jusqu'à ». Le code est disponible ci-dessous, mais il existe deux façons d'utiliser ce champ :
#1 Nous pourrions simplement ajouter le champ et laisser l'utilisateur saisir des coordonnées GPS, par exemple pour un champ « Aéroport le plus proche » où l'utilisateur pourrait entrer les informations GPS de l'aéroport le plus proche.
#2 Dans le cas de cet utilisateur, il a simplement besoin d'afficher la distance vers un seul endroit, sans que l'utilisateur ait vraiment besoin de connaître le champ. Ainsi, lors de l'ajout du champ personnalisé, il peut le définir comme un champ « admin uniquement » afin qu'il ne soit pas visible par l'utilisateur en front-end et que celui-ci ne puisse pas le modifier, puis définir la « valeur par défaut » sur les coordonnées GPS souhaitées — toutes les annonces afficheront alors les informations requises.

Le code

Cet article vous expliquera comment résoudre le problème « This page didn't load Google Maps correctly. See the JavaScript console for technical details. » avec Google Maps.

Si vous utilisez GeoDirectory, veuillez consulter notre documentation ici.

Si vous souhaitez en savoir plus sur le problème, consultez notre article de blog ici : https://wpgeodirectory.com/google-maps-api-key-and-new-limits/

Si vous avez vu le message « This page didn't load Google Maps correctly. See the JavaScript console for technical details. » ou l'un des messages suivants :
« 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 Карт на этой странице возникла проблема. »

Il y a de fortes chances que vous ayez besoin de ce correctif. Si vous utilisez WordPress, nous avons créé un plugin qui devrait résoudre ce problème pour la plupart des utilisateurs dont le plugin ou le thème en est la cause. Vous pouvez le trouver ici : CORRECTIF CLÉ API GOOGLE MAPS

Si vous n'utilisez pas WordPress, vous devrez localiser votre appel à Google Maps dans votre code source et y ajouter la clé API. Vous trouverez des instructions pour créer une clé API ici. Une fois que vous avez votre clé API, ajoutez-la à votre appel au fichier Google Maps maps.google.com/maps/api/js?key=YOUR-API-KEY-HERE

J'espère que vous avez trouvé cela utile. Les retours sont toujours les bienvenus.

L'équipe GeoDirectory.

Nous sommes ravis d'annoncer la prise en charge de Snazzy Maps dans notre addon Custom Google Maps (1.0.5).

Qu'est-ce que Snazzy Maps ?

Snazzy Maps est une ressource en ligne qui permet aux utilisateurs de personnaliser les couleurs, la saturation et d'autres options de style de leurs Google Maps.

Les options de personnalisation sont proposées sous forme de différents styles de cartes conçus par divers auteurs sur le web.

En plus de modifier des cartes avec Snazzy Maps, les utilisateurs peuvent créer leurs propres styles Snazzy Maps pour les utiliser dans leurs sites web ou applications.

Toutes les cartes personnalisées proposent également des images satellites haute résolution et la prise en charge des vecteurs pour le web et les appareils mobiles.

Grâce à ces fonctionnalités, les entreprises comme les développeurs peuvent créer des cartes visuellement attrayantes pour leurs projets, sans avoir recours à des compétences en programmation.

Pourquoi avons-nous ajouté la prise en charge de Snazzy Maps dans GeoDirectory ?

Il y a un peu plus d'une semaine, l'un de nos membres, `Pieter Ravelli`, nous a signalé ce site, et il a immédiatement suscité l'enthousiasme de notre équipe, si bien qu'il a été placé en tête de nos tâches de développement.

C'est ce qui définit notre philosophie ici chez GeoDirectory. Si un membre peut suggérer quelque chose qui profitera à tous les membres, nous l'ajouterons avec plaisir.

Importer des styles Snazzy Maps dans GeoDirectory

Ajouter des styles Snazzy Maps à l'extension Geodirectory Custom Maps est relativement simple.

Tout d'abord, rendez-vous sur snazzymaps.com et trouvez ou créez un style qui vous plaît.
Une fois sur la page qui vous convient, vous verrez un bouton de copie. Cliquez dessus.
Ensuite, accédez aux paramètres de votre GeoDirectory et allez dans GD>Custom Google Maps>Manage Styles, puis cliquez pour modifier la carte que vous souhaitez changer.
Sur l'écran de modification des styles de carte, cliquez sur le bouton « import styles », collez le code de vos styles provenant de Snazzy Maps, puis cliquez sur le bouton « Import & Save Styles ».
Vos nouveaux styles de carte seront désormais utilisés sur votre site.

Utilisez-vous Snazzy Maps avec GeoDirectory ? Si oui, quel style utilisez-vous ? Faites-le nous savoir dans les commentaires ci-dessous.

Le plugin de répertoire WordPress le plus avancé et le plus évolutif au monde