Contenu principal
via Wikimedia Commons

La séparation des pouvoirs de l’État WordPress

12 Jan 2015

Il y a peu, Daniel Roch de SeoMix postait un tweet comme je les aime (parce que je suis souvent l’auteur de ce genre de message), rageant contre les développeurs qui incluent des outils de SEO dans leurs thèmes.

Bisous à toi également ;)
Le message sous-jacent est un débat de longue date traitant de mauvaises pratiques de développement : certains thèmes incluent toutes leurs fonctionnalités en leur sein. Le problème est alors que lorsque l’on change de thème, il ne reste plus rien. Il s’agit donc de séparer certaines fonctionnalités du thème, comme le précise Daniel quelques minutes plus tard :

Oui. Mais non. Enfin si, mais pas tout à fait, la ma vérité est ailleurs (mais c’est surtout parce que j’aime bien contredire les gens, même s’ils ont raison ^^ ). Je suis d’accord avec Daniel dans les grandes lignes, mais disposant ici de plus de 140 caractères, je vais pouvoir me permettre de nuancer ma pensée.

Disclaimer

Je créé des thèmes sur mesure, ma vision est différente de celle pour les thèmes gratuits ou premium. En effet, je suis dans un contexte où il y a de fortes chances pour que le thème qui remplacera le mien dans quelques années soit également fait sur mesure, il y aura donc une personne qui prendra en compte mes développements et s’adaptera. Je ne veux pas dire que j’ai alors carte blanche pour faire n’importe quoi, je dois quand même penser à la maintenabilité et l’évolutivité (car c’est bien là le sujet qui nous préoccupe), mais je peux cependant prendre certains raccourcis qui faciliteront le développement.
Je vais tenter d’aborder les deux côtés.
Nota : mon thème inclus des options SEO ;)

CPT et shortcode

Tout d’abord, les cas simples souvent pris en exemple pour défendre l’idée de « séparation des pouvoirs » : les CPT et les shortcodes.
Oui, je vais vous dire que les CPT et les shortcodes devraient se trouver dans une extension, pas dans un thème. Mais où est la limite ?

Deux metas sont dans un bateau

Les CPT s’accompagnent souvent de post metas, on en fait quoi ?

Il y a des metas de fonctionnement : dates de début et de fin pour un CPT évènement. À mon sens, ceci doit aller dans une extension, car c’est la base du fonctionnement des évènements. Il y a aussi les metas secondaires : pouvoir choisir d’afficher la galerie de photos au-dessus ou au-dessous de la description de l’évènement. On commence déjà à se poser la question si ça doit vraiment aller dans l’extension (je dirais que ça va dans le thème, d’ailleurs il s’agit là de « design » pour reprendre les propos de Daniel).

Jusque là on peut assez facilement séparer nos metas en deux groupes, du moins dans la théorie, car en pratique on se rend compte qu’il faut alors prévoir deux façons de récupérer (et mettre à jour, sanitizer, valider, etc.) ces données : une dans l’extension, une dans le thème.
De plus, dans le thème il faut s’assurer que le site ne va pas exploser si l’extension est désactivée, c’est donc parti pour une brouette de function_exists(), class_exists(), method_exists(), defined() et prévoir des fallbacks. C’est tout un processus mental qui n’a pas lieu lorsque tout est regroupé dans le thème.
On peut pousser la réflexion en ajoutant des filtres et actions. Par exemple, les évènements sont habituellement listés par date, mais dans mon thème ils doivent être classés par titre, on se retrouve donc à filtrer sa propre extension depuis son propre thème, ou l’inverse. D’ailleurs, a t-on vraiment besoin de prévoir un comportement par défaut que l’on modifiera ensuite depuis le thème (développement sur mesure) ?

Get cape. Wear cape. Fly.

Les shortcodes. Là aussi, il y a sens à mettre les shortcodes dans une extension, puisque sans eux, nos contenus deviennent un amas de [column] [yolo] [zora_la_rousse] (poke page builder).
Oui, mais. Souvent, ces shortcodes ont besoin de CSS (+ images) et JavaScript spécifiques : shortcode créant des colonnes (CSS), shortcode créant des onglets (CSS + JS). Il faut donc créer ces fichiers de ressources et prévoir les fonctions qui vont les « enqueue », et qui… ne serviront pas, puisque le thème utilisera ses propres règles CSS, sa propre image de sprite, et mettre le JavaScript nécessaire dans son fichier .js principal. Là on est en développement spécifique, on ne peut pas livrer un thème qui ajoute 20 fichiers CSS/JavaScript par page. Pour les thèmes gratuits/premium, il reste la solution d’une extension de cache (tiens, ça ferait un joli backlink ça) qui va concaténer les styles/scripts.

