Les 12 pires erreurs commises par les développeurs WordPress avancés

WordPress est un moyen très populaire de mettre en place un site et de le faire fonctionner rapidement. Cependant, dans leur hâte, de nombreux développeurs finissent par prendre des décisions horribles. Certaines erreurs, comme laisser WP_DEBUG défini sur true , peuvent être faciles à commettre. D'autres, comme regrouper tout votre JavaScript dans un seul fichier, sont aussi courants que les ingénieurs paresseux. Quelle que soit l'erreur que vous réussissez à faire, lisez la suite pour découvrir les 12 erreurs WordPress les plus courantes commises par les développeurs débutants et expérimentés. Si vous vous retrouvez à commettre l'une de ces erreurs, ne désespérez pas. Chaque erreur est une occasion d'apprendre.

1. Placer le code JavaScript du thème WordPress dans un fichier principal

Une fois, alors que j'optimisais la vitesse des pages pour les sites Web d'un client, j'ai remarqué qu'il utilisait un thème premium contenant toutes les bibliothèques qu'il utilisait, y compris le code personnalisé, dans un seul fichier appelé main.js , theme.js ou custom.js . Cette pratique est mauvaise pour les raisons suivantes :

1. Le fichier, avec le temps, peut devenir très volumineux car le thème, en cours de développement actif, augmentera en fonctionnalités et vous verrez parfois des fichiers d'une taille pouvant atteindre 1 Mo. Le fichier sera chargé sur l'ensemble du site même si seulement 10 % du code du fichier est nécessaire dans certaines pages. Cela rendra les pages plus longues à télécharger et plus lentes à afficher, surtout s'il s'agit d'un code bloquant l'affichage dans la section d'en-tête de la page.
2. Cela rend la gestion du code à l'intérieur du fichier plus difficile, car vous ne pouvez pas utiliser des fonctions telles que wp_dequeue_script() pour décharger une partie du code dans certaines pages afin d'améliorer la vitesse de la page ou d'éviter un conflit avec un autre code JavaScript qui pourrait être chargé par l'un des plugins actifs. Bien sûr, le fichier peut être divisé en plusieurs fichiers et mis en file d'attente dans WordPress, mais si, ultérieurement, l'administrateur du site Web effectue une mise à jour du fichier main.js du thème, l'ensemble du processus doit recommencer.

2. Utiliser des noms trop courants pour les variables, les fonctions, les constantes ou les classes

Lors du développement d'un plugin, il est préférable d'utiliser une convention de nommage qui empêche les conflits de code au cas où d'autres plugins utilisent le même nom. C'est pourquoi de nombreux développeurs préfixent leurs noms de variables et de fonctions avec quelque chose d'unique et lié au plugin lui-même. En plus d'éliminer les conflits de code, cela facilite également la recherche lorsque de nombreux plugins sont activés.

Certains développeurs, en revanche, préfèrent utiliser les espaces de noms PHP pour encapsuler des éléments et résoudre les deux problèmes rencontrés par les auteurs de bibliothèques et d'applications lors de la création d'éléments de code réutilisables tels que des classes ou des fonctions :

1. Collisions de noms entre le code qu'ils créent et PHP interne ou tiers, classes, fonctions ou constantes
2. Possibilité d'alias (ou de raccourcir) Extra_Long_Names conçu pour résoudre le premier problème ou améliorer la lisibilité du code source. Celui-ci est mon préféré car je développe souvent des thèmes ou des plugins qui ont beaucoup de code. Avec cela, je peux lire et gérer le code facilement sans avoir à me soucier d'avoir de longs noms uniques.

Je recommanderais une bonne compréhension des espaces de noms avant de les utiliser car ils peuvent souvent être utilisés dans le mauvais sens.

Selon le projet que vous allez entreprendre, il est probable que vous deviez vous en tenir au style de codage existant, à moins que votre travail ne soit principalement séparé de celui existant. Si vous devez étendre un plugin ou un thème existant qui suit déjà les normes de codage PHP pour WordPress, il est préférable de s'y tenir afin d'avoir un style cohérent afin que le code devienne propre et facile à lire. Notez que certaines règles sont universellement appliquées afin d'améliorer les performances, quel que soit le style de codage. Par exemple, il est toujours préférable d'utiliser des guillemets simples (au lieu de doubles) si vous n'évaluez rien dans la chaîne. En outre, le code doit être indenté pour être lu, en particulier s'il contient du code imbriqué (par exemple, des IF dans des IF , des FOREACH et des FOR imbriqués).

