WordPress, plugins et thèmes, comment ça s’organise ?

A force de voir des gens chercher un plugin pour faire une chose extrêmement simple, ou ne pas savoir comment modifier leur thème,

à force d’entendre des âneries comme “il ne faut pas plus de cinq plugins“,

à force de voir des thèmes qui incluent des fonctionnalités qui devraient être dans des plugins…

voici un petit guide de la chasse aux idées fausses et aux mauvaises pratiques.

(Je préviens : cet article est rempli de “vocabulaire” compliqué, mais les notions derrière sont simples. Vocabulaire qu’il faut comprendre si on veut maîtriser un minimum son blog).

WordPress : un “core” qu’on peut étendre à volonté

Ce qu’on appelle le “core” de WordPress, c’est ce qui est installé par défaut, sans les plugins et les thèmes de base. Ce noyau dur comprend l’ensemble des fonctions nécessaires au fonctionnement du site, et toutes les fonctions qu’on peut utiliser pour créer des fonctionnalités supplémentaires.

Le noyau dur est volontairement léger et simple. C’est un choix de base des développeurs de WordPress de mettre à disposition quelque chose de très modulaire, d’extensible, mais de ne pas “tout” activer par défaut.

Par exemple, à une époque, dans les anciennes versions, il y avait un élément de menu “liens”, qui a disparu parce qu’il était de moins en moins utilisé, la “blogroll” perdant beaucoup d’importance. Mais les fonctions pour l’utiliser sont toujours là, et il suffit de mettre en place un petit plugin pour le voir réapparaître.

De la même façon, WordPress inclut ce qu’on appelle des “bibliothèques javascript” (encore un autre langage) qui permettent de faire beaucoup de choses : quand vous voyez dans un formulaire un champ pour sélectionner une date avec un petit calendrier qui s’affiche, c’est une bibliothèque javascript qui permet cet affichage du calendrier. Mais toutes les bibliothèques ne sont pas activées par défaut dans l’installation de base, parce que cela alourdirait inutilement le site.

Le core de WordPress comprend :

• l’admin, donc tout ce qui est nécessaire pour gérer les différents contenus, les catégories, les utilisateurs, les options
• et les fonctions nécessaires pour les traiter et les afficher.

Pour les curieux, c’est classé, d’une part dans wp-admin et d’autre part dans wp-includes

Par contre, ces deux dossiers n’ont pas de thème.

Les thèmes permettent d’afficher les données

Avant d’étendre les fonctionnalités, il faut pouvoir afficher ce que l’on a enregistré dans l’admin.

Cela se fait par l’intermédiaire de thèmes.

Comme le core de WordPress, un thème est un ensemble de fichiers .php, avec éventuellement du javascript (.js) mais ces fichiers ont pour objectif de traiter les données qui sont dans la base, et de les afficher, en tenant compte des options (ce que vous paramétrez dans les réglages).

WordPress est livré avec un thème par défaut, qui change souvent, et qui s’appelle twenty “quelque chose”, le quelque chose correspondant à l’année.

Ce thème se trouve dans un sous-répertoire dans le dossier wp-content/themes.

Le thème par défaut est, d’un point de vue WordPress, parfaitement codé (et heureusement !), par contre, d’un point de vue SEO, c’est souvent une catastrophe, car WordPress propose des thèmes totalement HTML5 avec de nombreuses sections et de nombreux titres H1.

En théorie, dans un monde parfait et informatiquement bien organisé, un thème ne devrait traiter que de la présentation des données. En pratique, pour des raisons de simplicité, beaucoup de thèmes ont aussi des fonctionnalités qui touchent directement aux données, et qui devraient donc être dans des plugins.

C’est le cas, notamment, de tous les thèmes qui proposent des “customs post types”, des types de contenus personnalisés, comme les portfolio, entre autres. Donc 99,9% des thèmes de ThemeForest.

Car ce qui se passe, c’est que, si on change de thème, on perd l’accès à ces données, et donc on change le contenu du site. (En pratique, les données sont toujours dans la base, mais elles sont devenues invisibles dans l’admin).

Les plugins permettent d’étendre les fonctionnalités

Un plugin est, lui aussi, un ensemble de fichiers .php, .js etc… mais sont objectif n’est pas, initialement, de présenter les données, mais de rajouter des fonctionnalités pour traiter ces données.

Certaines de ces fonctionnalités sont dans l’admin uniquement :

• un plugin comme Force Regenerate Thumbnails permet de retailler les images
• un plugin comme Gravity Forms Toolbar ajoute un élément de menu pour l’admin, pour accéder rapidement à toutes les fonctionnalités de Gravity Forms
• un plugin comme WooZone permet d’interroger le site d’Amazon et d’importer des produits dans WooCommerce pour faire facilement un site d’affiliation
• les plugins d’antispam, comme Antispam Bee (bien plus efficace qu’Akismet)

