Réécrire les fonctions WordPress
- 2 - Article, page et catégories : organiser son contenu dans WordPress
- 2 - Champs personnalisés dans WordPress : attention à la performance
- 3 - La pire idée avec WordPress : “faire faire son SEO par Yoast”
- 4 - Réécrire les fonctions WordPress
Quand on commence tout juste à bidouiller, c’est tentant de réécrire les fonctions de WordPress.
- on ne sait pas qu’une fonction existe
- on a trouvé la fonction, mais on ne sait pas comment l’utiliser
- ça va tellement plus vite de faire une simple requête SQL
Alors voilà, c’est simple, si vous n’avez pas envie de prendre de l’aspirine en lisant cet article, retenez simplement la règle de base :
Il faut toujours utiliser les fonctions WordPress quand elles existent, et éviter de les réécrire.
Et les “fonctions WordPress”, cela recouvre un champ d’application assez large, y compris toutes les requêtes SQL faites sur les tables standard (ou presque).
Alors voilà donc les 5 bonnes raisons pour éviter de réécrire les fonctions WordPress
- ça va plus vite d’utiliser ce qui existe
- c’est plus sécurisé, en particulier pour toutes les requêtes qui mettent la base de données à jour
- c’est nettement plus stable sur le long terme (ça fait longtemps que je n’avais pas parlé de compatibilité ascendante)
- c’est plus performant
- si ça ne vous suffit pas comme raison, … vous me faites confiance, non ?
C’est plus performant
Le code de WordPress est “plutôt bien écrit”. En tout cas, même si il y a par ci, par là, des petites imperfections, il tient bien la route.
Les différentes fonctions sont écrites de façon logique, optimisée, en faisant appel à une API globale, plutôt cohérente.
Dans de nombreux cas (utiliser une page pour présenter des catégories par exemple) cela revient à doubler le code, donc à charger plus de fichiers.
Cela peut aussi conduire à multiplier les requêtes pour rien. Toujours dans l’exemple de la page pour la catégorie, le chargement d’une page au sens WordPress implique d’avoir une requête pour aller cherche le contenu de la page (le fameux the_content(), et ça vous n’y pouvez rien, c’est dans l’organisation de WordPress), puis, sans que cette requête soit fermée, une seconde requête, pour afficher les articles de la catégorie.
Pour peu qu’on oublie de libérer cette deuxième boucle, on se trimballe peu à peu avec des variables chargées en mémoire, et on pleure que WordPress n’est pas performant.
C’est plus stable sur le long terme
Et là, je vous parle d’expérience, ayant, à mes débuts, commis ces erreurs, j’en ai payé lourdement le prix… au moment de la mise en place des custom taxonomies, justement, où le schéma des tables a changé, et où j’ai du recoder toutes mes requêtes liées aux catégories, sur quatre ou cinq sites, parce que j’avais jugé plus malin de faire mon propre SQL.
Bref, WordPress est un CMS qui respecte la compatibilité ascendante. Chaque nouvelle version est capable de comprendre les fonctionnalités des versions précédentes (sauf cas extrêmement rare et documenté) pendant un temps certain.
Mais pour bénéficier de cette comptabilité, il faut utiliser l’API, donc les fonctions WordPress, au lieu de les réécrire.
Toujours dans mon exemple de catégories, utiliser wp_query avec comme les arguments de catégories est beaucoup plus simple.
D’abord c’est plus clair qu’une longue requête SQL.
Ensuite, il est de la responsabilité de WordPress de faire que cela marche toujours. Donc si ils déplacent les catégories et les termes ailleurs, la fonction qui génère le SQL, wp_query, sera modifiée en même temps, et pour vous cela sera transparent.
C’est encore plus vrai pour les requêtes d’insertions, de modification ou de suppression, où des paramètres peuvent être modifiés, supprimés, ajoutés.
En revanche, quand on code soi-même son SQL… WordPress ne peut rien deviner.
C’est plus sécurisé
Si les requêtes de sélection, pas passées en paramètres (typiques de cette fameuse “page” pour les catégories) ne présentent pas de gros risques, il en va tout à fait différemment de tout ce qui est requêtes modifiant d’une façon ou d’une autre les valeurs de la base de données.
“ça ne se voit” sans doute pas, mais il y a plusieurs niveaux de sécurité dans le code wordpress, un qui est mis à disposition avec wpdb->prepare, et d’autres qui sont intégrés aux fonctions, et qui vont vérifier la qualité des informations transmises, éviter les hacks, éviter les incohérences dans la base de données, etc.
Si on sait ce qu’on fait, il est bien sûr possible de recoder tous les contrôles soi-même, mais est-ce utile ?
De plus, en cas de mise à jour pour risque de sécurité, on n’en bénéficiera pas.
Ça va plus vite
Cela semble effectivement plus rapide d’écrire 4 lignes de MySQl dans un template de page, mais en réalité, si on veut faire les choses proprement, en ayant en tête les impératifs de performance, de stabilité, et de sécurité, il faut plus de quatre lignes. (Ne serait-ce que pour mettre les arguments de la requête en variable, évitant ainsi le hard-coding des paramètres).
Découvrir le codex et trouver la bonne fonction prend effectivement du temps, ça s’appelle de l’auto-formation.
Une fois qu’on les connaît, il est nettement plus rapide d’écrire un query_posts avec les arguments, et s’arrêter là, que de refaire toute la requête.
Le prochain article dans la série “les erreurs à ne pas faire dans WordPress” vous expliquera pourquoi il faut utiliser les plugins, enfin “les bons” plugins.
Allez, avoue, t’as des actions chez eux en plus ?
Bon bon bon, ça fait pas de mal de nous parler un peu de la compatibilité ascendante…
C’est malheureusement pas toujours le cas (j’en fais les frais avec un autre CMS, j’en pleurerais).
++
Il y a vraiment déjà qui réécrive les fonctions de WordPress ?
A leur décharge, même si le codex est bien foutu, pas évident d’imaginer toutes les fonctions à disposition dans WP (à moins de parcourir de long en large le code source…)
En voilà un article plein de bon sens. Je ne peux qu’approuve tout ce que tu dis ici : il ne faut jamais réécrire les fonctions de WordPress. Et surtout, on peut les modifier à la volée avec des filtres et des actions, rendant son plugin ou son thème bien plus compatible, sécurisé ou performant que le fait d’aller taper dans le coeur.
Le seul défaut de cette vision, c’est surtout qu’elle implique de bien connaître les fonctions de WordPress. Je sais que le codex est là pour palier à ces défauts, mais j’avoue que de prime abord il est un peu difficile de le prendre en main…
Oui d’autant plus que la document wordpress est également plutôt bien faite et que de ce fait, l’utilisation et le bidouillage des fonctions existantes et relativement facile, même pour un non initié. Après bien sur, il faut aimer mettre les mains dans cambouis et prendre le risque de tout casser mais c’est une autre histoire !
Bonjour
Daniel me retire les mots de la bouche, le fait d’utiliser les fonctions WordPress nous permet de bénéficier des filtres et actions.
Il existe des cas où le code PHP sera plus performant que WordPress mais là on touche à la personnalisation extrême et en faisant ça, on sait qu’on perd les filtres et la compat, l’envie est grande parfois.
Il y a au moins une fonction que je n’utilise plus :
get_the_ID() (et the_ID(), idem). Elle est gourmande et si elle est bien utilisée dans la boucle, un simple $GLOBALS[‘post’]->ID; est identique.
L’exception qui confirme la règle dira-t-on.
Merci pour cet article et cette suite d’articles, je savais avant de cliquer que j’aurais lu du bon et j’ai eu raison !
Je me suis déjà fait piéger en ajoutant certaines fonctions soi-disant pour accélérer le chargement du site.
Mais par la suite, bloquer, plus possible de faire une mise à jour, et léger bug sur un menu. Du coup j’ai restaurer une sauvegarde, mais avant j’ai copier/coller mes pages faites depuis le dernière sauvegarde et j’ai du les recréer à l’identique. Donc je confirme rester dans le code d’origine et acheter un bouquin sur les fonctions de WP, vous gagnerez du temps.
j’ai un blog sous WordPress et j’ai faillis passer du côté obscur ^^.
J’ai tenté de trouver des infos sur le codex mais il faut croire que j’ai mal cherché. J’ai donc commencé à écrire une fonction par moi même et heureusement au bout de quelques minutes (un peu moins d’une heure) j’ai trouvé une fonction toute faite :).
Bref maintenant je préfères passer du temps à chercher sur le Codex :)
Effectivement réécrire une fonction wordpress peut s’avérer une perte de temps importante alors quelle existe déjà.
Il peut être plus simple de chercher dans le codex où toutes les fonctions sont répertoriés par catégories dans la page function reference.
Cependant le nombre de fonctions répertoriées dépasse les 1800. Il faudra alors prendre le temps de chercher si la fonction recherchée existe et ce n’est pas si évident.
En s’armant de patience et d’une bonne thermos de café bien serré on peut trouver souvent la fonction recherchée. j’ai trouvé ainsi des fonctions fortes utiles comme pouvoir envoyer des mails depuis une page wordpress “wp_mail()” ou bien pour savoir si l’utilisateur consultant le blog le fait à partir d’un périphérique mobile “wp_is_mobile()”.
La patience est la mère des vertus.
En tant que débutant, j’ai souvent tendance à prendre des thèmes en anglais, et donc je modifiais systématiquement les mots dans le code du thème comme home, phone…
Je me suis trouvé embêté à la mise à jour du thème…