3. Ne pas tirer parti des fonctionnalités de base de WordPress existantes à son véritable potentiel

Comme WordPress est livré avec une suite de bibliothèques régulièrement mises à jour qui peuvent être simplement appelées dans nos plugins et thèmes, il est préférable d'utiliser autant que possible les fonctionnalités de base existantes. J'ai vu des thèmes et des plugins WordPress qui avaient des fichiers dans leur répertoire d'actifs qui étaient déjà dans les fichiers principaux de WordPress (par exemple, jQuery ou Color Picker). Outre le fait que le paquet deviendra plus gros et prendra plus de temps à se charger sur le réseau, vous devez également vous assurer que toutes les bibliothèques tierces sont régulièrement mises à jour, ce qui n'est qu'une autre chose à prendre en charge.

Tirez parti de ce que WordPress a déjà à offrir, car les bibliothèques sont déjà mises à jour par l'équipe principale de développement de WordPress et vous pouvez avoir un projet léger et plus facile à entretenir. En faisant régulièrement des mises à jour WordPress, vous avez accès à plus de fonctionnalités (qu'il s'agisse d'un plugin, d'un thème ou du noyau WordPress lui-même car son tableau de bord est constamment amélioré) et rendez le site Web plus sécurisé au cas où des vulnérabilités seraient trouvées dans les anciennes versions de code.

4. Ne pas rendre le plugin ou le thème facile à modifier via des actions et des filtres

Éditer directement un plugin ou un thème WordPress est une mauvaise idée, à moins, bien sûr, que vous ne soyez directement impliqué dans le développement de ce package et que vous contribuiez à son code. Si une mise à jour automatique est effectuée sur le plugin ou le thème, toutes les modifications directes apportées au package seront perdues et vous devrez à nouveau modifier les fichiers.

C'est pourquoi l'utilisation d'actions et de filtres ainsi que la création d'un thème enfant (qui étend le thème parent) sont les approches les plus efficaces pour modifier un thème puisque vous pouvez modifier la fonctionnalité existante sans modifier le thème parent ou le plugin lui-même. De plus, si vous proposez un plugin en téléchargement gratuit sur WordPress.org et que plus tard vous souhaitez créer une extension premium qui dépendrait du plugin parent, alors vous devriez développer le plugin gratuit de manière à ce qu'il être facile à étendre et à ajouter des extensions premium.

5. Développer avec WP_DEBUG Définir sur false

Par défaut, la constante WP_DEBUG est définie sur "false" pour éviter d'afficher les erreurs, avertissements et avis PHP. Dans un environnement réel, il s'agit d'un choix recommandé car il garde les chemins de serveur privés et les scripts cachés de la vue publique, ce qui est excellent pour des raisons de sécurité. Cependant, pendant la phase de développement, il est préférable de l'avoir défini sur "true" car il nous informera de toute erreur dans notre code. Même si les erreurs n'affectent pas directement la fonctionnalité, cela vous obligera souvent à écrire un meilleur code et à développer de meilleures habitudes de codage. Cela m'est arrivé. Cela garantira également que le plugin ou le thème que vous développez ne génère pas d'erreurs PHP dans aucune installation WordPress.

Bien que ce soit quelque chose que la plupart des développeurs expérimentés font, cela arrive, surtout dans la précipitation. Quelle que soit l'urgence du travail, les développeurs doivent toujours essayer de maintenir les normes de codage WordPress, avec un œil évident sur les meilleures pratiques PHP.

6. Écrire du code PHP sans considérer que la page pourrait être mise en cache un jour

Il s'agit d'une erreur PHP courante et, comme la précédente, il est relativement facile de l'éviter si vous vous en tenez aux normes de codage PHP.

Certains développeurs ont l'habitude d'implémenter des extraits PHP dans des thèmes et des plugins qui ne sont valides que si le code PHP est déclenché tout le temps. Par exemple, une fonction PHP qui répond à l'agent utilisateur HTTP avec certaines actions doit être prise ou non (par exemple, mettre en file d'attente des scripts destinés uniquement aux utilisateurs mobiles).

Si votre client installe un plugin qui met en cache la page (par exemple, W3 Total Cache ou WP Rocket) sans déclencher les conditions dans votre thème ou vos plugins, votre code PHP sera rendu inutile. Si l'intention est de rendre les pages réactives, cela doit être fait du côté frontal via des requêtes multimédias et JavaScript. Ce dernier, seulement si c'est vraiment nécessaire. Idéalement, vous voulez éviter d'utiliser JavaScript pour rendre votre site réactif.