Dans la plupart des cas, les plugins vont avoir des fonctionnalités à cheval entre l’admin et le “front-end” (partie visible par le visiteur) :

• tous les plugins qui rajoutent des types de contenu, du simple témoignage à un plugin extrêmement complet comme WooCommerce
• des plugins qui permettent de créer des tables comme TablePress
• des plugins comme Widget Logic, qui permettent de paramétrer des conditions pour l’affichage des Widgets dans la sidebar
• les plugins de SEO, comme Yoast ou All In One SEO (que je préfère, je le redis à chaque fois)

Enfin, il existe des plugins qui n’affectent que l’affichage :

• les plugins destinés à TinyMCE, comme Viper Video Quicktag, qui ajoute des boutons dans l’éditeur de texte, pour insérer des shortcodes
• des plugins qui sont spécifiquement destinés à rajouter des éléments dans le front-end, comme les “related posts”, ou les plugins de partage et de mise en avant de contenu, comme AdThis, que j’utilise ici

(Je mets à part le cas des plugins de shortcodes).

Plugins et thèmes utilisent l’A.P.I. de WordPress

Une API c’est une “Application Programming Interface”, une “interface de programmation“, autrement dit un ensemble de fonctions utilisables pour interagir avec un programme.

L’API de WordPress permet donc d’utiliser les fonctionnalités de WordPress, les modifier, en rajouter, sans aller toucher à un seul moment aux fichiers du core. Elle sert d’intermédiaire, ce qui permet de sécuriser les plugins et les thèmes.

Un exemple : on peut parfaitement sélectionner les articles appartenant à une catégorie en allant faire sa requête SQL soit-même ; mais le jour où la base de données change de structure, alors la requête ne marche plus. Par contre, si on utilise la fonction de l’API prévue pour cela, la fonction sera modifiée avec le changement de version de WordPress, et la sélection fonctionnera toujours.

De plus, les fonctions de WordPress intègrent généralement des validations, pour éviter qu’un petit malin pirate trop facilement votre site.

Le nombre de plugin n’a aucune importance

Eh oui, exit la légende idiote qui dit “pas plus de cinq, pas plus de vingt plugins”, ou la remarque imbécile “je code moi-même, parce que les plugins c’est mauvais pour la performance”.

(Parce que coder soi-même, c’est simplement faire son propre plugin).

Les plugins ne sont QUE des fichiers de programme supplémentaires. Ce qui compte, c’est ce que fait le plugin, et comment il est codé.

Exemples de plugins qui n’impactent pas du tout la performance

Edit Author Slug permet juste de rajouter sur la page utilisateur l’affichage d’un champ prévu par WordPress, et qui permet de mettre dans l’url de l’auteur autre chose que l’identifiant. Il fonctionne en ajoutant une règle de réécriture dans la table wp-options, selon le mécanisme standard de WordPress, et en stockant des valeurs dans la base de données, selon l’API, à un endroit “prévu pour”, utilisé par les fonctions standard. En clair, il a un impact zéro sur la performance (mais très positif sur la sécurité).

Force Regenerate Thumbnail de la même façon, est un plugin utilisé pour redimensionner les images de la bibliothèque des médias quand on change de thème ou qu’on rajoute un plugin. Il est très proprement codé (il ne balance pas ses scripts ailleurs que sur son unique page de traitement), et son action est “à la demande”. Là encore, zéro impact sur la performance globale.

Exemples de plugins qui explosent la performance

D’une manière générale, tous les plugins qui stockent dans la base de données des statistiques de visites, des sessions, etc… ce qui n’a rien à y faire. Avec l’exception des plugins de sécurité, qui doivent stocker un certain nombre d’informations… mais dans lesquelles il faut faire régulièrement le ménage. (D’ailleurs, ne pas faire le ménage est, de toute façon, une bonne manière de tuer son blog. En particulier, pensez à vider vos spams régulièrement).

Des plugins comme Yet Another Related Posts ou Relevanssi sont aussi connus pour beaucoup demander, car ils indexent des “contenus relatifs”, et selon leur paramétrage, cela peut consommer beaucoup de ressources.

Entre les deux

Tout ce qui est, par exemple “Builder”, qui rajoute des couches inutiles…

Mieux vaut plusieurs plugins qu’un gros thème ou qu’un gros plugin.

Un thème vient avec un fichier “functions.php” qui était prévu, au début, pour des fonctionnalités simples liées à la présentation des données, comme :

• la traduction, avec le chargement du textdomain
• la gestion des tailles de vignettes, avec register_image_size
• les options classiques du thème (le header, éventuellement des couleurs)
• les sidebars

