Les nouveaux thèmes élaborés WordPress nous font oublier la fonction primaire du template : ce n’est qu’un cadre. Notre procédure de création de thème tient compte de ce fait. Nous allons ici décrire cette procédure, puis ensuite, évoquer le problème des thèmes évolués.

Notre procédure en matière de création de thèmes :

  1. Nous partons d’un thème « minimal », réalisé dans les règles de l’art Wordpress. C’est pour nous la garantie d’avoir un thème propre, optimisé, sans superflux, avec un fichier fonctions vide et un css presque vide.
  2. Nous utilisons le framework CSS Bootstrap. Nous pensons que ce framework offre les objets de base des pages HTML et nous le maîtrisons bien, et vite.
  3. Nous créons pour chaque site un thème-enfant qui accueillera les modifications du thème de base.
  4. Nous agissons principalement sur le fichier CSS pour personnaliser le site. Nous élaborons ce CSS avec une application d’édition de feuille de style.
  5. Nous agissons aussi sur le fichier functions.php pour régler certains paramètres du thème. Pour cela, nous avons à notre disposition une « banque de snapcodes » qui nous permet de faire la plupart de ces modifications rapidement par simple copier-coller.
  6. Nous n’utilisons le fichier functions que pour les action à entreprendre sur le thème. Pour les autres besoins en code du site, nous créons un plug-in.
  7. Nous avons à notre disposition de nombreux fichiers Home, Headers et Footer différents (« banque de bouts de templates »), et quand nous en créons un nouveau, nous le conservons. Cela nous permet de réutiliser du code quand c’est nécessaire, sans avoir à repartir de zéro.
  8. Quand nous voulons créer une page complexe, nous utilisons une application d’édition Bootstrap et nous copions le HTML dans une page, un article ou dans le thème.
  9. Nous possédons une « banque d’objets Bootstrap » ainsi qu’une « banque d’objets jquery »qui nous permet d’avoir à disposition des objets de toutes sortes qui peuvent êtres utilisés dans le thème .
  10. Pour les pages d’accueil évoluées, de type Landing page, qui ont besoin d’être souvent mises à jour, nous pouvons utiliser un plug-in de création de page.

Cette procédure nous permet de réaliser toutes sortes de thèmes différents, en garantissant une structure de base légère au thème, éliminer le superflu, sécuriser le thème, tout en ayant une grande latitude dans le design, sans être dépendant des outils d’un thème particulier. Il nous est aisé, par exemple, de récupérer un objet Bootstrap et/ou Jquery pour l’intégrer à un thème.

Nous avons mis un certain temps pour mettre en place cette procédure, car il a fallu créer le thème de base et réunir les « banques » de code et trouver nous même nos outils. Mais à présent, la procédure nous permet de réaliser nos thèmes vite et bien,  tout en « capitalisant » à chaque fois que l’on crée quelque chose de nouveau.

Nous n’utilisons plus la procédure dite du « thème évolué », qui consistait à utiliser des thèmes entièrement paramétrables en ligne. Nous allons expliquer la raison de cette décision.

A quoi sert un thème WordPress ?

A question simple, réponse simple : Selon nous, à définir le design graphique général du site. Et c’est tout.

On a vu apparaître ces dernières années de très nombreux template WordPress, via des sites éco-système tel que Theme Forest. On a vu en même temps apparaître une multitude de thèmes de plus en plus complexes, possédant leurs propre framework, permettant de créer des pages de plus en plus impressionnantes, et offrant des fonctionnalités inexistantes dans un wordpress de base. Nous sommes sorti de l’objectif initial du thème, qui est d’offrir un design général au site. Le thème devient un élément central du fonctionnement du site.

Nous avons été séduit au début par ce déluge de possibilités qu’offraient la communauté de développeurs en créant des thèmes toujours plus élaborés. Nous avons appris beaucoup de ces thèmes, en étudiant leurs codes sources, en constatant leur efficacité, en les utilisant sur divers projets. Nous avons vu à quel point WordPress était plus qu’un système de blog, plus qu’un CMS, plus qu’un framework, mais réellement, un serveur d’applications.

Mais cette évolution du thème WordPress nous a aussi fait découvrir ses limites, que nous allons aborder.

La dépendance d’un site au thème évolué :

Beaucoup de thème WordPress évolués retirent une des fonction clé de WordPress : La possibilité de renouveler le design de son site sans avoir à tout refaire. Quand le design d’un site est daté, et même si on pratique des évolutions progressive dans le design, la question de la refonte totale du thème se fait. Le problème avec les thèmes évolués, c’est la dépendance du site au thème. Le thème non seulement s’occupe de l’aspect général du site, mais aussi de la façon dont fonctionne certains plug-in, ils s’occupent de la façon dont sont stockées les données, il s’occupe de la façon dont on administre le site. Avec certain thème, la dépendance est totale. Changer de thème revient à tout reconstruire.

Le sabotage de la structure MVC par les thèmes évolués :

Notre politique de bonnes pratiques exige un respect de la norme MVC (Model-View-Controller). Même si WordPress n’est pas à proprement parler un système MVC, il s’en rapproche fortement ; Son système de base de données est le modèle, son système d’administration, framework, plug-in est le contrôleur, quant au système de thème, avec les widgets, c’est le système de vue. Les thèmes évolués chamboulent complètement cet ordre. Ils collectent de nouvelles données, prenant le rôle du modèle, ils modifient la façon dont on administre le site, jouant le rôle de contrôleur,  ils interviennent fortement sur le fonctionnement général du site, dépassant leur rôle initial d’assurer un aspect général au site.

