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.

▼Publicité

À 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 :

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 :

fichier wp-config.php

define( 'WP_DEBUG',  false );

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 :

fichier wp-config.php

// Active le mode débogage

define( 'WP_DEBUG',  true );

 

// Pendant le débogage, lorsqu'une erreur est rencontrée, n'affiche pas de message d'erreur.

// Plutôt, WordPress enverra un codes d'état HTTP 500 au navigateur.

define( 'WP_DEBUG_DISPLAY', false );

 

// Pendant le débogage, WordPress enregistrera les messages d'erreurs dans le fichier www\monsite\wp-content\debug.log.

define( 'WP_DEBUG_LOG', true );

 

// En production (lorsque WP_DEBUG est à false), n'affiche pas les erreurs à l'écran.

@ini_set( 'display_errors', '0' );

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 !

Notepad++ : This file has been modified by another program. Do you want to reload it?

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 fonction1. 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() ).

PHP

/**

 * Enregistre une information de débogage dans le fichier debug.log, seulement si WP_DEBUG est à true

 *

 * Utilisation : monprefixe_log_debug( 'test' );

 * Inspiré de http://wp.smashingmagazine.com/2011/03/08/ten-things-every-wordpress-plugin-developer-should-know/

 *

 * @author Christiane Lagacé

 *

 */

function monprefixe_log_debug( $message ) {

    if ( WP_DEBUG === true ) {

        if ( is_array( $message ) || is_object( $message ) ) {

            error_log( 'Message de débogage: ' . print_r( $message, true ) );

        } else {

            error_log( 'Message de débogage: ' . $message );

        }

    }

}

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 :

WordPress (PHP)

/**

 * Affiche une information de débogage à l'écran, seulement si WP_DEBUG est à true

 *

 * Utilisation : monprefixe_echo_debug( 'test' );

 * Suppositions critiques : le style .debug doit définir l'apparence du texte

 *

 * @author Christiane Lagacé

 *

 */

function monprefixe_echo_debug( $message ) {

    if ( WP_DEBUG === true ) {

        if ( ! empty( $message ) ) {

            echo '<span class="debug">';

            if ( is_array( $message ) || is_object( $message ) ) {

                echo '<pre>';

                print_r( $message ) ;

                echo '</pre>';

            } else {

                echo  $message ;

            }

            echo '</span>';

        }

    }

}

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 !

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 :

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 :

PHP

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

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/

Merci de partager ! Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInPin on PinterestShare on StumbleUponEmail this to someone
Catégories

2 commentaires

  1. Bonjour,

    Très bien votre ‘papier sur’ la programmation et le debogage.
    J’utilise WP depuis 2 semaines, pour migrer un site Google/Blogger.

    J’ai cherché une bonne semaine avant d’arriver à faire ‘tourner’ du php et du mySQL directement dans WP.

    Ce que j’ai retenu c’est que:
    – La formulation ne marche pas dans le WP ‘out of the box’ de base que l’on mette le code en ‘direct’ ou via un include. Je n’ai pas testé la page dédiée car le thème que j’utilise (Magazine-basic) ne le permet pas et je ne vois pas très bien quelle serait la différence par apport à un include.
    – La seule solution que j’ai trouvé c’est d’utiliser un plugin, dans mon cas Insert_PHP.
    – La solution de debogage que vous donnez n’est indiquée quasiment nulle part, mais il est vrai que ‘les pépites il faut les chercher pour les trouver’.

    Donc:
    – Merci pour votre série d’articles, je sens que je vais y revenir souvent.
    – Et une question: comment accède t’on a ‘debug.log’.

    Marc.

    • Christiane Lagacé

      Bonjour Marc,

      Qu’entendez-vous par WordPress Out of the box ? Et qu’entendez-vous par page dédiée ?

      De façon native, PHP et MySQL tournent directement dans WordPress. En fait, c’est plutôt l’inverse : WordPress et bâti à l’aide de PHP et d’une BD MySQL. Comme dans tout programme, vous pouvez créer vos propres requêtes SQL. Il est également possible d’ajouter vos propres tables dans la BD créée par WordPress.

      Le problème, c’est que si vous désirez effectuer ces tâches à l’aide de l’interface graphique de WordPress, vous serez grandement limité. L’idéal est d’y aller par programmation. J’ai écrit un article qui montre comment effectuer une requête MySQL sous WordPress : http://christianelagace.com/wordpress/effectuer-une-requete-a-laide-de-wpdb/ et un autre qui montre comment ajouter vos propres tables : http://christianelagace.com/wordpress/ajouter-des-tables-personnalisees-dans-un-theme-ou-une-extension-wordpress-avec-dbdelta/.

      Vous devrez coder vos fonctionnalités dans le fichier functions.php de votre thème ou plutôt du thème enfant que vous développerez. Je vous conseille grandement d’utiliser un thème enfant pour faciliter les mises à jour de votre thème (vos ajouts directement dans le thème parent seraient écrasés lors d’une mise à jour). Cet article devrait vous éclairer sur la façon de créer un thème enfant : http://christianelagace.com/wordpress/developper-un-theme-enfant/. Et celui-ci vous aidera à comprendre la structure d’un site WordPress : http://christianelagace.com/wordpress/de-quoi-est-compose-un-theme-wordpress/.

      Finalement, pour répondre à votre dernière question, le fichier debug.log sera créé dans le dossier wp-content de votre site. Il n’existe pas à la base et il ne doit en aucun cas être présent sur un serveur de production car il peut ouvrir d’importantes failles de sécurité. Donc, dans votre environnement de développement, lorsque vous mettrez la variable de débogage à TRUE et que PHP rencontrera un problème, il créera automatiquement le fichier debug.log. Vous pourrez l’ouvrir à l’aide d’un éditeur de votre choix. Personnellement, j’utilise NotePad++.

      Bonne chance dans votre exploration de WordPress !

      Christiane