D’ailleurs, le fichier functions.php du thème par défaut “Kubrick” (qui était encore distribué avec la 2.9) ne contient que cela… sur 400 lignes quand même, car, à l’époque, l’API comportait nettement moins de fonctions.

Et puis peu à peu sont venus :

• les shortcodes pour faire des mises en page
• les custom post types, avec les portfolios et autres
• les widgets spécifiques au thèmes, qui reprennent, par exemple, les custom post types
• les panneaux d’options pour gérer son SEO dans le thèmes, les liens avec les réseaux sociaux, etc, etc…
• les bibliothèques javascript pour gérer l’affichage et les panneaux d’options

Un thème et un plugin pour les données

Avec comme conséquence directe : quand vous changez de thème, vous “perdez” au moins en partie ces éléments, il faut penser à remettre les codes analytics, changer le nom des custom post types dans la base de données, etc.

A tel point que Justin Tadlock, un des développeurs du core, lançait l’année dernière une initiative pour standardiser un certain nombre d’identifiants, pour des types de posts qui se retrouvent souvent (portfolio, etc)

Ce qui est, à mon avis, la mauvaise réponse au problème : la standardisation est quasiment impossible, si elle peut porter sur quelques éléments, comment standardiser les taxonomies, les custom fields, les options ?

La bonne réponse est de pousser à une meilleure qualité de développement, en séparant réellement les données de la présentation.

Ce que je fais toujours pour mes clients : un plugin spécifique pour les données.

Or en termes de “code” et de “fichiers chargés”, c’est exactement équivalent. La seule différence ? Au lieu d’appeler plein de fichiers de code par le biais du fichier functions.php du thème, on appelle “le même code” via le fichier du plugin.

Cela démontre bien l’absurdité de lier performance et nombre de plugins.

Alors plugin ou pas ?

Analytics et assimilés

Pour moi, a priori, pas de plugin : c’est un bout de code à inclure dans le fichier header.php

Le plugin devient utile à partir du moment où on utilise les fonctionnalités avancées, comme les groupes de contenu.

Insertion de contenu complexes dans les articles

Oui, un plugin peut-être utile pour ceux qui ne connaissent pas les fonctionnalités html de base, et / ou qui n’ont pas envie de switcher sur la fenêtre de l’éditeur de texte.

Malheureusement, la plupart des plugins, au lieu de générer du code html, génèrent des shortcodes. Ce qui est mauvais.

Regardez comment fonctionnent les boutons de base de TinyMCE : ils génèrent du code html. Ce mode de fonctionnement est reproductible pour du code complexe, comme les onglets ou autre, mais avec nettement plus de travail en amont pour le développeur…

Custom posts types, custom taxonomies

Là, je suis contre l’utilisation d’un plugin pour générer cela. Comme Custom Post Type UI.

Le code pour générer des custom post types et des customs taxonomies est simple, il suffit de recopier ce qui se trouve dans le codex. Si vous avez le besoin d’en créer pour votre site, vous êtes déjà un utilisateur avancé, prenez une grande respiration, plongez et faites votre propre plugin.

Il sera beaucoup plus simple, beaucoup moins lourd que n’importe quel plugin prévoyant “toutes les possibilités”.

Et de toutes façon, avec un plugin comme Custom Post Type UI, vous devez mettre les mains dans le cambouis pour l’affichage dans le thème ^^.

Custom Fields et Metaboxes

Le custom field, c’est le “champs personnalisé”, le “post_meta” qui permet d’ajouter des informations à un article.

La “metabox”, c’est le cadre qui permet de saisir ces informations de façon plus agréable que la boite standard. Quand vous saisissez les informations pour Yoast ou pour All In One SEO, vous êtes dans une metabox.

Bien que je préfère les faire moi-même, la programmation peut-être plus complexe que pour un type de post ou une taxonomie, surtout dès qu’on sort du standard. Donc je ne vous jetterai pas la pierre si vous utilisez Advanced Custom Fields…

 En conclusion, plugin ou pas plugin ?

Ce n’est pas le nombre qui compte, c’est la qualité. On peut très bien avoir, par exemple, une trentaine de plugin qui ne touchent qu’à l’admin (quand on a un site multi auteurs) et presque rien en front-end.

On peut très bien avoir de nombreux plugins légers, bien faits, qui utilisent les transient – un système de stockage temporaire de données – qui stockent intelligemment les champs personnalisés dans la base de données, etc… et qui n’ont pas d’impact sur la performance.

Ou avoir un espèce de gros mastodonte unique et mal foutu.

Oui, c’est mieux d’éviter les plugins pour toutes les choses qu’on peut faire directement. Et ça vaut le coup d’apprendre le HTML pour ça.

Mais le principe de base de WordPress, à la différence d’autres CMS, c’est un noyau léger et beaucoup de plugins.