Mes cinq pires erreurs de développement WordPress

Ou, To All the Servers I've Tanked Before: Un regard rétrospectif horrifiant sur les cinq pires erreurs WordPress que j'ai commises

En tant que développeurs, nous commettons différents types d'erreurs à différents moments de notre carrière. Dans le développement WordPress, en particulier, nous commettons différents types d'erreurs au fur et à mesure que notre familiarité avec la base de code WordPress augmente.

Il y a quelques années, j'ai entendu Matt Mullenweg déclarer que la plupart des gens répètent leurs erreurs, que les plus intelligents apprennent de leurs erreurs et que les plus intelligents d'entre nous apprennent des erreurs des autres. J'aime plutôt ça, et j'ajouterais un corollaire : tout le monde fait des erreurs, les humbles partagent ces erreurs en privé, et les plus audacieux d'entre nous les écrivent et les publient dans un blog !

Mais il est temps de réfléchir plus tard. Vous lisez cet article parce que vous voulez entendre parler d'un accident de train, et je suis l'ingénieur. Sans plus de préambule, rejoignez-moi dans un regard horrifié sur les cinq erreurs les plus embarrassantes que j'ai commises en tant que développeur WordPress.

La fois où j'ai mis à jour une version piratée de WordPress Core

Je venais juste de terminer mes études de codage CraigsList très obscures pour travailler dans une véritable agence en direct. j'étais arrivé ! J'étais nerveux de travailler ailleurs que sur mon canapé, dans autre chose que mon pyjama. Mais même alors, je connaissais généralement WordPress depuis WordPress Doing It Wrong, et j'ai trouvé agréablement auto-agrandissant de se vanter des meilleures pratiques de WordPress, comme de ne jamais "pirater le noyau".

Ma première tâche de développement WordPress dans cette agence a été de reprendre un projet au point mort, plutôt complexe pour mes compétences à l'époque. Cela impliquait de nombreuses personnalisations du flux d'enregistrement et de connexion de WordPress. Le développeur précédent était réputé pour avoir réalisé des progrès significatifs en modifiant simplement les fichiers wp-login base.

Je savais que ce n'était pas durable, donc ma première tâche a été d'installer un plugin de sauvegarde/restauration et de remplacer le noyau de WordPress par une version fraîchement téléchargée. J'étais convaincu que rien de très impressionnant n'avait encore été réalisé dans le projet et que je serais capable d'imiter l'ensemble de fonctionnalités existant via des filtres.

Quelle que soit la capacité de codage que j'avais ou non à ce moment-là, elle est rapidement devenue sans objet, car mon nouvel employeur était devenu fou. Elle ne comprenait pas la signification du "hacking core" et je n'étais pas assez mature pour l'expliquer de manière digeste. La seule chose qui a temporairement refroidi son front, c'est quand je lui ai assuré que je pouvais revenir en arrière via le plugin de sauvegarde/restauration que j'avais installé.

Pouvez-vous deviner où cela va?

Ce plugin, comme le voulait le destin, n'a sauvegardé que le dossier wp-content . Quels que soient les hacks WordPress dans ces fichiers de base, ils ont disparu pour toujours. Je me souviens encore de mon e-mail (elle m'avait depuis longtemps renvoyé à mon bureau à domicile à ce stade):

Les gars, je ne peux pas faire la sauvegarde.

J'étais vraiment prêt à compléter son ensemble de fonctionnalités souhaité via des filtres et des actions, mais elle ne l'entendrait pas. Elle m'a viré sur-le-champ, a menacé de me poursuivre en justice et ne m'a jamais payé pendant deux semaines de travail très dur. J'étais tellement humilié.

Il y a beaucoup de choses (maintenant évidentes) que j'aurais pu apprendre de cette expérience. La leçon générale, qu'une sauvegarde n'est pas une sauvegarde tant qu'elle n'a pas été répétée et confirmée, est bonne. Mais celui qui m'a le plus marqué est une leçon spécifique sur la manière exacte de procéder aux sauvegardes dans WordPress, en particulier avec le noyau WordPress.

J'ai appris à vraiment chérir les environnements gérés comme WP-Engine, avec un système de sauvegarde/restauration robuste. De nombreux hébergeurs de boutique disposent de divers outils de ligne de commande et d'autres fonctionnalités axées sur les développeurs pour effectuer des sauvegardes, mais WP-Engine est mon préféré. C'est assez rapide sauf si vous avez un très grand réseau. L'interface utilisateur est simple. Il a une interface utilisateur, point final : quiconque sait utiliser WordPress peut travailler avec. C'est-à-dire que, contrairement à une approche CLI qui est probablement beaucoup plus rapide, ou à une chose obscure enfouie dans Plesk, mes clients peuvent l'utiliser, le comprendre, le surveiller et vérifier que je l'utilise. Je suis un grand fan.

