Leçons apprises en sortant de la zone de confort de WordPress

C'était à la fin de l'été 2018. J'étais un développeur vieillissant qui n'était plus tout à fait sûr de ma place dans le monde WordPress. J'avais passé plus d'une décennie à apprendre les tenants et les aboutissants de la plate-forme qui a lancé ma carrière et qui a également servi de passe-temps pour d'autres projets pour animaux de compagnie que je voulais aborder.

En partie, je m'ennuyais. J'avais besoin d'un nouveau défi.

J'adore WordPress. Plus que cela, j'apprécie ce que WordPress m'a permis d'accomplir au fil des ans. Cependant, je n'en étais plus satisfait pour mon blog personnel. Il convenait au travail, mais j'ai souvent constaté qu'il contenait beaucoup plus de gadgets et de gadgets que ce dont j'avais besoin. J'écrivais également des articles de blog dans Markdown depuis de nombreuses années plutôt que dans l'éditeur classique. WordPress ne faisait tout simplement plus partie de mon flux de travail pour mon blog. Parfois, c'était un obstacle.

Défi accepté.

Au cours d'un week-end, j'ai construit un système de blog personnalisé fonctionnel. J'hésite à l'appeler un système de gestion de contenu (CMS) car il lui manquait des fonctionnalités cruciales, telles qu'une interface administrative, qui sont au cœur de tout CMS. Néanmoins, j'ai construit un système fonctionnel à partir de zéro en deux jours.

Je n'avais aucune idée que je pouvais accomplir un tel exploit sans compter sur les fonctions et outils utiles que WordPress avait si généreusement fournis pendant la majeure partie de ma carrière de programmeur. Je ne peux pas compter le nombre de fois que j'ai accidentellement tapé esc_attr() ou esc_html() uniquement pour me souvenir qu'il s'agissait de fonctions WordPress. Ma mémoire musculaire WordPress était forte. Sans le savoir, tout ce que j'avais appris en construisant sur WordPress m'a poussé à devenir un développeur PHP plus complet. Il y a peu d'API avec lesquelles je n'avais pas travaillé depuis le cœur de WordPress. J'ai compris une grande partie du code source et connaissais les raisons d'une grande partie de la crasse héritée.

Mon projet personnel pâlit par rapport à la puissance de WordPress et le fait encore à ce jour. Cependant, cela m'a fait sortir de ma zone de confort. Cela m'a permis d'explorer de vieilles idées de manière nouvelle.

Un exemple consistait à comprendre comment les règles de réécriture et le routage fonctionnaient. Certains de mes amis et moi avons récemment plaisanté en disant que personne ne comprend vraiment l'API WordPress Rewrite. Vous venez de le bricoler jusqu'à ce que quelque chose fonctionne et que le nouveau code ne casse plus votre site. Il existe de nombreuses bibliothèques existantes, mais je voulais comprendre comment cela fonctionnait pour ma propre édification. Par conséquent, j'ai décidé de créer une requête HTTP, un routeur et une classe de contrôleur. Le résultat final était une solution élégante, qui empruntait beaucoup à d'autres frameworks PHP.

Avec une simple ligne de code, comme indiqué ci-dessous pour configurer un type de contenu "livre", je pourrais gérer les demandes entrantes pour une page de livre, la mapper à la bonne ressource et générer le modèle sur le front-end. J'ai commencé à me demander pourquoi j'avais évité ce concept de site Web fondamental pendant tant d'années en tant que développeur.

 // Create 'example.com/books/book-name'. $this->router->get( 'books/{name}', Controller::class );

Il y avait beaucoup d'autres domaines où j'ai commencé à remettre en question la «façon WordPress» de faire les choses. Au cours de ce voyage de découverte, j'ai pu apprendre des choses que je pourrais rapporter pour les utiliser dans mes projets WordPress. En entrant dans le monde plus large du développement de sites Web, j'ai pu mieux voir les défauts de la plate-forme qui m'ont aidé à tomber amoureux de la programmation. Cependant, j'ai également pu mieux voir la beauté du système que des milliers de développeurs ont continué à faire fonctionner pendant les 15 années précédentes.

Ce n'est pas qu'une question de code

J'ai eu l'opportunité d'étudier et d'apprendre de grands frameworks comme Laravel et Symfony. Cependant, j'ai également étudié le fonctionnement d'autres plates-formes du point de vue de l'expérience utilisateur pure.

La seule chose que je savais avec certitude, c'est que je voulais tester des plates-formes créées pour les personnes qui écrivaient dans Markdown. Je ne cherchais pas d'énormes plateformes pour concurrencer la puissance de WordPress, comme Joomla ou Drupal. Au lieu de cela, je cherchais des solutions plus légères comme Grav, Jekyll et Hugo. Je voulais comprendre comment l'expérience utilisateur s'intégrait à mon flux de travail.

De toutes les solutions que j'ai testées, chacune avait ses avantages. Chacun avait aussi des caractéristiques ou des méthodes de faire des choses qui n'étaient pas à mon goût. La bonne chose à propos de l'expérience était que j'ai pu identifier comment je voulais que ma plateforme de blogs fonctionne pour moi. La lecture des pensées d'autres membres de ces communautés m'a également permis d'entendre des utilisateurs extérieurs à la communauté WordPress expliquer pourquoi ils aimaient leur système de blogging préféré.

J'ai avancé. En utilisant ce que j'ai appris de ces plates-formes, j'ai construit quelque chose que j'étais heureux d'utiliser. Ce n'était pas parfait et ne le serait probablement jamais. La marge de croissance n'est pas une mauvaise chose.

Pendant ce temps, j'ai ravivé mon amour des blogs avec WordPress. Bien que ce ne soit pas toujours l'opinion populaire, l'éditeur de blocs se sentait mieux que l'éditeur classique. C'était quelque chose que je me voyais utiliser régulièrement. En plus de mon blog personnel, j'ai commencé à l'utiliser sur d'autres projets. J'écris toujours en Markdown tous les jours. Cependant, je me retrouve à aimer écrire dans l'éditeur de WordPress pour la première fois depuis des années.

Pourquoi devriez-vous essayer de nouvelles plateformes

Du point de vue du développeur, ce n'est pas une bonne idée de devenir complaisant et de s'appuyer sur un seul système. Au lieu de vous appeler un "développeur WordPress", pensez au-delà de cette terminologie. Au lieu de cela, vous devriez être un programmeur PHP ou un programmeur JavaScript. Ou, mieux encore, appelez-vous simplement un programmeur. Les programmeurs résolvent des problèmes. Les outils ou langages sont ce que vous utilisez pour aller du point A au point B.

Sur le marché du travail, être un programmeur plus complet ouvre plus d'opportunités. Alors que la plupart d'entre nous ne pouvons qu'espérer que WordPress sera la plate-forme leader pour les 10, 20 ou 50 prochaines années, vous devez être prêt pour tout avenir.

Un autre avantage de travailler avec d'autres plates-formes de temps en temps est que vous apprenez des idées que vous pouvez ramener dans l'écosystème WordPress. Par exemple, il est intéressant de voir comment le thème de démarrage Sage implémente le moteur de template de Laravel Blade. Ces idées peuvent aider à façonner l'avenir de WordPress.

Certaines idées peuvent être poussées dans le noyau de WordPress. D'autres peuvent améliorer les workflows d'équipe au sein des agences.

La formation continue profite à la communauté WordPress dans son ensemble. Ne limitez pas cette éducation aux idées spécifiques à WordPress. Apprenez de l'extérieur et ramenez-le.