7. Ne pas suivre les modifications apportées de manière professionnelle via un système de contrôle de version tel que Git

Les fichiers codés de manière personnalisée, tels qu'un thème enfant ou un plugin personnalisé, doivent idéalement être sous contrôle de version. Git crée un enregistrement de ce qui a été modifié et permet aux développeurs de travailler ensemble sur le même projet WordPress ou de revenir facilement à une version précédente en cas de problème avec le site Web. De plus, les clients peuvent utiliser Git pour garder une trace de tout l'historique de travail effectué par tous les développeurs qui ont été embauchés pour ce projet particulier, surtout s'il s'agissait d'un grand site Web personnalisé WordPress à long terme.

Bien que cela puisse être intimidant au début, en particulier pour les développeurs juniors, comprendre Git vaudra la peine et un logiciel d'interface graphique Git tel que SourceTree (l'un de mes favoris) serait simplement la façon dont vous interagissez avec vos référentiels Git, rendant l'ensemble courbe d'apprentissage plus agréable. Une fois que vous avez compris comment cela fonctionne, pensez à consulter les meilleures pratiques et astuces Git des développeurs Toptal qui expliquent plus en détail quelques façons d'utiliser Git.

8. Mise en file d'attente des fichiers CSS et JavaScript lorsqu'ils ne sont pas nécessaires

Avoir de nombreuses requêtes HTTP ralentirait le chargement du site Web, ce qui aurait un score inférieur dans Google PageSpeed, ce qui affecterait probablement le classement de la recherche. Cela pourrait également entraîner des erreurs JavaScript en raison de conflits entre les plugins. Par exemple, il peut y avoir deux plugins utilisant une bibliothèque jQuery commune, qui peut être chargée deux fois et peut causer des problèmes. Et vraiment, c'est le meilleur exemple, car jQuery est très souvent chargé plusieurs fois sur des sites Web en direct. Cela se produit probablement en raison de plugins ou de thèmes mal écrits.

9. Utilisation de fichiers .php pour générer du code CSS ou JavaScript au lieu de fichiers statiques .css et .js

J'ai vu des thèmes et même des plugins WordPress contenant des fichiers tels que style.php qui étaient utilisés uniquement pour générer du code CSS personnalisé et l'imprimer. Des éléments tels que les couleurs, les tailles de police et l'espacement autour des éléments ont été définis dans les paramètres du thème, puis enregistrés dans la base de données. Ensuite, style.php est lu (par exemple, <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) et génère le code CSS en fonction des paramètres personnalisés qui ont été mis à jour dans le tableau de bord.

C'est vraiment une mauvaise pratique en termes de performances de WordPress. Voici les principaux inconvénients qui en découlent :

1. Comme le fichier CSS se charge dans la balise head (ce qui est normal et la plupart d'entre eux se chargent comme ceci), il y a un problème de performances qui vient avec cela car le navigateur doit télécharger complètement le fichier avant de rendre la page. Si l'environnement WordPress est lent à cause de certains plugins, cela retardera considérablement le temps de chargement. Même si des techniques de mise en cache sont utilisées ou qu'une partie seulement de l'environnement WordPress est chargée afin de récupérer les valeurs de la base de données. Il est préférable d'utiliser un fichier .css statique à la place.
2. Dans le fichier PHP, le code (règles CSS mélangées avec des variables PHP et des clauses conditionnelles) sera plus difficile à lire par les développeurs lorsqu'ils auront besoin de vérifier quelque chose. Bien sûr, le fichier peut être exécuté dans le navigateur (bien que je sois sûr que lorsqu'il sera imprimé, il ne sera même pas en retrait ou beau) mais si vous avez une copie locale du projet et parcourez le code du thème et vous avez besoin pour trouver une syntaxe CSS ou JavaScript (au cas où script.php serait utilisé), cela rendrait la lisibilité plus difficile.

La solution : enregistrez tout CSS personnalisé en dehors du répertoire du plug-in. Exemple : /wp-content/uploads/theme-name-custom-css/style-5.css . De cette façon, si le thème ou le plugin est mis à jour, le fichier personnalisé ne sera pas perdu.

10. Ne pas utiliser la bonne architecture (organisation du code) pour les plugins et thèmes WordPress

Selon la taille et la nature du plugin (par exemple, un plugin autonome ou une extension de plugin qui ne fonctionne que si un plugin principal est activé comme WooCommerce), la bonne architecture et l'organisation du code doivent être mises en place.

Si vous devez créer un plugin WordPress à usage unique pour un client et qu'il a une interaction limitée avec le noyau WordPress, les thèmes et d'autres plugins, il n'est pas efficace de concevoir des classes complexes à moins que vous ne soyez certain que le plugin va se développer considérablement plus tard. au.