Au delà de la question de principe (le respect de la norme MVC), cette façon de faire entraîne la dépendance au site, que nous avons déjà évoqué, mais aussi, rend le site plus complexe à personnaliser.

Complexité de l’évolutivité du site :

Modifier un thème évolué peut devenir très compliqué. Quand la structure MVC est respectée, le développeur identifie rapidement la provenance des problèmes et sait où regarder. Avec un thème évolué, il devient parfois très compliqué de savoir d’où vient un problème, car le Modèle, la Vue et le Contrôleur se mélangent au sein du thème.

Ces thèmes évolués possèdent aussi souvent leur propre framework. Une évolution demande donc d’apprendre le fonctionnement de ce framework, entrainant ainsi une élévation du temps de réalisation.

Après avoir identifié que le problème venait du thème, il faut alors décortiquer ce thème, voir comment il a été construit, et régler les problèmes de fiabilité du thème. En effet, si certain thèmes évolué sont soigneusement programmé, beaucoup de thème n’offrent aucune garantie quand à leur fonctionnement.

Le problème avec les systèmes d’options et les shortcodes.

La plupart de ces thèmes évolués sont livrés avec un système d’options et un système de shortcode.

Le système d’option permet de paramétrer le site, par exemple les fonts ou les couleurs, mais ajoute en même temps de la complexité au code et du temps de traitement pour le serveur, qui doit à chaque fois faire des requêtes pour connaître les paramètres enregistrés. Quand il s’agit de personnaliser l’aspect du site, au lieu de se concentrer sur le fichier CSS, LESS ou SASS, il faut aussi tenir compte des paramètres enregistrés en système. Le système d’option a tout son intérêt pour qui souhaite personnaliser un peu un site sans rien connaître au code, mais pour quelqu’un qui connait le css, cela ne procure aucun gain de temps (modifier un CSS avec un éditeur de style est aussi rapide), ajoute de la complexité, et alourdi le système. Tout en rendant le site encore plus dépendant à son thème.

Quand aux shortcodes de présentation, à l’intérieur des articles et des pages, dont ces thèmes usent et abusent, il alourdissent encore le traitement par le serveur, qui doit repérer les shortcode et les traduire avant des les afficher. Ils compliquent la compréhension du code pour celui qui veut personnaliser le site (il faut parfois réapprendre une nouvelle syntaxe qui n’est qu’une couche au dessus d’une autre syntaxe.). Par exemple, il nous parait plus adéquate d’utiliser la syntaxe des tag Bootstrap directement, plutôt que de passer par un shortcode, qui ne fera que traduire Bootstrap dans un autre langage pour ensuite être retraduit en Bootstrap lors de l’exécution du site.

Les shortcode liés au thème gènent aussi l’évolutivité du site, le rendant encore plus dépendant du thème.

Le problème de la fiabilité des thèmes évolués :

Les thèmes que l’on peut acheter sur internet sont développé par toutes sortes de personnes, du programmeur du dimanche à la grosse start-up en passant par des freelances. Nous ne connaissons pas la qualité de leur code tant que l’on n’a pas acheté leur thème. On peut tester des versions démos avant d’acheter, vérifier le poid des pages et la qualité du html, mais on n’a pas accès au code source tant qu’on n’a pas le thème en main.

L’expérience nous a montré que la plupart des thèmes du marché avaient de sérieux problèmes de qualité de code. Tailles des images inadaptées à l’affichage, modules de contact faisant appel à des scripts peu sûrs, bonnes pratique W3 ignorées, etc.

Souvent, les démos nous présentent des sites impressionnants, mais souvent aussi, dès que l’on cherche à adapter le thème à son projet, on se retrouve face à des problèmes de manque de souplesse.

Pour un développeur ou une société, il est extrêmement compliqué de pouvoir garantir ce type de thème et d’estimer le temps qu’il faut consacrer pour l’adapter.

Bien sélectionner son thème :

Comme nous l’avons évoqué, les thèmes élaborés, qui paraissent pratiques et adéquates dans un concept RAD (Rapid Application Developement) sont souvent source de complications.  S’ils peuvent permettre d’aller vite au tout début du projet, l’adaptation est souvent chronophage. Désorganisation de la structure du site, problèmes d’évolutivité, problèmes de fiabilité. Tout celà entraine une difficulté pour garantir la qualité du site, une augmentation du temps d’apprentissage du thème, une augmentation du temps d’adaptation et de débuggage.

Le paradoxe est que souvent, nous utilisions ce type de thème pour accélérer la réalisation des sites qu’on nous confiait, alors que systématiquement ou presque, nous nous retrouvions face à des problème imprévus que nous découvrions en utilisant le thème, et qui gâchaient complètement les gains de productivités initiaux.

Un peu de nuance :

Notre critique des thèmes évolués peut paraître radicale, aussi allons nous un peu nuancer nos propos ici. Nous ne sommes pas non plus des adeptes du « partir de zéro » pour créer des thèmes, nous aimons les outils qui accélèrent le développement, nous utilisons parfois des short-code, et nous achetons même des thèmes évolués qui nous plaisent rien que pour voir comment ils sont faits.

Il existe aussi des thèmes évolués très bien réalisés, sécurisés, optimisés et bien pensés, qui une fois bien maîtrisés, servent de base à la réalisation de tous les sites de certaines agences web. Nous avons longuement étudié la possibilité de nous servir de thèmes tels que Divi ou Genesis pour tous nos projets, et nous n’excluons pas complètement la solution du thème évolué dans le future, si cela nous permet de créer avec souplesse et productivité des sites performants.

Pour le moment, nous avons choisi une solution qui nous permet à la fois de faire ce que l’on veut, de le faire rapidement, et de pouvoir le garantir.