Les 10 erreurs les plus courantes commises par les développeurs WordPress

Nous ne sommes qu'humains, et l'une des caractéristiques de l'être humain est que nous commettons des erreurs. D'un autre côté, nous nous corrigeons également, ce qui signifie que nous avons tendance à apprendre de nos erreurs et, espérons-le, à éviter de refaire les mêmes deux fois. Beaucoup d'erreurs que j'ai commises dans le domaine WordPress proviennent d'essayer de gagner du temps lors de la mise en œuvre de solutions. Cependant, ceux-ci lèveraient généralement la tête sur la route lorsque des problèmes surgiraient à la suite de cette approche. Faire des erreurs est inévitable. Cependant, apprendre des oublis des autres (et des vôtres bien sûr !) est une voie que vous devez emprunter de manière proactive.

Erreur courante n° 1 : désactiver le débogage

Pourquoi devrais-je utiliser le débogage lorsque mon code fonctionne correctement ? Le débogage est une fonctionnalité intégrée à WordPress qui entraînera l'affichage de toutes les erreurs, avertissements et avis PHP (sur les fonctions obsolètes, etc.). Lorsque le débogage est désactivé, des avertissements ou des avis importants peuvent être générés que nous ne voyons jamais, mais qui pourraient causer des problèmes plus tard si nous ne les traitons pas à temps. Nous voulons que notre code s'harmonise bien avec tous les autres éléments de notre site. Ainsi, lorsque vous ajoutez un nouveau code personnalisé à WordPress, vous devez toujours effectuer votre travail de développement avec le débogage activé (mais assurez-vous de le désactiver avant de déployer le site en production !).

Pour activer cette fonctionnalité, vous devrez modifier le fichier wp-config.php dans le répertoire racine de votre installation WordPress. Voici un extrait d'un fichier typique :

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Il ne s'agit pas d'une liste exhaustive des options de configuration pouvant être utilisées, mais cette configuration suggérée devrait être suffisante pour la plupart des besoins de débogage.

Erreur courante n° 2 : ajouter des scripts et des styles à l'aide du crochet wp_head

Quel est le problème avec l'ajout des scripts dans mon modèle d'en-tête ? WordPress inclut déjà une pléthore de scripts populaires. Pourtant, de nombreux développeurs ajouteront des scripts supplémentaires à l'aide du crochet wp_head . Cela peut entraîner le même script, mais une version différente, chargée plusieurs fois.

La mise en file d'attente ici vient à la rescousse, qui est le moyen convivial WordPress d'ajouter des scripts et des styles à notre site Web. Nous utilisons la mise en file d'attente pour éviter les conflits de plugins et gérer toutes les dépendances qu'un script pourrait avoir. Ceci est réalisé en utilisant les fonctions intégrées wp_enqueue_script ou wp_enqueue_style pour mettre en file d'attente les scripts et les styles respectivement. La principale différence entre les deux fonctions est qu'avec wp_enqueue_script nous avons un paramètre supplémentaire qui nous permet de déplacer le script dans le pied de page.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Si le script n'est pas obligé de rendre le contenu au-dessus du pli, nous pouvons le déplacer en toute sécurité vers le pied de page pour nous assurer que le contenu au-dessus du pli se charge rapidement. Il est recommandé d'enregistrer le script avant de le mettre en file d'attente, car cela permet aux autres de désenregistrer votre script via le handle de leurs propres plugins, sans modifier le code principal de votre plugin. De plus, si le descripteur d'un script enregistré est répertorié dans le tableau des dépendances d'un autre script qui a été mis en file d'attente, ce script sera automatiquement chargé avant le chargement du script mis en file d'attente en surbrillance.

Erreur courante n° 3 : Éviter les thèmes enfants et modifier les fichiers principaux de WordPress

Créez toujours un thème enfant si vous envisagez de modifier un thème. Certains développeurs apporteront des modifications aux fichiers du thème parent uniquement pour découvrir après une mise à niveau du thème que leurs modifications ont été écrasées et perdues à jamais.

Pour créer un thème enfant, placez un fichier style.css dans un sous-répertoire du dossier du thème enfant, avec le contenu suivant :

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

L'exemple ci-dessus crée un thème enfant basé sur le thème WordPress par défaut, Twenty Sixteen . La ligne la plus importante de ce code est celle contenant le mot "Template" qui doit correspondre au nom du répertoire du thème parent à partir duquel vous clonez l'enfant.

Les mêmes principes s'appliquent aux fichiers principaux de WordPress : ne prenez pas la voie facile en modifiant les fichiers principaux. Faites cet effort supplémentaire en utilisant les fonctions et les filtres enfichables de WordPress pour éviter que vos modifications ne soient écrasées après une mise à niveau de WordPress. Les fonctions enfichables vous permettent de remplacer certaines fonctions de base, mais cette méthode est progressivement supprimée et remplacée par des filtres. Les filtres obtiennent le même résultat final et sont insérés à la fin des fonctions WordPress pour permettre de modifier leur sortie. Une astuce consiste toujours à envelopper vos fonctions avec if ( !function_exists() ) lors de l'utilisation de fonctions enfichables, car plusieurs plugins essayant de remplacer la même fonction enfichable sans ce wrapper produiront une erreur fatale.

