Quand on commence tout juste à bidouiller, c’est tentant de réécrire les fonctions de WordPress.

  1. on ne sait pas qu’une fonction existe
  2. on a trouvé la fonction, mais on ne sait pas comment l’utiliser
  3. ç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

  1. ça va plus vite d’utiliser ce qui existe
  2. c’est plus sécurisé, en particulier pour toutes les requêtes qui mettent la base de données à jour
  3. c’est nettement plus stable sur le long terme (ça fait longtemps que je n’avais pas parlé de compatibilité ascendante)
  4. c’est plus performant
  5. 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.

Que pensez-vous de cet article ?
Super0
Bien0
Bof0
Nul0
Poster un commentaire