Présentation technique WP21
(ma.tt)- Cela fait 21 ans que WordPress a publié sa première version après que Matt Mullenweg et Mike Little ont forké b2/cafélog, et le développement à venir doit retrouver les conditions qui ont permis ce succès initial
- L’orientation produit s’aligne sur le principe selon lequel les choses simples doivent être intuitives, tout en rendant aussi les choses complexes possibles
- Les fonctionnalités web dynamiques comme les blogs, les commentaires et les pingbacks rendent les sites plus intéressants, et davantage de valeur est accordée aux sites dynamiques qu’aux sites statiques
- L’écosystème des plugins et des thèmes doit disposer d’une infrastructure de développement au niveau du cœur de WordPress, et en 2024 il n’est pas approprié de dépendre de l’upload de ZIP
- Des boucles de feedback proches des utilisateurs, des forums centrés sur la communauté, de bons aperçus de thèmes et Playground façonneront l’expérience WordPress à venir
Les 21 ans de WordPress et les principes produit
- Cela fait 21 ans que WordPress a publié sa première version après que Matt Mullenweg et Mike Little ont forké le travail de Michel sur b2/cafélog
- Il faut continuer à garder à l’esprit, dans les développements à venir, les éléments qui ont contribué au succès initial de WordPress
- Le principe central du produit est que ce qui est simple doit être facile et intuitif, tout en permettant aussi de faire des choses complexes
Blog, documentation et fonctions communautaires
- Les blogs, les commentaires et les pingbacks doivent être amusants
- Les sites statiques ont leur place, mais les sites dynamiques sont préférables
- Presque tous les sites peuvent être améliorés avec un excellent blog
- La documentation doit pouvoir être éditée aussi facilement qu’un wiki
- Les wikis sont considérés comme des outils « formidables »
- Dans la communauté, les forums doivent être au centre
- bbPress et BuddyPress ont besoin de davantage d’attention
L’écosystème des plugins et des thèmes
- Tous les plugins et thèmes doivent disposer d’une infrastructure de développement du niveau de celle utilisée pour construire WordPress lui-même
- gestion de versions
- suivi des bugs
- forums
- documentation
- internationalisation
- salons de discussion
- P2
- un chemin simple vers la contribution et la communauté
- En 2024, il n’est pas approprié de gérer plugins et thèmes via l’upload de ZIP
- Les aperçus de thèmes doivent être excellents
- Une collection de thèmes non commerciaux aux esthétiques et fonctionnalités variées est importante
Boucles de feedback et transparence plutôt que règles
- Il ne faut pas trop se focaliser sur les directives et les exigences
- Il vaut mieux concevoir de bonnes dynamiques de marketplace, des boucles de feedback automatisées et de la transparence vis-à-vis des utilisateurs
- La frontière entre fonctionnalité et design doit être repoussée davantage
- Une tolérance zéro est nécessaire face au spam et aux comportements assimilables au spam
- Les boucles de feedback doivent s’adapter à l’usage et à l’ensemble de la communauté, plutôt que de dépendre de gatekeepers
Le caractère du cœur et le contact avec les utilisateurs
- Le cœur de WordPress doit être affirmé et singulier
- Easter egg
- un langage plein de personnalité, même s’il est difficile à traduire
- un caractère proche du jazz
- Toutes les personnes qui développent le logiciel et prennent des décisions doivent l’utiliser
- Les développeurs et décideurs doivent rester proches des utilisateurs finaux ordinaires via le support, les meetups, les événements et toute activité possible
Playground et l’expérience initiale
- Playground est attendu comme un changement majeur
- Le 27 mai 2003, jour de la première version de WordPress, Matt Mullenweg a écrit depuis le porche de la maison de ses parents un billet de blog de 953 mots dans lequel figurait la phrase : « J’ai publié WordPress, et je me sentais bien. »
- Ce soir-là, il a configuré WP pour son ami Ramie Speight et assuré une assistance technique par téléphone à Mike Tremoulet, rencontré lors d’une réunion locale de blogueurs
- Ses amis de lycée utilisaient WordPress chacun sur leur propre domaine, et cette boucle de feedback a joué un grand rôle dans la manière dont le logiciel s’est façonné
1 commentaires
Avis de Hacker News
C’est dommage : WordPress semble non seulement ne pas respecter les standards de développement, mais même chercher activement à les casser
Après avoir utilisé des variables globales partout et encouragé le code spaghetti avec les thèmes classiques, les nouveaux thèmes demandent de mettre du JSON dans des commentaires HTML, ce qui prive de support éditeur, rend les erreurs faciles et donne tout simplement une conception étrange
On se demande sérieusement si des ingénieurs seniors ont vraiment décidé de mettre des templates JSON dans des commentaires HTML ; vu sous un angle complotiste, cela peut même donner l’impression de vouloir tuer le marché des freelances et des agences digitales pour pousser tout le monde vers le site builder WYSIWYG de WP.com
C’est du genre HTML dans du PHP dans du JS dans du CSS, avec une structure implicite qui détermine quels fichiers sont lus, et dans quel ordre, pour construire une page entière
Au début, cela paraît pratique, mais on finit par ne pas fermer correctement les éléments HTML dans le même fichier et par les terminer dans un autre, ce qui empêche aussi leur réutilisation
Cela ressemble à une erreur de débutant, mais comme des milliers de thèmes en dépendent, tout le monde est désormais coincé avec ça, surtout par contraste avec la manière dont les templates Jinja2 rendent des blocs et des macros
WordPress existe pour les clients sans budget et les clients à bas coût qui s’imaginent avoir besoin d’un simple site web ; et même l’idée de ce genre de site simple me semble déjà morte
https://timber.github.io/docs/v2/
Dès qu’on essayait de déplacer l’installation vers un nouveau serveur avec un chemin d’installation un peu différent, tout cassait
Malheureusement, cela pourrait nuire au message marketing selon lequel « notre plateforme fait tourner 43,4 % de tous les sites web »
C’est dommage que les jugements rapides et les opinions tranchées soient devenus une partie de la communauté
Après avoir beaucoup développé sur WordPress ces 2 ou 3 derniers mois, je dirais que l’isolation du code offerte par les blocs (Gutenberg) est excellente
Utilisés comme plugin indépendant, ou avec Advanced Custom Fields, ils permettent de construire un site web et un workflow de développement entièrement modulaires, autrement dit un design system, avec un contrôle direct à 100 % jusqu’au HTML
Je recommande à tout le monde de vraiment comprendre et apprendre WordPress. Je n’ai aucun lien ni aucune affiliation avec WordPress
Aujourd’hui, d’un coup, Gutenberg et ACF Blocks entrent en conflit quelque part autour du parsing du contenu de champs médias imbriqués
La cause pourrait être « l’utilisateur a ajouté une description d’image qu’il n’aurait pas dû ajouter », ou bien « l’objet global du plugin a pollué un autre objet global passé à
acf_register_block_type()»Je vais peut-être devoir appeler un client déjà furieux pour lui dire d’éviter les jugements rapides et les opinions tranchées
Ce n’est peut-être plus le cas aujourd’hui, mais le scepticisme est compréhensible. Dans les mises à jour que je consulte chaque semaine, je vois pas mal de CVE, même si elles concernent peut-être toutes des risques faibles ou des plugins très peu utilisés
index.phpde WordPress pour essayer de comprendre comment ça fonctionnaitJe me souviens de n’avoir rien compris, à part le commentaire « code is poetry » en haut du fichier
Cela a changé ma façon de penser le code et m’a encore davantage attiré vers la programmation
Si un article a besoin de métadonnées, on installe ACF ; si l’on veut filtrer sur ces métadonnées, les requêtes SQL expirent dès que quelques filtres s’appliquent en même temps. Il suffit de regarder le schéma étrange de WP pour comprendre pourquoi
Gutenberg promet des composants React éditables en WYSIWYG, mais prend des décisions étranges : stocker les attributs dans le HTML, mettre le HTML rendu en base de données et obliger les développeurs de composants à maintenir un tableau de changements dépréciés à chaque modification
Il existe aussi des tentatives de refactorer WordPress et de lui adjoindre Laravel pour s’en sortir[1], mais chaque couche est un cauchemar, et même les auteurs des différentes parties semblent avoir du mal à déterminer pourquoi certaines choses cassent au hasard
L’écosystème de plugins peut être séduisant, mais les implémentations des plugins sont tellement disparates qu’on risque fort d’envoyer aux utilisateurs d’énormes paquets de CSS et de JS boursouflés
Je suis passé à Directus et Astro, et pour un déploiement PHP plus classique, j’utiliserais probablement un CMS basé sur Laravel comme October ou Statamic
[1]: https://roots.io/
Je l’ai pas mal utilisé en 2009–2011, y compris pour écrire et modifier des plugins, mais je n’ai jamais eu l’impression de vraiment le comprendre ; je le comprenais ou l’acceptais seulement dans les grandes lignes
J’aime WordPress. Les gens l’installent eux-mêmes, ajoutent des dizaines d’extensions inutiles, peu sûres et pleines de bugs, puis quand le site se dégrade avec le temps, on peut leur facturer une solution plus sûre et plus solide.
Ça donnait l’impression d’un projet de week-end jamais terminé qui avait fini par être publié après avoir trop traîné, avec des boucles
forlongues comme cinq écrans qui tournaient autour d’une énorme variable globale, dupliquées pour traiter des choses.WordPress est mon exemple préféré de « pas besoin que ce soit parfait, il faut juste que ça marche ».
Beaucoup de beaux projets meurent parce qu’ils rendent la première étape trop compliquée. Une fois que les gens commencent à l’utiliser, on peut toujours améliorer plus tard, mais il faut d’abord sortir quelque chose.
C’est si grave que même les développeurs du langage PHP ne peuvent pas implémenter certaines fonctionnalités ou corrections, parce que l’équipe WordPress ne veut pas migrer le code et que WordPress représente une grosse part de l’usage de PHP.
WP est l’outil parfait pour 95 % du travail, mais ajuster les 5 % restants est incroyablement frustrant.
Je l’ai beaucoup utilisé, et le fait qu’il ait survécu aussi longtemps est à mes yeux une preuve de son utilité. J’espère qu’il durera encore 21 ans.
Honnêtement, je n’ai jamais trouvé WordPress facile à utiliser. Tout paraît rose tant qu’on peut trouver un bon thème et de bonnes extensions, mais dès qu’il faut une toute petite modification personnalisée, les ennuis commencent.
Mais une fois le site, le code des extensions/thèmes et les fichiers CSS ouverts, je passais des heures à me battre pour obtenir l’effet voulu, et même quand j’y parvenais, je cassais souvent d’autres parties du site.
Anecdote dépréciative mise à part, bravo à Matt, et la dernière histoire était bien aussi.
Les mises à jour nécessitent une intervention manuelle, les thèmes doivent être réparés, les extensions sont abandonnées. Comme je ne voulais pas accepter cette charge, j’ai migré tous mes sites vers Hugo/Jekyll/MkDocs et autres vers 2017.
Pour un blog, je préférerais utiliser Ghost plutôt que WP, et je préfère aussi JS à PHP.
Il est intéressant de voir que lorsque plusieurs personnes disent « je suis développeur WordPress », cela désigne en réalité des expériences et des ensembles de compétences totalement différents.
Pour certains, cela veut dire installer des thèmes et des extensions dans l’interface d’administration WordPress et rédiger le contenu des pages.
Pour d’autres, cela renvoie au vieux code PHP consistant à écrire du HTML avec des templates PHP et à personnaliser le comportement de WordPress, c’est-à-dire les thèmes classiques.
Pour d’autres encore, cela signifie écrire du JS+React avec Docker et CI/CD pour de nouveaux thèmes blocs.
J’aimerais que davantage d’entreprises adoptent la politique de congé sabbatique d’Automattic.
https://automattic.com/benefits/sabbatical/
Ce qui me donne l’impression d’avoir vieilli, c’est de voir « WP » et de penser non pas à WordPress mais à WordPerfect(https://en.wikipedia.org/wiki/WordPerfect).
WordPress a désormais l’âge d’être considéré comme adulte même dans les pays les plus conservateurs, et WordPerfect entre maintenant dans l’âge de la crise de la quarantaine.
Ce qui est frappant avec WordPress, c’est que les nerds du web s’attendent à ce que ce soit évidemment facile, puis s’énervent quand ce n’est pas le cas.
Comme tout le reste, WordPress s’apprend, et il a sa propre perspective.
Il a aussi une histoire étrange, et je n’aime vraiment pas sa manière de gérer les éléments média, mais il y a tout de même une méthodologie.
Si je disais que je connais Go, JS, Perl, Java, Ruby et C, puis que je m’énervais parce que Rust est difficile à apprendre, on me contredirait évidemment.
WordPress semble faire des choses simples, mais c’est en réalité une plateforme assez vaste. Il faudra peut-être lire un peu la documentation.
Si vous héritez d’un site qui utilise Elementor, demander à la personne qui l’a créé comment faire des modifications simples peut aider.
Si vous héritez d’un site qui utilise Visual Composer ou Divi, vous aurez envie de fusiller ceux qui l’ont créé.
Si vous pensez que Gutenberg est mauvais, ce n’est plus du tout le cas aujourd’hui. Quand on se souvient de l’époque de Divi, c’était vraiment terrible.
Sur cette horrible UI JavaScript posée sur WordPress, le moindre timeout peut, rien qu’en enregistrant un article de blog, mettre tout le site web dans un état irrécupérable.
Les localisations italienne et française sont aussi mauvaises que celles des jeux japonais des années 90, et les options responsive ne fonctionnent pratiquement pas, sauf si l’on appelle « responsive » le fait de masquer et d’afficher du contenu à certains breakpoints.
Le « thème » frontend ressemble davantage à un dump illisible de JavaScript de l’époque jQuery, ce qui rend tout extrêmement fragile.
Je suis sûr à 100 % que personne ne l’utiliserait si Elegant Themes ne dépensait pas énormément d’argent en publicité.