Erreur courante n° 4 : coder en dur les valeurs

Souvent, il semble plus rapide de simplement coder en dur une valeur (telle qu'une URL) quelque part dans le code, mais le temps passé sur la route à déboguer et à corriger les problèmes qui en résultent est beaucoup plus long. En utilisant la fonction correspondante pour générer dynamiquement la sortie souhaitée, nous simplifions grandement la maintenance et le débogage ultérieurs de notre code. Par exemple, si vous migrez votre site d'un environnement de test vers la production avec des URL codées en dur, vous remarquerez tout d'un coup que votre site ne fonctionne pas. C'est pourquoi nous devrions utiliser des fonctions, comme celle répertoriée ci-dessous, pour générer des chemins de fichiers et des liens :

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Un autre mauvais exemple de codage en dur est lors de l'écriture de requêtes personnalisées. Par exemple, par mesure de sécurité, nous changeons le préfixe de table de données WordPress par défaut de wp_ en quelque chose d'un peu plus unique, comme wp743_ . Nos requêtes échoueront si jamais nous déplaçons l'installation de WordPress, car les préfixes de table peuvent changer entre les environnements. Pour éviter que cela ne se produise, nous pouvons référencer les propriétés de table de la classe wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Remarquez comment je n'utilise pas la valeur wp_users pour le nom de la table, mais à la place, je laisse WordPress s'en sortir. L'utilisation de ces propriétés pour générer les noms de table aidera à garantir que nous renvoyons les résultats corrects.

Erreur courante n° 5 : ne pas empêcher l'indexation de votre site

Pourquoi ne voudrais-je pas que les moteurs de recherche indexent mon site ? L'indexation c'est bien, non ? Eh bien, lors de la création d'un site Web, vous ne voulez pas que les moteurs de recherche indexent votre site tant que vous n'avez pas fini de le créer et que vous n'avez pas établi une structure de permaliens. De plus, si vous avez un serveur intermédiaire sur lequel vous testez les mises à niveau du site, vous ne voulez pas que les moteurs de recherche comme Google indexent ces pages en double. Lorsqu'il existe plusieurs éléments de contenu indiscernables, il est difficile pour les moteurs de recherche de décider quelle version est la plus pertinente pour une requête de recherche. Les moteurs de recherche pénaliseront dans de tels cas les sites avec un contenu dupliqué, et votre site en souffrira dans les classements de recherche.

Comme indiqué ci-dessous, les paramètres de lecture de WordPress ont une case à cocher qui se lit « Décourager les moteurs de recherche d'indexer ce site », bien qu'il y ait une note importante en dessous indiquant que « Il appartient aux moteurs de recherche d'honorer cette demande ».

Gardez à l'esprit que les moteurs de recherche n'honorent souvent pas cette demande. Par conséquent, si vous souhaitez empêcher de manière fiable les moteurs de recherche d'indexer votre site, modifiez votre fichier .htaccess et insérez la ligne suivante :

 Header set X-Robots-Tag "noindex, nofollow"

Erreur courante n° 6 : ne pas vérifier si un plugin est actif

Pourquoi devrais-je vérifier si une fonction de plugin existe si mon plugin est toujours activé ? Bien sûr, 99% du temps, votre plugin sera actif. Cependant, qu'en est-il de ce 1 % du temps où, pour une raison quelconque, il a été désactivé ? Si et quand cela se produit, votre site Web affichera probablement de vilaines erreurs PHP. Pour éviter cela, nous pouvons vérifier si le plugin est actif avant d'appeler ses fonctions. Si la fonction du plugin est appelée via le front-end, nous devons inclure la bibliothèque plugin.php afin d'appeler la fonction is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Cette technique est généralement assez fiable. Cependant, il peut y avoir des cas où l'auteur a changé le nom du répertoire principal du plugin. Une méthode plus robuste consisterait à vérifier l'existence d'une classe dans le plugin :

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

Les auteurs sont moins susceptibles de changer le nom de la classe d'un plugin, donc je recommanderais généralement d'utiliser cette méthode.

Erreur courante n° 7 : Charger trop de ressources

Pourquoi devrions-nous être sélectifs dans le chargement des ressources de plug-in pour les pages ? Il n'y a aucune raison valable de charger des styles et des scripts pour un plugin si ce plugin n'est pas utilisé sur la page vers laquelle l'utilisateur a navigué. En ne chargeant les fichiers de plug-in que lorsque cela est nécessaire, nous pouvons réduire le temps de chargement de notre page, ce qui se traduira par une meilleure expérience de l'utilisateur final. Prenons, par exemple, un site WooCommerce, où nous souhaitons uniquement que le plugin soit chargé sur nos pages d'achat. Dans un tel cas, nous pouvons supprimer de manière sélective tous les fichiers du chargement sur toutes les autres pages du site pour réduire les ballonnements. Nous pouvons ajouter le code suivant au fichier functions.php du thème ou du plugin :

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Les scripts peuvent être supprimés avec la fonction wp_dequeue_script($handle) via le handle avec lequel ils ont été enregistrés. De même, wp_dequeue_style($handle) empêchera le chargement des feuilles de style. Cependant, si cela est trop difficile à mettre en œuvre pour vous, vous pouvez installer l'organisateur de plugins qui offre la possibilité de charger des plugins de manière sélective en fonction de certains critères, tels qu'un type de publication ou un nom de page. C'est une bonne idée de désactiver tous les plugins de mise en cache, comme W3Cache, que vous avez peut-être activés pour vous empêcher d'avoir à actualiser constamment le cache pour refléter les modifications que vous avez apportées.

Erreur courante n° 8 : conserver la barre d'administration

Ne puis-je pas simplement laisser la barre d'administration WordPress visible pour tout le monde ? Eh bien, oui, vous pouvez autoriser vos utilisateurs à accéder aux pages d'administration. Cependant, ces pages ne s'intègrent très souvent pas visuellement au thème choisi et ne fournissent pas une intégration transparente. Si vous voulez que votre site ait l'air professionnel, vous devez désactiver la barre d'administration et fournir votre propre page de gestion de compte :

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Le code ci-dessus, une fois copié dans le fichier functions.php de votre thème, affichera uniquement la barre d'administration pour les administrateurs du site. Vous pouvez ajouter n'importe quel rôle ou capacité d'utilisateur WordPress dans la fonction current_user_can($capability) pour empêcher les utilisateurs de voir la barre d'administration.

Erreur courante n° 9 : ne pas utiliser le filtre GetText

Je peux utiliser CSS ou JavaScript pour changer l'étiquette d'un bouton, qu'est-ce qui ne va pas avec ça ? Eh bien, oui, vous pouvez. Cependant, vous ajoutez du code superflu et du temps supplémentaire pour afficher le bouton, alors que vous pouvez utiliser à la place l'un des filtres les plus pratiques de WordPress, appelé gettext . En conjonction avec le textdomain d'un plugin, un identifiant unique qui garantit que WordPress peut distinguer toutes les traductions chargées, nous pouvons utiliser le filtre gettext pour modifier le texte avant que la page ne soit rendue. Si vous recherchez le code source de la fonction load_plugin_textdomain($domain) , cela vous donnera le nom de domaine dont nous avons besoin pour remplacer le texte en question. Tout plugin réputé s'assurera que le textdomain d'un plugin est défini lors de l'initialisation du plugin. Si c'est du texte dans un thème que vous souhaitez modifier, recherchez la ligne de code load_theme_textdomain($domain) . En utilisant à nouveau WooCommerce comme exemple, nous pouvons modifier le texte qui apparaît pour l'en-tête "Produits associés". Insérez le code suivant dans le fichier functions.php de votre thème :

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Ce crochet de filtre est appliqué au texte traduit par les fonctions d'internationalisation __() et _e() , tant que le textdomain est défini via les fonctions susmentionnées.

 _e( 'Related Products', 'woocommerce' );

Recherchez ces fonctions d'internationalisation dans vos plugins pour voir quelles autres chaînes vous pouvez personnaliser.

Erreur courante n°10 : conserver les permaliens par défaut

Par défaut, WordPress utilise une chaîne de requête avec l'ID de la publication pour renvoyer le contenu spécifié. Cependant, ce n'est pas convivial et les utilisateurs peuvent supprimer des parties pertinentes de l'URL lors de la copie. Plus important encore, ces permaliens par défaut n'utilisent pas une structure conviviale pour les moteurs de recherche. L'activation de ce que nous appelons les "jolis" permaliens garantira que nos URL contiennent des mots-clés pertinents du titre du message pour améliorer les performances dans les classements des moteurs de recherche. Il peut être assez ardu de devoir modifier rétrospectivement vos permaliens, surtout si votre site fonctionne depuis longtemps et que vous avez des centaines de messages déjà indexés par les moteurs de recherche. Ainsi, après avoir installé WordPress, assurez-vous de modifier rapidement la structure de vos permaliens en quelque chose d'un peu plus convivial pour les moteurs de recherche qu'un simple identifiant de publication. J'utilise généralement le nom de publication pour la majorité des sites que je crée, mais vous pouvez personnaliser le permalien au format de votre choix en utilisant les balises de structure de permalien disponibles.

Conclusion

Cet article n'est en aucun cas une liste exhaustive des erreurs commises par les développeurs WordPress. S'il y a une chose que vous devriez retenir de cet article, c'est que vous ne devriez jamais prendre de raccourcis (et c'est vrai dans n'importe quelle plateforme de développement, pas seulement dans WordPress !). Le temps gagné maintenant grâce à de mauvaises pratiques de programmation reviendra vous hanter plus tard. N'hésitez pas à partager avec nous certaines erreurs que vous avez commises dans le passé - et plus important encore, les leçons apprises - en laissant un commentaire ci-dessous.