La fois où j'ai fait glisser toute notre plate-forme dans son répertoire frère

J'étais encore assez nouveau sur le lieu de travail professionnel et j'avais toujours été une personne Windows. Cependant, mon nouveau travail était dans un magasin Mac et j'ai appris à tout aimer très rapidement. Eh bien, presque tout. J'avais l'impression d'avoir beaucoup de mal avec la "souris magique". J'avais tendance à perdre ma connexion Bluetooth, ce qui entraînait des actions de glisser-déposer accidentelles et souvent effrayantes une fois reconnectée. Plus que cela, j'étais juste maladroit avec une nouvelle motricité fine.

À cette époque, notre flux de développement WordPress incluait toujours le déploiement en production via FTP. Il n'était pas rare que je passe des journées entières de travail à écrire du code, à discuter, à répondre à des e-mails, généralement à faire des allers-retours via ma nouvelle souris magique, avec Cyberduck ouvert à la production sur mon bureau. Ça sonne mal ! Mais c'était comme ça.

Un jour, toute notre plate-forme a disparu. Notre administrateur système n'a pas tardé à supposer qu'il s'agissait d'une sorte de DDoS ou quelque chose de généralement à son niveau. Quant à nous, les développeurs, nous avons fait confiance à son instinct et avons supposé qu'il le découvrirait assez tôt.

Les heures ont passé. Le jour est venu et est parti. Toujours en bas.

Le lendemain matin, les choses étaient rétablies et notre CTO m'a gentiment demandé de la rejoindre dans la salle de conférence. Notre administrateur système a identifié le problème. Il a extrait les journaux FTP et a observé que mon utilisateur avait déplacé toute notre plate-forme dans un répertoire frère. Autrement dit, wp-content était devenu imbriqué sous wp-includes .

J'étais découragé, mais notre CTO était super à ce sujet. Elle pouvait voir que j'étais généralement un employé serviable et responsable, mais elle m'a mis au défi d'aller au-delà de la simple contrition et de trouver des moyens d'empêcher que cela ne se reproduise. J'ai trouvé deux choses vraiment utiles.

La première consistait à localiser une commande CLI pour empêcher Cyberduck d'autoriser les mouvements de fichiers de distance à distance. C'était une bonne mesure de sécurité et nous l'avons immédiatement adoptée comme politique de l'entreprise.

La seconde était que je m'intéressais vivement au déploiement via Git. Finalement, j'ai fini par écrire un plugin WordPress pour intégrer notre gestion des versions Bitbucket dans le flux de mise à jour normal wp-admin . Depuis lors, nous n'avons eu presque aucune raison d' avoir un accès FTP à la production. Ce plugin est une de mes réalisations professionnelles préférées. Bien sûr, une affinité pour Git est aujourd'hui un pré-requis pour les développeurs.

La fois où j'ai supprimé tout le contenu frontal via add_filter()

Je pensais vraiment que j'étais devenu assez intelligent avec mes pratiques WordPress à ce stade. La demande était d'apposer un "badge" aux messages d'une certaine catégorie. Pour une raison quelconque, j'avais en tête que seuls les noobs ajouteraient encore une autre condition à un fichier de modèle pour quelque chose comme ça, donc avec une grande fierté, j'ai implémenté le filtre suivant :

 add_filter( 'the_content', 'myprefix_add_a_badge' ); function myprefix_add_a_badge( $content ) { global $post; if( ! has_category( 'sponsored', $post ) ) { return false; } $out = $content . myprefix_get_badge(); return $out; }

Vous voyez quelque chose de mal à cela ? Je l'ai testé rapidement en mise en scène pour confirmer que les postes requis ont obtenu leurs badges appliqués. Ensuite, je l'ai déployé et j'ai quitté le travail pour la journée. Comme vous pouvez le deviner, l'univers a explosé.

Plus précisément, le résultat était que les publications sans badge étaient affichées sur le front-end sans aucun contenu ! Pouvez-vous voir pourquoi? Le problème était qu'au lieu de retourner $content dans ma condition de garde, je retournais false . Mais il y a vraiment de nombreuses couches d'erreurs ici.

Pourquoi me suis-je contenté de tester uniquement que les publications recevaient un badge ? Pourquoi n'ai-je pas également testé que d'autres postes restaient indemnes ? Pourquoi ai-je été déployé en production si tard dans la journée ? Pourquoi notre contrôle de qualité consistait-il entièrement en ce que je cliquais un peu et rafraîchissais la page ?