Si le plugin doit être riche en fonctionnalités avec beaucoup de code, alors l'utilisation d'une approche de codage de programmation orientée objet (OOP) (ayant beaucoup de classes) aurait du sens. Par exemple, si vous avez beaucoup de shortcodes, vous pouvez tous les conserver dans un fichier de classe séparé tel que class.shortcodes.php ou s'il existe des fichiers CSS et JavaScript destinés à être chargés dans le tableau de bord et la vue frontale. alors une classe telle que class.scripts.php peut être utilisée et mettre en file d'attente les fichiers frontaux dans une méthode telle que enqueue_public_scripts() tout en mettant en file d'attente les fichiers destinés à être chargés dans la zone d'administration dans la méthode enqueue_admin_scripts() .

Au lieu de mélanger le code HTML avec le code PHP, il est préférable de le garder séparé en implémentant le modèle MVC dans les plugins et les thèmes. Un bon exemple est le plugin WooCommerce. Il contient des modèles pour diverses mises en page qui peuvent également être écrasés facilement via le thème ou divers filtres simplement parce que la logique est séparée de la conception. Le modèle contenant la mise en page HTML est principalement utilisé pour imprimer les informations déjà traitées. Avoir du code HTML dans les méthodes PHP est généralement une mauvaise pratique (il y a bien sûr des exceptions pour les petits morceaux de code HTML), en particulier pour un plugin qui est maintenu par plus d'un développeur à mesure qu'il grandit.

Selon le WordPress Plugin Handbook, bien qu'il existe un certain nombre de modèles d'architecture possibles, ils peuvent être regroupés en trois variantes :

• Fichier de plugin unique, contenant des fonctions
• Fichier de plug-in unique, contenant une classe, un objet instancié et, éventuellement, des fonctions
• Fichier de plugin principal, puis un ou plusieurs fichiers de classe

11. Ne pas prendre au sérieux la sécurité de WordPress lors de l'écriture de code

La sécurité n'est souvent pas prise au sérieux dans le développement WordPress, car de nombreux développeurs novices se concentrent davantage sur les résultats souhaités par le client. Tout va bien jusqu'à ce que le site Web du client soit piraté ou que votre plugin publié sur WordPress.org présente une vulnérabilité, laissant des milliers de sites Web affectés. Ces choses se produisent parfois et même le noyau de WordPress a traité un bon nombre de vulnérabilités de sécurité depuis les premiers jours du CMS. Il est de notre responsabilité de le rendre aussi sûr que possible et, au cas où quelque chose se produirait, d'agir rapidement et de nous assurer que nous publions un correctif solide et bien testé.

Voici quelques-uns des conseils de sécurité les plus importants :

Vulnérabilités XSS : Pour éviter cela, deux choses doivent être faites : assainir les données d'entrée et assainir les données de sortie. Selon les données et le contexte dans lequel elles sont utilisées, il existe plusieurs méthodes dans WordPress pour nettoyer le code. Il ne faut pas faire confiance aux données d'entrée, ni aux données qui vont être imprimées. Une fonction courante pour nettoyer l'entrée de données est sanitize_text_field() . Il vérifie les caractères UTF-8 non valides, convertit les caractères < uniques en entités HTML, supprime toutes les balises, supprime les sauts de ligne, les tabulations et les espaces blancs supplémentaires et supprime les octets. En ce qui concerne l'impression de données, un bon exemple de sortie de liens est la fonction esc_url() , qui rejette les URL invalides, élimine les caractères invalides et supprime les caractères dangereux.

Empêchez l'accès direct à vos fichiers : les fichiers sont accessibles directement, car la plupart des hébergeurs le permettent. Cependant, si cela se produit et que le code n'est pas correctement écrit pour y faire face, certaines erreurs peuvent être affichées (par exemple, des fonctions ou des variables manquantes qui ne sont pas déclarées) qui contiendraient des informations précieuses pour les attaquants potentiels. Un extrait de code courant que vous voyez souvent dans les plugins et les thèmes est :

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Si la constante ABSPATH n'est pas définie (ce qui devrait être le cas pour toute installation WordPress), le script se fermera et n'imprimera rien.

Utiliser des nonces : comme indiqué dans la documentation de WordPress, un nonce est un « nombre utilisé une fois » pour aider à protéger les URL et les formulaires contre certains types d'utilisation abusive, malveillante ou autre.

