Programmer dans WordPress

Il est possible de créer un site WordPress sans toucher à la programmation. Plusieurs personnes gagnent leur vie de cette façon. Mais si vous êtes programmeur, vous pourrez aller beaucoup plus loin dans les fonctionnalités de votre site.

Avant de débuter la programmation, voici quelques éléments qui vous aideront à vous lancer.

• À quel endroit le code doit-il être ajouté ?
• API WordPress
• Normes de programmation
• Mode débogage
• Quelques fonctions utiles
• Les bonnes pratiques

À quel endroit le code doit-il être ajouté ?

Pour personnaliser votre site WordPress, vous pouvez ajouter du code à différents endroits :

• dans le fichier functions.php de votre thème enfant
• dans un fichier modèle de votre thème enfant
• dans une extension que vous coderez entièrement
• etc.

API WordPress

Rappelez-vous qu'il ne faut jamais modifier les fichiers de l'API WordPress :

• Fichiers à la racine du site Web (à l'exception de wp-config.php qui contiendra vos configurations)
• Fichiers dans le dossier wp-admin
• Fichiers dans le dossier wp-includes

Si vous modifiez un fichier de l'API WordPress, vos modifications seront perdues dès que vous mettrez WordPress à jour. Et comme l'utilisation d'une version non à jour vous expose à des failles de sécurité, vous devrez tôt ou tard effectuer les mises à jour, et donc écraser vos modifications.

Normes de programmation

Tout développeur WordPress devrait commencer par prendre connaissance des normes de programmation WordPress. Ces normes sont clairement documentées dans le Codex WordPress.

Il existe également des normes de documentation du code, également documentées dans le Codex WordPress.

Avant de poursuivre, prenez le temps de lire les documents suivants :

• Normes de programmation WordPress PHP : https://make.wordpress.org/core/handbook/best-practices/coding-standards/php/.
• Normes de documentation du code : https://make.wordpress.org/core/handbook/best-practices/inline-documentation-standards/php/.

Ajoutez la page des normes de programmation dans vos favoris... vous y référerez souvent pendant le développement de votre site WordPress.

Mode débogage

Pendant le développement d'un thème ou d'une extension, le mode débogage pourra vous faire sauver un temps précieux.

Lorsque vous installez WordPress, le mode débogage est désactivé. Vous pouvez vérifier ce fait dans le fichier wp-config.php :

Activer et configurer le mode débogage

Sans le mode débogage, vous ne verrez pas les avertissements de WordPress. Vous ne serez pas non plus avertis si vous utilisez une fonction obsolète (deprecated). Comme ces informations sont importantes pour tout développeur, vous devez remplacer la ligne define( 'WP_DEBUG', false ); par les lignes suivantes :

Consulter le fichier debug.log

Lorsque vous développez une fonctionnalité dans un thème ou dans une extension, il peut arriver que le navigateur affiche une page blanche, une page indiquant que la page ne fonctionne pas. Il peut également arriver que les résultats attendus ne soient pas au rendez-vous.

Prenez l'habitude de consulter régulièrement le fichier debug.log. Si vous avez bien configuré votre fichier wp-config.php pour le débogage, vous y retrouverez tous les message d'avertissement et les messages d'erreurs qui auraient normalement été affichés à l'écran.

Par défaut, le fichier de log s'ouvrira avec le bloc notes. Le problème avec ce logiciel, c'est qu'il ne permet pas de rafraîchir le contenu d'un fichier une fois qu'il a été ouvert. Vous seriez continuellement obligés de fermer puis de réouvrir votre fichier de log.

Vous devriez ouvrir le fichier de log à l'aide de Notepad++.

Avec Notepad++, vous pourrez garder le fichier de log ouvert tout au long de votre travail de débogage. En effet, lorsque Notepad++ prendra le focus et réaliser a que le fichier a été modifié, il vous demandera si vous désirez le recharger. Génial !

Prenez également l'habitude de vider le fichier de log régulièrement afin de retrouver plus facilement l'information qui vient d'y être ajoutée.

Enregistrer nos propres messages dans debug.log

Plutôt que d'utiliser les fameux echo pour afficher les valeurs de nos variables à l'écran, il est possible de créer une fonction qui enregistrera les informations désirées dans le fichier debug.log. Ceci ne fonctionnera que si WP_DEBUG est à true donc aucun affichage ne sera réalisé quand on n'est plus en débogage.

Voici donc le code de cette fonction¹. Si cette fonction est définie comme une méthode de la classe d'une extension, elle pourra s'appeler simplement log_debug. Par contre, si elle est définie directement dans un fichier de fonctions du thème, comme functions.php, il faudra ajouter un préfixe devant son nom pour assurer qu'il soit unique ( ex : function monprefixe_log_debug() ).

Supprimer le fichier debug.log avant de procéder à une mise en ligne

Le fichier debug.log est placé à la racine de votre site. Aussi, il est important de vider son contenu ou encore de détruire ce fichier avant de procéder à la mise en ligne sans quoi son contenu pourrait donner des indices précieux aux utilisateurs malveillants.

Afficher nos messages de débogage à l'écran sans risque de les oublier une fois le site en production

Le travail avec un fichier de log peut parfois être fastidieux. Ce fichier se remplit vite lors du débogage et il faut prendre soin de le vider régulièrement. C'est pourquoi certains programmeurs préfèrent afficher les informations de débogage à l'écran.

Si vous avez déjà travaillé avec PHP sans utiliser WordPress, il y a fort à parier que vous avez déjà codé une fonction qui permet d'afficher un message de débogage. Il ne vous restera plus qu'à l'adapter pour WordPress.

Voici ce à quoi votre fonction, codée dans functions.php, pourrait ressembler :

Débogage avec votre éditeur

Avant même de songer à afficher un message dans un fichier de log ou à l'écran, vous devriez installer et configurer un éditeur qui contient un débogueur, comme PhpStorm ou CodeLobster, et y créer un projet pour votre site WordPress. Vous aurez ainsi accès à toutes les fonctionnalités de débogage d'un tel outil : points d'arrêt, exécution pas à pas, consultation de la valeur des variables, etc.

Extensions pour aider au débogage

Il existe de nombreuses extensions qui facilitent la vie des développeurs WordPress. En voici quelques unes, à vous de les explorer !

• Debug bar : http://wordpress.org/plugins/debug-bar/
• BlackBox Debug Bar :http://wordpress.org/plugins/blackbox-debug-bar/
• WordPress Console :http://wordpress.org/plugins/wordpress-console/
• Debug Translations :http://wordpress.org/plugins/debugging-translation/
• WordPress Hook Sniffer :http://wordpress.org/plugins/wordpress-hook-sniffer/

Quelques fonctions utiles

Langage PHP

Pour développer un thème ou une extension WordPress, vous devez coder en PHP. Ce langage met à votre disposition une foule de fonctionnalités pour :

• poser des conditions, faire des boucles ( ex : if, while, for, foreach )
• effectuer des opérations (ex : comparaison ( == ), assignation ( = ), concaténation ( . ), addition ( + ) )
• envoyer du texte au navigateur ( ex : echo )
• manipuler les chaînes de caractères ( ex : substr(), str_replace(), md5(), addslashes(), explode() )
• manipuler des dates ( ex : getdate(), dateformat() )
• manipuler des tableaux ( ex : array(), count(), sort() )
• manipuler les URL ( ex : parse_url(), urlencode() )
• etc.

Fonctions spécifiques à WordPress

Vous aurez en plus accès aux fonctions spécifiques à WordPress, dont voici un petit échantillon.

• get_bloginfo() et bloginfo() : informations générales sur le site Web. La première permet de manipuler ces informations alors que la seconde les affiche directement dans le navigateur.Ex :
  PHP

  <?php

     $blog_title = get_bloginfo( 'name' );

  ?>

  PHP

  <h1><?php bloginfo( 'name' ); ?></h1>

• get_site_url() et site_url() : retrouver ou afficher l'URL du site Web, tel que codé dans le panneau de configuration sous « Adresse Web de WordPress ».Ex :
  PHP

  $url = get_site_url();

• admin_url() : retrouver l'URL de la page d'administration du site Web. L'URL se termine par une barre oblique.
  WordPress (PHP)

  Ex : $adminUrl = admin_url();   // Ex : http://mondomaine.com/wp-admin/

  Note : il existe également la fonction get_admin_url(). Mais contrairement au modèle retrouvé dans les autres fonctions, la différence entre admin_url() et get_admin_url() ne se situe pas au niveau de l'affichage. get_admin_url() est conçue pour être utilisée dans le contexte d'une installation WordPress multisites. Elle reçoit comme premier paramètre l'id du site pour lequel on désire retrouver l'URL de la page d'administration.

• Constante ABSPATH : retrouver le dossier racine du site Web. Attention : il s'agit d'un chemin et non d'un URL.
  WordPress (PHP)

  Ex : require_once( ABSPATH . 'wp-admin/includes/image.php' ); 

• get_the_title() et the_title() : retrouver ou afficher le titre d'un article ou d'une page.Ex :
  PHP

  $parent_title = get_the_title( $post->post_parent );

• get_the_content() et the_content() : retrouver ou afficher le contenu d'un article ou d'une page.Ex :
  PHP

  $content = get_the_content('Read more');

• is_page() : vérifier s'il s'agit de l'affichage d'une page complète (par rapport à une liste d'articles ou à un article complet).Ex :
  PHP

  if ( is_page() ) {

     ...   // traitement spécifique pour les pages

  }

• is_single() : vérifier s'il s'agit de l'affichage d'un article complet (par rapport à une liste d'articles ou à une page).Ex :
  PHP

  if ( is_single() ) {

     ...   // traitement spécifique pour les articles

  }

• Autres fonctions pour vérifier l'état de ce qui sera affiché (marqueurs conditionnels ou conditional tags)

Retrouver la documentation officielle d'une fonction WordPress spécifique

Le Codex WordPress regorge d'informations. Cette qualité peut devenir un défaut lorsqu'on cherche une information très précise. Voici donc un petit truc qui pourrait vous sauver de précieuses minutes.

L'URL de la documentation d'une fonction WordPress prendra presque toujours la forme suivante :

http://codex.wordpress.org/Function_Reference/nom_de_la_fonction

Vous pouvez donc simplement entrer le nom de la fonction recherchée, sans les parenthèses, pour atteindre directement sa page de documentation.

Ex :

Les bonnes pratiques

Lors du développement d'un thème ou d'une extension WordPress, il faut être au fait des bonnes pratiques pour tirer profit de tous les avantages WordPress.

Se conformer aux bonnes pratiques permettra également d'être accepté dans la communauté WordPress.

Voici quelques bonnes pratiques à mettre en application :

• Toujours se placer en mode débogage pendant le développement. Enlever le mode débogage seulement lorsque le développement et les tests sont complétés.
• Si vous développez une extension, son code devrait être placé dans une classe afin d'éviter les conflits de noms de variables ou de fonctions.
• Rendez votre travail prêt pour la traduction en utilisant les fonctions __() et _e().
• Documentez le mode d'emploi de l'extension dans un fichier README.TXT.
• Respectez les normes de programmation WordPress.
• Respectez les normes de documentation du code.
• Ne codez jamais en dur le nom du dossier du thème ou de l'extension. Utilisez plutôt la fonction une des fonctions suivantes :
  • plugin_dir_path() pour le dossier d'une extension. Attention : c'est le chemin du dossier sur le serveur. Ce n'est pas un URL.
  • get_template_directory() pour le dossier du thème ou, si vous utilisez un thème enfant, pour retrouver le dossier de son thème parent. Ici encore, ce n'est pas un URL.
  • get_stylesheet_directory() pour le dossier du thème et ce, même s'il s'agit d'un thème enfant.On obtiendra un chemin et non un URL.
  • plugins_url() pour retrouver l'URL du dossier des extensions
  • get_template_directory_uri() pour l'URL du thème ou, si vous utilisez un thème enfant, pour retrouver l'URL de son thème parent.
  • get_stylesheet_directory_uri() pourl'URL du thème et ce, même s'il s'agit d'un thème enfant.
• Pour accéder aux données, utilisez toujours l'objet $wpdb.
• Dans la mesure du possible, utilisez les « hooks » pour ajouter ou enlever du code dans un fichier existant.

Sources

1. « Ten Things Every WordPress Plugin Developer Should Know ». Cmashing magazine. http://wp.smashingmagazine.com/2011/03/08/ten-things-every-wordpress-plugin-developer-should-know/

Pour plus d'information

« fr:Fonctions de référence ». Codex WordPress. http://codex.wordpress.org/fr:Fonctions_de_r%C3%A9f%C3%A9rence

« Référence des fonctions ». PHP Manual. http://www.php.net/manual/fr/funcref.php

« Beginning WordPress Development: A Look at Common Functions ». Six Revisions. http://sixrevisions.com/wordpress/beginning-wordpress-development-a-look-at-common-functions/

« Formatting PHP Strings with printf and sprintf ». Elated. http://www.elated.com/articles/formatting-php-strings-printf-sprintf/

« Déboguer sous WordPress ». Pixenjoy. http://kattagami.com/pixenjoy/deboguer-sous-wordpress/

« Déboguer sous WordPress ». Pixenjoy. http://kattagami.com/pixenjoy/deboguer-sous-wordpress/

« Writing a Plugin ». Codex WordPress. http://codex.wordpress.org/Writing_a_Plugin

« WordPress Coding Standards ». Codex WordPress. http://codex.wordpress.org/WordPress_Coding_Standards

« Inline Documentation ». Codex WordPress. http://codex.wordpress.org/Inline_Documentation

« Ten Things Every WordPress Plugin Developer Should Know ». Cmashing magazine. http://wp.smashingmagazine.com/2011/03/08/ten-things-every-wordpress-plugin-developer-should-know/

« Plugin API ». Codex WordPress. http://codex.wordpress.org/User:Guigui/fr:Plugin_API

« Bien développer un plugin pour WordPress ». z720.net. http://z720.net/blog/archives/2006/03/28/bien-developper-un-plugin-pour-wordpress

« Créer une extension WordPress : Les premières étapes ». Blog d'un développeur WordPress. http://blog.nicolas-juen.fr/2011/08/23/creer-une-extension-wordpress-les-premieres-etapes/

« Determining Plugin and Content Directories ». Codex WordPress. http://codex.wordpress.org/Determining_Plugin_and_Content_Directories

« Création d’un plugin ». L'Arbre à Hélices. http://www.arbre-helices.com/cours/installation-dun-plugin/