La réponse à toutes ces questions peut se résumer à la maturité . Il faut simplement un certain temps pour en avoir marre de faire ce genre d'erreurs, avant que nous soyons amenés à investir dans des choses comme les tests de régression visuelle et les tests unitaires. Cette erreur particulière a été une goutte d'eau, parmi des centaines, qui a fini par briser le dos du chameau et m'a conduit à devenir très investi dans phpUnit et xDebug. À leur tour, ces outils m'ont appris à écrire du code testable, ce qui a probablement évité plus de bogues que les tests eux-mêmes.

Le temps que j'ai divisé par zéro à l'intérieur d'une boucle infinie

La demande du client était de reformater la ligne du blog WordPress de manière à ce que la date se lise « Il y a XYZ » au lieu de « 10 novembre 2011 ». Je ne savais pas exactement comment y parvenir, mais j'étais conscient qu'il s'agissait d'un format de date qui semblait gagner en popularité, et en effet, le Dr Google m'a fourni un extrait très rapidement. Cela a fonctionné sur mon local! Il y avait beaucoup de maths, en particulier, beaucoup de division . Je ne savais pas exactement pourquoi cela fonctionnait - il y avait beaucoup de boucles imbriquées, de restes, d'arrondis, etc. Mais c'était sur Google et ça semblait fonctionner, et j'étais assez content de le déployer en production.

Environ 30 minutes plus tard, j'ai reçu un Skype hostile de notre administrateur système. La production était en baisse. Mort dans l'eau. Il m'a demandé si j'avais divisé par zéro ces derniers temps et je n'avais aucune idée de ce à quoi il pouvait faire référence. Voici ce qui s'est passé.

Croyez-le ou non, l'extrait illisible "travaillé sur mon local" que j'ai trouvé, étant donné une taille d'échantillon suffisamment grande, était capable d'un comportement aberrant. Fournies avec certaines combinaisons malheureuses de jours, d'heures et de minutes, les boucles de Rube Goldberg tentaient parfois de diviser un nombre par zéro. Rappel des maths du lycée :

En arithmétique ordinaire, l'expression n'a pas de sens, car il n'y a pas de nombre qui, multiplié par 0, donne a (en supposant a ≠ 0), et donc la division par zéro n'est pas définie. - Wikipédia

Alors qu'est-ce que cela signifie pour les ordinateurs? Habituellement, juste un message d'erreur dans les journaux, mais dans mon cas, c'était pire : l'erreur mathématique interférait avec ma logique de boucle, provoquant l'exécution de mes boucles imbriquées sans jamais se terminer - une boucle infinie menant à un écran blanc de la mort. Et c'est de pire en pire ! Parce que chaque itération de la boucle écrivait une erreur de division par zéro, le journal des erreurs a pris des proportions fantastiques et a commencé à gêner notre système de fichiers. Cela a eu l'effet d'une attaque DDoS, bien qu'absurdement auto-infligée.

La mauvaise chose à propos de cette erreur était qu'elle a supprimé un site à fort trafic. La bonne chose à propos de cette erreur est qu'elle a radicalement changé mon approche du travail. Plus que tout, j'avais honte de ma volonté de mettre en œuvre sans comprendre. J'ai juré de ne plus jamais coller un extrait sans faire tous les efforts possibles pour comprendre chaque ligne, même en faisant un suivi avec l'auteur de l'extrait si nécessaire.

Plus que cela, j'ai juré de ne plus jamais expédier de code qui n'était pas très lisible pour les développeurs novices. Je suis devenu obsédé par les normes de codage WordPress, les extensions d'éditeur de texte, les commentaires en ligne et les docblocks, et même les onglets contre les espaces, ce rite de passage classique ! En somme, j'ai décidé de me soucier plus de la facilité de lecture de mon code que de la facilité de son écriture . Cette rébellion contre le collage sans compréhension m'a amené à m'intéresser professionnellement à la gestion des dépendances à des tiers, un sujet qui m'a alimenté diverses opportunités d'écriture et de prise de parole au cours de la décennie qui a suivi.

Oh, et la chose vraiment drôle à propos de cette erreur ? Le noyau WordPress a une solution en une seule ligne pour cela.

La fois où j'ai laissé un projet devenir incontrôlable jusqu'à ce que tout le monde en ait marre

