Mes projets, mes dépendances, mes emmerdes…

Pour certains une seule réponse, pas besoin d’en faire une chanson, composer et une version de PHP décente pour commencer à travailler et arrête de nous casser les pieds WordPress.

Si on écoutait les @rarst et autres dév en pointe on passerait sur composer et là roulez jeunesse… la gestion des dépendances est automatisée, autoload, chaque composant en packages, basta bonne journée. Personnellement je pense que WordPress doit passer ce cap avec tous les risques que cela peut comporter, sink or swim buddy.

Dans l’intervalle, on a quand même des moyens de s’organiser.

Je suis aussi pour un nivellement par le haut, ce n’est pas la philosophie de WordPress qui veut ses barrières à l’entrée quasi inexistantes. Les lead dévs font leurs choix et comme je dis souvent plus facile de bouger un radeau qu’un paquebot. Donc en attendant une modernisation, qui semble avoir été enclenchée d’ailleurs, creusons le sujet avec ce qu’on a.

Une dépendance ?

Dans un projet WordPress, on a déjà pas 3 grandes dépendances :

  • les plugins
  • les thèmes
  • le core

Et dans ce cas dès le moment où je vais commencer à mettre du ACF (advanced custom fields), du Gravity Forms, un framework, un thème starter, ma propre base de code, je suis parti pour un grand tour. D’autant qu’avec ACF entre les versions 3, 4 et 5 on a pas mal de différences, impossible de faire la transition sans dév AMHA.

Bon là on parle d’un plugin en particulier bien identifié, donc sur des petits projets ça se gère, avec ce qu’il faut de maintenance etc. Sur des moyens voire gros projets la liste des dépendances fait des bonds, c’est Fibonacci, quelques semaines d’évolutions et elles font des petites qui elles-mêmes se reproduisent. Cela grouille dans tous les sens.

Que faire ?

Choisir.

Comment être sûr ?

On peut pas. On produit le meilleur code possible sur une période t, ne pas oublier le temps, toujours plus facile de juger un code a posteriori. T’arrives sur un code qui date de 4 ans et tu dis “hen pas bien” mais peut-être que c’était bien à l’époque, ça a juste un peu vieillit mais ça tient. Bon après comme la vie est nuancée ça peut aussi être naze depuis le début hun smile

Aucun soft n’est développé ex-nihilo, on pourrait parler des créations de l’esprit, est-ce qu’on peut produire quelque chose de manière totalement isolée ? Mais on va éviter d’abuser de la philosophie. C’est bon pour le moral mais faut agir à moment donné.

Cascade de dépendances

Certains auteurs de plugins comme @scribu l’ont bien compris et ils construisent leurs outils open source dans ce sens : soyez API smile Tout dépend de l’ambition du projet mais si votre plugin a vocation à être un framework voire une application connectée à WordPress comme peut l’être JetPack par exemple, construisez vos codes en prenant en compte que vous créerez peut-être votre propre bulle dans la bulle WordPress.

Ainsi votre base de code devient core, c’est ce que l’on peut dire de BuddyPress aussi, plugins simili-core. Là où ça devient très très pointu c’est quand on va vouloir sortir un projet open source avec à la fois une bonne UX et une bonne DUX ( ~ user & developer friendly ). Difficile de contenter tout le monde. FAITES UN CHOIX.

Je ne dis pas qu’il est impossible mais difficile de contenter tout le monde. Dans tous les cas il faut des utilisateurs, qu’ils soient directs ou indirects par l’intermédiaire des développeurs. Les malmener ou les brusquer c’est faire un contresens, c’est pour ça que je peux comprendre qu’on passe pas du jour au lendemain sur une nouvelle techno avec une base utilisateurs comme celle de WordPress, il faut “péreniser le changement” comme on dit là-bas.

Bons choix / mauvais choix

Tiens je vais en sortir une :

La différence entre un bon et un mauvais développeur: le mauvais développeur, il voit une nouvelle techno il l’utilise, le bon développeur il voit une nouvelle techno il l’utilise mais c’est un bon développeur.
Notre métier c’est faire marcher des trucs et ce truc de la rétrocompatibilMaité qui nous frustre quand on veut commencer à utiliser des features pratiques mais qui sont WordPress core 4.2+++ c’est peut-être aussi le signe pour nous qu’il faudrait dans l’absolu créer des codes non dépendants d’une version de WordPress, ne pas rajouter de la dépendance à la dépendance. Héhé introspection…

Le problème c’est le temps. Or l’intérêt de WordPress c’est avant tout la vitesse des projets, et c’est pas cher etc. Et puis y a la GPL qui nous contraint même si c’est bien aussi. La vie c’est dur.

Y a des truc pas bien quand même

C’est pas parce que certains blocages s’expliquent que tout est bien :

  • les incompatibilités de plugins, de librairies
  • les features qui déchirent mais qu’on voit jamais arriver
  • les grands principes qu’on oublie quand ça nous arrange ( à quoi ça sert d’en avoir j’ai envie de dire )
  • les évolutions bloquées

La vérité

Y en a pas. Le dév s’organise pour mettre en place les fonctionnalités, il fait ses choix et s’il y a des dépendances, à lui de les gérer et on pourra juger de son code (outre la revue de code classique) sur la durée.

La solution intermédiaire adoptée par beaucoup de pros c’est d’avoir des dépendances vers des plugins pseudo-core, des gros du marché, genre ACF, JetPack et tabler sur une relative stabilité.

Tout ça pour dire quoi finalement

Au final je dirais que les débats du type “ça va dans le thème, ça va dans un plugin” sont non avenus même si j’ai mon avis sur la question, je suis partisan des plugins pour la fonctionalité et du thème pour l’apparence, beaucoup de plugins donc, parce que WordPress est construit comme ça. Y en a d’autres qui rétorquent que c’est trop compliqué pour les utilisateurs finaux, que mettre les custom post types dans le thème oui c’est pas forcément top mais qu’actuellement rien ou très peu est prévu dans WordPress pour bunlder des plugins et des thèmes facilement. Ils n’ont pas tort.

Ma position c’est d’essayer de glisser le maximum de bonnes pratiques à la mesure de ce que je sais et d’essayer de me mettre à la place de l’utilisateur final pour qui je fais tout ça finalement. Après je peux aussi en discuter avec les collègues. Donc n’hésitez pas à parler de vos techniques on pourra vous dire “bonne méthode on va s’en inspirer” ou “non faut pas faire comme ça” mais au moins vous avancerez.

Allez je saute le pas.

Ma méthode (freelance)

  • tout ce qui concerne l’apparence dans le thème
  • les scripts et styles liés à l’apparence dans le thème
  • découpage en includes ou require dans le functions.php
  • un plugin par fonctionalité
  • généraliser le plus possible dans des classes en mu-plugins par exemple pour déclarer les CPTs, les Taxos
  • les filtres et les actions plutôt que les utilisations directes dans les templates et si pas le choix un function_exists() ou un class_exists() au minimum

La dependance aux plugins me gêne beaucoup moins que celle au thème. Et vous ?