En pratique

Il y a un autre problème que nous n’avons pas encore abordé. Imaginons, je créé mon extension d’évènements comme il faut, avec tout ce qu’il faut dedans. La personne peut changer de thème, ses évènements seront toujours là.

Que se passe t-il alors ?
J’aurais bien sûr prévu des templates de base dans l’extension, mais il ne seront pas adaptés au nouveau thème. Sérieux ? Vous croyez vraiment qu’un développeur sain d’esprit va s’amuser à créer deux jeux de templates (un dans le thème et un dans l’extension) ? Mythooooooooo !
Verdict : il faut refaire les templates, et ça, c’est vrai en développement spécifique ou pas.

Thème gratuit/premium :
Ha mais c’est simple, il n’y a qu’à choisir un nouveau thème qui inclus des évènements ! Quand tout à coup « Mais où sont mes évènements ? ». Bah oui, mon CPT était sf-event mais le nouveau est baw-event. D’OH! Bon ok, la personne installe une extension capable de changer le type de contenu d’un post. Super, ça marche. « Mais pourquoi la date n’est pas bonne ? Où est passée l’adresse ? ». Ha ouais, je t’ai pas dis ? J’ai appelé mes metas sf_event_start_date, sf_event_end_date, sf_event_city, etc. D’OH!
D’autres sont conscients de ce problème et proposent de « normaliser » tout cela avec des conventions communes.

Conclusion

En voyant tout ça, on se rend vite compte que :

  1. en voulant respecter cette séparation à la lettre il y a le double de travail,
  2. aucune solution n’est parfaite,
  3. même en créant des extensions, le prochain thème ne sera pas compatible, à moins de rester chez le même fournisseur,
  4. la séparation thème/extension l’emporte tout de même, il y aura moins de travail à faire lors d’un changement de thème.

Pour les thèmes gratuits/premium il n’y a cependant pas trop le choix, pour moi il faudrait bien séparer extension et thème car on ne contrôle pas l’environnement dans lequel le site évolue, ou va évoluer.

Si on fait du thème sur mesure on peut prendre des raccourcis et mettre l’essentiel de la mécanique dans des extensions, le reste sera gardé dans le thème, sous peine de transformer notre développement en usine à gaz, on perdrait alors le bénéfice du développement sur mesure. Le développeur qui passera après moi viendra piocher dans les fichiers du thème au besoin. Le code étant alors destiné à être repris, une attention particulière sera faite au niveau des commentaires (voilà une règle que je ne respecte pas, hontable) et de la lisibilité du code.

Universel

Mais on n’a abordé qu’une partie du sujet.

Daniel aborde ici un autre problème, que j’ai à peine introduit dans la première partie. Ici on va devoir se poser plusieurs questions.

  1. Le thème (ou ses extensions) doit-il inclure une partie SEO ?
  2. Si oui, jusqu’à quel point ? Où s’arrêter ?
  3. Si oui, thème ou extension ?
  4. Qu’est-ce que « un vrai plugin SEO » ?
  5. Et le CMS dans tout ça, que fait-il ?

SEO ou pas SEO ?

Le thème ou l’une de ses extensions (on pourrait aussi dire « ma prestation ») doit-elle inclure des outils de SEO ?
Ma réponse est oui. Sans ça j’estime que le thème serait incomplet. Principalement parce que le référencement passe aussi par la sémantique html du site. J’estime que le thème doit même aller plus loin en utilisant des meta-données dans ses balises html. Tant qu’à faire, le thème doit aussi s’occuper de la balise <title> et de la meta description (ouais, j’ose, ch’uis un fou) : un site sans ces deux balises est pour moi inimaginable.

Vers l’infini…