J'avais décroché un projet vraiment passionnant. Je devais être le responsable technique et l'ingénieur de développement WordPress, et j'aurais un développeur Amazon AWS Lambda et un expert approfondi en JavaScript qui me rapporterait. C'était la première fois que plusieurs personnes relevaient de moi, et c'était de loin le projet le plus complexe sur lequel j'avais jamais travaillé. Même le qualifier de projet WordPress sous-estimait grandement le problème, mais WordPress était le ciment qui maintenait le tout ensemble, il était donc logique pour moi d'agir en tant que responsable technique.

Parce que mon rôle principal était généralement d'être strictement un technicien, et aussi parce que j'ai une affinité pour le minimalisme, il ne m'est jamais venu à l'esprit d'implémenter quelque chose comme Jira ou Basecamp ou une véritable plate-forme de gestion des tâches. Les choses se sont plutôt bien déroulées pour la première itération du projet. Nous avons pu travailler sur nos propres composants individuels, nous référer au document de spécification du client comme feuille de route du produit et nous envoyer un ping via Slack lorsque nous avions besoin de coupler les choses ensemble.

Les problèmes ont commencé lorsque nous avons commencé à présenter les progrès au client et à mettre en œuvre ses commentaires. Ce qui a commencé comme une équipe de trois personnes a immédiatement senti qu'il avait été porté à un nouvel ordre de grandeur : il n'était pas clair qui était responsable de quel retour d'information, quel était le statut de la mise en œuvre de ce retour d'information, ou même qui parlait à qui. . Nous avons dépassé plusieurs fois la limite de 100 réponses par fil de Gmail !

Les choses ont commencé à devenir inconfortables. Je pense que le client avait l'impression d'avoir perdu le contrôle de la direction du projet, et tout aussi important, il avait l'impression d'avoir perdu la visibilité de l'état du projet. Mon développeur Amazon a mentionné un jour : « Je me demande si nous devrions utiliser Trello.

Hein , j'ai pensé. Une équipe de trois personnes a-t-elle besoin d'une plate-forme comme celle-là ? Encore une fois, ma tendance habituelle est de préférer moins d'outils, moins de frais généraux, moins de complexité. Mais le projet nous entraînait déjà tous dans la boue, alors quel était le mal à l'essayer ?

J'ai passé au peigne fin tous nos e-mails, tous nos documents de spécifications, tous nos fils de commentaires disparates et les ai tous cartographiés sur les tableaux Trello. Immédiatement, le projet s'est ressuscité de sa tombe numérique car nous pouvions communiquer avec beaucoup moins de surcharge mentale. Au lieu de chercher du texte dans ma boîte de réception ou un document de spécifications pour la plupart obsolète, nous avions de jolis tableaux, listes et cartes. Il était facile de voir l'état de n'importe quelle fonctionnalité, d'intégrer des commentaires et de distribuer de nouvelles tâches. C'était comme si nous étions progressivement devenus aveugles, si lentement que nous ne l'avons pas remarqué, et puis soudainement nous avons pu voir à nouveau.

Certes, le code ne s'est pas écrit tout seul, c'était toujours un projet très difficile et nous devions toujours utiliser chaque once de nos compétences techniques. Mais c'est en quelque sorte le but : Parce que nous avions enfin une infrastructure pour comprendre le projet, nous étions maintenant libres d'appliquer nos compétences techniques.

Je suis heureux de dire que ce projet a été réalisé à l'entière satisfaction du client. De nos jours, je considère Trello ou Jira comme une exigence de facto pour les équipes de deux ou plus.

Allez de l'avant et apprenez des erreurs des autres

Voici l'une des choses les plus intelligentes que j'ai entendues enseigner pendant mon temps dans l'armée : « C'est normal que les lieutenants fassent des erreurs de lieutenant et c'est normal que les capitaines fassent des erreurs de capitaine. Ce qui n'est pas acceptable, c'est que les capitaines commettent des erreurs de lieutenant ou que les lieutenants commettent des erreurs privées.

En d'autres termes, il n'y a rien de mal à commettre les erreurs courantes qui vont de soi compte tenu de votre niveau de responsabilité actuel. Ce qui est plus important, c'est comment vous grandissez à partir d'eux.

J'espère qu'en tant que développeurs, nous apprendrons à faire preuve de compassion envers les autres lorsqu'ils commettent des erreurs, car j'espère que d'autres l'ont été avec nous. J'espère rester curieux et responsable lorsque je fais des erreurs afin de continuer à innover au-delà. J'espère être toujours entouré d'une communauté inspirante d'experts WordPress, des personnes dont je peux apprendre les erreurs et éviter de les commettre moi-même. Et surtout, j'espère que d'autres pourront apprendre de mon expérience, comme les erreurs WordPress que j'ai partagées ici.