WordPress : utiliser les champs personnalisés ?

A l’origine WordPress était une plateforme de blog. Petit à petit, le célèbre logiciel est devenu un CMS (système de gestion de contenu) permettant de créer des sites Web de toutes natures. Du simple blog au site de e-commerce, en passant pour le site Web pour une agence immobilière, WordPress est le couteau suisse des logiciels de publication sur Internet.

Pour ce faire, WordPress propose aux développeurs et intégrateurs Web plusieurs fonctionnalités. Au premier rang desquelles figurent les champs personnalisés (custom fields) et les types d’articles personnalisés (custom post types).

Prenons l’exemple d’un site Web pour une agence immobilière.

Pour les annonces publiées sur le site de l’agence immobilière il faut indiquer plusieurs informations :

• Titre de l’annonce (en standard WordPress)
• Texte descriptifs de l’annonce (en standard dans WordPress)
• Photos de l’annonce, sous forme de galerie (en standard dans WordPress)
• Référence de l’annonce
• Type d’annonce (achat, vente, location, recherche)
• Localisation : département (liste déroulante)
• Localisation : ville (liste déroulante mise à jour en fonction du département sélectionné)
• Prix ou loyer
• Charges mensuelles
• Superficie
• Nombre de pièces
• Etc.

Le fait d’utiliser des champs personnalisés permet, entre autre, d’interfacer le site Web avec un logiciel tiers, tel qu’un logiciel de gestion pour agence immobilière.

Cela permet également de mettre en œuvre un moteur de recherche multi-critères.

Pour gérer les champs personnalisés facilement et rapidement dans WordPress il existe plusieurs extensions dont Advanced Custom Fields,  Simple Fields, Types, Magic Fields, etc.

Certes ! Mais, utiliser les champs personnalisés dans WordPress présente quelques inconvénients.

Typiquement, pour une annonce immobilière, on peut être amené à gérer plus de 20 informations personnalisées. Or, pour afficher la valeur d’un champ personnalisé, WordPress effectue une requête sur la base de données. Par conséquent, pour afficher une annonce immobilière, WordPress exécutera plus de 20 requêtes là où il serait possible de le faire en une seule !

A la base, pour afficher la valeur d’un champ personnalisé, telle que la référence de l’annonce, WordPress interroge la table des métas données associées aux articles (wp_postmeta).

Dans l’exemple qui nous intéresse il serait nettement plus judicieux et surtout plus performant d’avoir une table stockant toutes les caractéristiques des annonces immobilières.

Pour l’un de nos clients, nous avons développé un site immobilier où une annonce pouvait compter jusqu’à 40 critères ! Pour ce projet il était bien évidemment totalement absurde d’utiliser des champs personnalisés, d’autant plus que certains critères sont facultatifs et d’autres obligatoires.

De plus, pour certaines informations dépendantes (le choix d’une ville par rapport à un département, par exemple) les champs personnalisés sont totalement inadaptés.

Dans le cas de notre client le site immobilier compte plusieurs dizaines de milliers d’annonces (il s’agit d’un portail immobilier). Si nous avions utilisé les champs personnalisés pour décrire les annonces immobilières, en se basant sur 20 000 annonces et 40 critères personnalisés, nous aurions donc 800 000 lignes dans la table des métas données. Mais en créant une table spécifique pour enregistrer les caractéristiques de l’annonce nous n’avons que 20 000 lignes…

Ajoutons, qu’il s’agit là d’une évaluation à la louche, car il faut aussi penser aux diverses tables de références nécessaires (départements, villes, types de bien, types de cuisine, types de chauffage, etc.).

Le modèle de données utilisé par WordPress est assez basique. Dans le cas d’un site Web simple dans ses fonctionnalités, il s’avère suffisant. Mais dès que le client souhaite une site Internet évolué de type CMS, il faut obligatoirement, comme nombre de ses confrères, recourir à des solutions de contournement.

De notre point de vue, dès qu’il est nécessaire de gérer plus de cinq informations spécifiques par article (personnalisé ou non), nous n’utilisons pas les champs personnalisés de WordPress.

En utilisant les champs personnalisés de WordPress, le site Web sera moins performant; ce qui est préjudiciable au référencement et donc aux intérêts du client.

De plus, si le client a besoin de champs personnalisés, il a également besoin d’une interface aux petits oignions pour gérer ces informations. Or, les extensions ne permettent pas de créer une interface de saisie adaptée telle que celle-ci :

Dans la mesure du possible nous évitons d’utiliser les champs personnalisés qui dégradent les performances, ce qui, du point de vue du référencement, est un facteur négatif.

Dans notre exemple, le site du portail immobilier importe chaque nuit plusieurs dizaines de milliers d’annonces immobilières en provenance de deux plateformes de diffusion. En moyenne, chaque annonce importée comporte un minimum de 25 informations spécifiques. Si nous avions utilisé les champs personnalisés pour importer ces annonces nous aurions du générer près d’une trentaine d’insertions dans la base de données ! Avec notre méthode, nous insérons seulement 3 lignes par annonces dans la base de données : une dans la table des articles (wp_posts), une dans la table des annonces (wp_annonces) et une dans la table des métas données (wp_postmeta) pour indiquer le modèle de page à utiliser pour afficher l’annonce…

Quand un internaute consulte une annonce, le portail immobilier effectue une seule requête pour afficher les données de l’annonce. En utilisant des champs personnalisés de WordPress, il aurait fallu exécuter … une requête pour chaque champ personnalisé… donc, au bas mot, 40 requêtes (ou une gigantesque requête à base de jointures) !

Bien évidemment, ne pas utiliser de champs personnalisés pour ce type de sites présente quelques inconvénients… pour le développeur du site Web. Il y passe plus de temps (pour créer les formulaires de saisie dans le back-office de WordPress, pour créer les différentes requêtes mySql et pour tester le tout). Mais au final, le client est gagnant et il est largement possible de factoriser, au moins partiellement, ce genre de développement.

Pour pallier, en partie, à ces inconvénients nous avons d’une part développé une extension et d’autre part créé un fichier de fonctions que nous pouvons utiliser en fonction du thème développé pour les sites de nos clients.

L’extension prend en charge les éléments suivants :

• Création des tables…
  • annonces immobilières
  • départements et remplissage de la table
  • villes et remplissage de la table
  • types d’annonces et remplissage de la table
  • types de biens et remplissage de la table
  • types de cuisines et remplissage de la table
  • types de chauffage et remplissage de la table
  • Etc.
• Création du type d’article personnalisé dans le back-office pour gérer les annonces

Le fichier spécifique des fonctions prend en charge les éléments suivants :

• Création du formulaire de saisie des annonces dans le back-office
• Affichage des listes déroulantes (départements, villes, types d’annonces, types de biens, etc.) avec utilisation d’ajax (pour l’affichage de la liste des villes après sélection d’un département)
• Fonctions diverses pour l’affichage des annonces sur le front-end du site
• Moteur de recherche multi-critères des annonces
• Etc.

Implémentation :

L’extension est installée comme toutes les extensions dans le dossier des plugins de WordPress. Le fichier des functions spécifiques est directement placé dans le dossier  des thèmes et est “chargé” dans le fichier des fonctions (functions.php) du thème utilisé de la manière suivante :

require(  '../extra_functions.php' );