Où s’arrêter ?
Je ne parle bien sûr pas d’une prestation de référencement complète, ce serait impossible, puisqu’une telle prestation passe par le contenu du site et une stratégie. Ça, c’est pas mon boulot, c’est celui de personnes comme Daniel.
En fait, j’ai plus ou moins répondu dans la question précédente. Le thème doit s’occuper du côté technique. Mais selon moi, il n’a pas besoin de gérer tous les aspects (techniques), il ne devrait s’occuper que de la base. Le titre et la description sont pour moi la base. Par exemple, sur une archive de catégorie, le titre doit refléter le nom de la catégorie et mettre la description de la catégorie dans la meta description. Il peut aussi prévoir une description (paramétrable) par défaut. Mais je pense que le thème doit s’arrêter là.

Ils utilisent leurs propres champs pour Title, Meta Description et autre

Si je comprends bien, le thème ajoute ici des champs spéciaux sur les pages pour pouvoir personnaliser le title et la description. C’est ici pour moi la limite à ne pas franchir en effet. Mon avis est que le thème doit donner la possibilité d’avoir un title + description par défaut, la base, mais ne devrait pas aller plus loin. C’est pourquoi je considère que ces champs personnalisés ne devraient pas être mis à disposition par le thème, car on marche ici sur les plate-bandes des extensions dédiées.

Thème ou extension ?

Thème.
J’ai parlé de sémantique et de micro-données : ceci va dans le thème.
J’ai parlé de title et description : bof, osef, c’est plus ou moins pareil mais je dirais thème, puisqu’à mon sens il n’est pas nécessaire d’envoyer ceci vers une extension. Pourquoi séparer ici ? Y aurait-il un avantage à cela ? Je n’en vois pas.
En revanche, comme je l’ai dit plus haut, le thème doit céder la place à l’extension spécialisée, dans une certaine limite.

Un vrai plugin SEO

C’est une plaie à importer dans un vrai plugin SEO…

Bah ouais, mais c’est quoi un « vrai plugin SEO » ? Qu’est-ce qui rend ton « vrai plugin SEO » plus légitime que le mien ou que mon thème ? Je suppose que ton « vrai plugin SEO » utilise des options et des post metas. Pourquoi ce sont pas les mêmes que les miennes ? C’est une vrai plaie à importer dans mon thème !

Ils utilisent leurs propres champs pour Title, Meta Description et autre.

Comme ton « vrai plugin SEO » ;) #troll

Et les Shadoks pompaient…

Et WordPress dans tout ça, il fait quoi ? Bah rien. Et c’est là le vrai problème à mon avis. Comme il ne fait rien, il n’y a rien de normalisé.
Actuellement on a quoi :

  1. Un champs « Titre du site » dans les réglages généraux : c’est la balise <title> ou le titre <h1> ?
  2. Un champs « Slogan » dans les réglages généraux : ça va à côté du titre ou dans la meta description ?
  3. Depuis WordPress 4.1 on a add_theme_support( 'title-tag' );. Ha super, c’est une très bonne idée, mais le machin ajoute le nom du site et le slogan à la fin du title de chaque page ! Résultat il faut bidouiller à mort pour virer ça, en feintant les fonctions menteuses (merci les globales).
  4. add_theme_support( 'description-meta' ); ? Ha ben non, ya pas.
  5. Uniformisation des post metas ? Non plus.

Et pour terminer là-dessus un gros lol :

Kubrick didn’t necessarily set a great example to theme authors by appending the blog name to wp_title(), a practice we have been trying to correct ever since.

OK, alors là, même si je suis d’accord sur ce point, il va falloir remettre les choses en place. Petit rappel concernant wp_title() :

Parameters
$sep
    (string) (Optional) How to separate the various items within the page title.
    Default value: '»'

$display
    (bool) (Optional) Whether to display or retrieve title.
    Default value: true

$seplocation
    (string) (Optional) Direction to display title, 'right'.
    Default value: ''

Dites, si on ne doit pas ajouter de texte à la fin de wp_title(), à quoi sert alors le paramètre $seplocation ? C’est pas justement pour ajouter un séparateur à la fin, afin d’y accoler du texte ? Kubrick est il réellement responsable de cette mauvaise pratique ?

Re-conclusion

WordPress ne propose quasiment rien de base concernant le SEO, ce qui fait que chaque développeur est libre de faire ce qu’il veut, il y aura donc toujours des galères pour migrer ces données (astuce : prévoir des extensions de migration, jdçjdr).
Pour résumer ma pensée : SEO basique paramétrable (débrayable) dans le thème (ou extension, osef), le SEO poussé est à réserver aux extensions spécialisées.

Hey, pour une fois je fais un article sans code, qui tente d’ouvrir une discussion, profitez-en ! :)