Par exemple, l'URL suivante dans le tableau de bord serait utilisée pour supprimer une publication : http://example.com/wp-admin/post.php?post=123&action=trash : lors de l'accès à cette URL, WordPress validera les informations du cookie d'authentification. et si vous avez la bonne permission (par exemple, vous êtes un administrateur avec tous les privilèges), ce message sera supprimé.

Un attaquant pourrait faire en sorte que votre navigateur accède à cette URL à votre insu en créant un lien sur une page tierce comme dans l'exemple suivant : <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Lors de cette demande à WordPress, le navigateur attachera automatiquement votre cookie d'authentification et WordPress considérera la demande comme valide.

C'est à ce moment qu'un nonce entre en place car l'attaquant ne pourra pas obtenir la valeur du nonce (générée pour l'administrateur qui est réellement connecté à WordPress) aussi facilement. La nouvelle URL de requête ressemblerait à ceci : http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Sans un nonce valide, une réponse 403 Forbidden serait envoyée au navigateur par WordPress avec le message d'erreur bien connu : « Are you sure you want to do this ?

Bien que la plupart des gens ne prennent pas au sérieux la sécurité de WordPress, pensant que leur site Web ne serait jamais piraté, faisant confiance à l'hébergement (ce qui peut être utile, mais seulement jusqu'à un certain point) et au fait qu'ils ont acheté des plugins/thèmes commerciaux (qui conduisent souvent à l'hypothèse qu'ils sont très sécurisés), nous devrions toujours faire des tests de pénétration pour nos sites Web afin d'identifier les vulnérabilités exploitables avant qu'un pirate ne puisse les identifier et les exploiter.

Notez qu'un grand nombre de piratages ne sont même pas effectués par une seule personne avec l'intention de pirater spécifiquement votre site Web. Souvent, il y a des bots qui analysent automatiquement les sites Web WordPress de manière cohérente et dès qu'une vulnérabilité connue est trouvée, elle est exploitée et le serveur est utilisé pour spammer, obtenir des informations privées de la base de données, placer des liens cachés dans certaines pages du site Web qui conduirait à toutes sortes de sites Web douteux (par exemple, pornographie, drogues illicites). Parfois, les hacks sont si bien cachés que vous avez besoin d'une analyse appropriée de votre site Web et de voir la date à laquelle des fichiers spécifiques ont été mis à jour afin de détecter le code piraté. C'est pourquoi il est même bon de réinstaller WordPress (oui, la même version si vous avez la dernière) afin que tous les fichiers piratés soient écrasés par les fichiers de base WordPress authentiques.

12. Utiliser les fonctions WordPress et les extraits de code sans les comprendre

Souvent, lorsque les développeurs sont bloqués et trouvent une solution sur des endroits comme StackOverflow, ils sont simplement satisfaits du fait qu'ils ont réussi à faire fonctionner quelque chose sans se soucier de comprendre la logique derrière ce code ou si ce code peut être modifié pour se charger plus rapidement ou avoir moins lignes de code.

J'ai vu cette pratique tant de fois lorsque des extraits de code sont copiés dans des scripts PHP alors qu'un tiers seulement de ce code est réellement utilisé.

Cela peut avoir quelques inconvénients, notamment :

1. Le code n'utilise pas le même style que le code de projet existant. Oui, il est confortable de simplement copier et coller des extraits qui fonctionnent immédiatement et, même s'ils conviennent à un petit projet personnel (cela pourrait devenir un grand projet un jour, qui sait), cette pratique n'est souvent pas bonne quand elle vient au travail commercial où une cohérence de style doit être conservée.
2. Bien que le code fasse son travail, il peut contenir des fonctions inefficaces qui ne sont pas recommandées pour la tâche à accomplir. Si le code n'est pas optimisé, cette pratique de « copier-coller » peut conduire à un site Web lent et plus difficile à entretenir, en particulier si plusieurs extraits sont utilisés à différents endroits du projet.
3. Le code peut ne pas être autorisé à être réutilisé, et l'inclure dans le projet d'un client peut lui ouvrir de nombreux problèmes juridiques.

Amélioration constante

Tout le monde fait des erreurs, et chaque erreur est une opportunité de s'améliorer. En tant que développeurs WordPress, notre industrie évolue à un rythme très rapide, et il n'y a jamais de « bonne façon » de faire les choses. Cependant, plus vous pratiquez et apprenez, meilleur vous deviendrez.

Êtes-vous en désaccord avec l'une des erreurs que j'ai signalées ou pensez-vous que j'en ai oublié une ? Faites-le moi savoir dans les commentaires et nous en discuterons.