Meine fünf schlimmsten WordPress-Entwicklungsfehler

Oder, an alle Server, die ich zuvor getankt habe: Ein Rückblick mit Schrecken auf die fünf schlimmsten WordPress-Fehler, die ich gemacht habe

Als Entwickler machen wir an verschiedenen Stellen unserer Karriere unterschiedliche Arten von Fehlern. Insbesondere in der WordPress-Entwicklung machen wir mit zunehmender Vertrautheit mit der WordPress-Codebasis verschiedene Arten von Fehlern.

Vor einigen Jahren hörte ich, wie Matt Mullenweg etwas erklärte, dass die meisten Menschen ihre Fehler wiederholen, klügere Menschen aus ihren Fehlern lernen und die klügsten Menschen unter uns aus den Fehlern anderer lernen. Das gefällt mir sehr gut, und ich würde eine logische Folgerung hinzufügen: Jeder macht Fehler, bescheidene Menschen teilen diese Fehler privat, und die Mutigsten unter uns schreiben sie auf und veröffentlichen sie in einem Blog!

Aber zum Nachdenken ist später noch Zeit. Sie lesen diesen Artikel, weil Sie etwas über ein Zugunglück erfahren möchten, und ich bin der Lokführer. Schließe mich ohne weitere Vorrede einem entsetzten Rückblick auf die fünf peinlichsten Fehler an, die ich als WordPress-Entwickler gemacht habe.

Die Zeit, in der ich eine gehackte Version von WordPress Core aktualisiert habe

Ich machte gerade meinen Abschluss von höchst obskuren CraigsList-Coding-Auftritten, um tatsächlich in einer echten Live-Agentur zu arbeiten. Ich war angekommen! Ich war nervös, von einem anderen Ort als meiner Couch aus zu arbeiten, in etwas anderem als meinem Schlafanzug. Aber schon damals kannte ich WordPress im Allgemeinen direkt von WordPress Doing It Wrong, und ich fand es angenehm selbstverherrlichend, mit WordPress Best Practices zu prahlen, als würde ich nie „den Kern hacken“.

Meine erste WordPress-Entwicklungsaufgabe bei dieser Agentur bestand darin, ein ins Stocken geratenes Projekt wieder aufzunehmen – ein ziemlich komplexes für meine damaligen Fähigkeiten. Es waren viele Anpassungen an der WordPress-Registrierung und dem Anmeldeablauf erforderlich. Dem vorherigen Entwickler wurde nachgesagt, dass er durch einfaches Bearbeiten der zentralen wp-login Dateien erhebliche Fortschritte erzielt habe.

Ich wusste, dass dies nicht nachhaltig war, also bestand meine erste Aufgabe darin, ein Backup-/Wiederherstellungs-Plugin zu installieren und den WordPress-Kern durch eine frisch heruntergeladene Version zu ersetzen. Ich war zuversichtlich, dass in dem Projekt noch nichts besonders Beeindruckendes geleistet worden war und dass ich in der Lage sein würde, den vorhandenen Funktionsumfang über Filter nachzuahmen.

Welche Programmierfähigkeiten ich zu diesem Zeitpunkt auch hatte oder nicht, wurde schnell irrelevant, da mein neuer Arbeitgeber kochte. Sie verstand die Bedeutung von „Hacking Core“ nicht und ich war nicht reif genug, um es auf verständliche Weise zu erklären. Das einzige, was sie vorübergehend kühlte, war, als ich ihr versicherte, dass ich über das von mir installierte Backup/Restore-Plugin wiederherstellen könnte.

Kannst du erraten, wohin das führt?

Dieses Plugin hat, wie es das Schicksal wollte, nur den Ordner wp-content gesichert. Welche WordPress-Hacks auch immer in diesen Kerndateien enthalten waren, sie waren für immer verschwunden. Ich erinnere mich noch an meine E-Mail an sie zurück (sie hatte mich zu diesem Zeitpunkt längst wieder ins Homeoffice verbannt):

Leute, ich kann das Backup nicht machen.

Ich war wirklich bereit, ihr gewünschtes Feature-Set über Filter und Aktionen zu vervollständigen, aber sie wollte es nicht hören. Sie entließ mich auf der Stelle, drohte, mich zu verklagen, und bezahlte mich nie für zwei Wochen sehr harter Arbeit. Ich war so gedemütigt.

Es gibt viele (jetzt offensichtliche) Dinge, die ich aus dieser Erfahrung hätte lernen können. Die allgemeine Lektion, dass ein Backup kein Backup ist, bis es geprobt und bestätigt wurde, ist gut. Aber diejenige, die mir mehr im Gedächtnis geblieben ist, ist eine spezielle Lektion darüber, wie man Backups in WordPress genau angeht – insbesondere mit dem WordPress-Kern.

Ich habe gelernt, verwaltete Umgebungen wie WP-Engine mit einem robusten Sicherungs-/Wiederherstellungssystem wirklich zu schätzen. Viele Boutique-Hosts verfügen über verschiedene Befehlszeilentools und andere auf Entwickler ausgerichtete Funktionen zum Durchführen von Backups, aber die von WP-Engine ist mein Favorit. Es ist ziemlich schnell, es sei denn, Sie haben ein sehr großes Netzwerk. Die Benutzeroberfläche ist einfach. Es hat eine Benutzeroberfläche, Punkt: Jeder, der sich mit WordPress auskennt, kann damit arbeiten. Das heißt, im Gegensatz zu einigen CLI-Ansätzen, die wahrscheinlich viel schneller sind, oder einer obskuren Sache, die in Plesk vergraben ist, können meine Kunden dies verwenden, verstehen, überwachen und überprüfen, ob ich es verwende. Ich bin ein großer Fan.

Die Zeit, als ich unsere gesamte Plattform in ihr Geschwisterverzeichnis gezogen habe

Ich war noch ziemlich neu am professionellen Arbeitsplatz und war schon immer ein Windows-Mensch. Mein neuer Job war jedoch in einem Mac-Shop und ich habe sehr schnell alles daran lieben gelernt. Naja, fast alles. Ich schien große Probleme mit der „magischen Maus“ zu haben. Ich neigte dazu, meine Bluetooth-Verbindung zu verlieren, was zu versehentlichen und oft beängstigenden Drag-and-Drop-Aktionen führte, sobald die Verbindung wiederhergestellt war. Mehr noch, ich war einfach ungeschickt mit einer neuen Feinmotorik.

Damals umfasste unser WordPress-Entwicklungsablauf noch die Bereitstellung für die Produktion über FTP. Es war nicht ungewöhnlich, dass ich ganze Arbeitstage damit verbrachte, Code zu schreiben, zu chatten, E-Mails zu beantworten und im Allgemeinen mit meiner neuen magischen Maus hin und her zu wirbeln, während Cyberduck auf meinem Desktop für die Produktion geöffnet war. Meine Güte, hört sich das schlecht an! Aber so war es.

Eines Tages war unsere gesamte Plattform einfach weg. Unser Systemadministrator ging schnell davon aus, dass es sich um eine Art DDoS oder etwas im Allgemeinen auf seinem Niveau handelte. Was uns Entwickler betrifft, wir vertrauten seinem Instinkt und gingen davon aus, dass er es früh genug herausfinden würde.

Stunden vergingen. Der Tag kam und ging. Immernoch herunter.

Am nächsten Morgen waren die Dinge wiederhergestellt, und unser CTO bat mich sanft, zu ihr in den Konferenzraum zu kommen. Unser Systemadministrator hatte das Problem identifiziert. Er zog die FTP-Protokolle und stellte fest, dass mein Benutzer unsere gesamte Plattform in ein gleichgeordnetes Verzeichnis verschoben hatte. Das heißt, wp-content wurde unter wp-includes verschachtelt.

Ich war niedergeschlagen, aber unser CTO war großartig. Sie konnte sehen, dass ich im Allgemeinen ein hilfsbereiter und verantwortungsbewusster Angestellter war, aber sie forderte mich auf, über bloße Reue hinauszugehen und Wege zu finden, um zu verhindern, dass dies jemals wieder vorkommt. Ich habe zwei wirklich hilfreiche Dinge gefunden.

Die erste bestand darin, einen CLI-Befehl zu finden, um Cyberduck daran zu hindern, Dateibewegungen von Remote zu Remote überhaupt zuzulassen. Dies war eine gute Sicherheitsmaßnahme, die wir sofort als Unternehmensrichtlinie übernommen haben.

Das zweite war, dass ich mich sehr für die Bereitstellung über Git interessierte. Schließlich schrieb ich ein WordPress-Plugin, um unsere Bitbucket-Versionierung in den normalen wp-admin Aktualisierungsablauf einzubinden. Seitdem hatten wir fast keinen Grund mehr, FTP-Zugriff auf die Produktion zu haben. Dieses Plugin ist eine meiner liebsten beruflichen Errungenschaften. Eine Affinität zu Git ist für Entwickler heute natürlich Voraussetzung.

Die Zeit, als ich alle Frontend-Inhalte über add_filter() entfernt habe

Ich dachte wirklich, ich wäre zu diesem Zeitpunkt mit meinen WordPress-Praktiken ziemlich schlau geworden. Der Wunsch bestand darin, Posts einer bestimmten Kategorie mit einem „Badge“ zu versehen. Aus irgendeinem Grund hatte ich im Hinterkopf, dass nur Noobs einer Vorlagendatei für so etwas noch eine weitere Bedingung hinzufügen würden, also habe ich mit großem Stolz den folgenden Filter implementiert:

 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; }

Sehen Sie irgendetwas daran falsch? Ich habe es schnell in der Staging-Phase getestet, um zu bestätigen, dass die erforderlichen Posts ihre Abzeichen erhalten haben. Dann setzte ich es ein und verließ die Arbeit für den Tag. Wie Sie sich vorstellen können, explodierte das Universum.

Das Ergebnis war insbesondere, dass Posts ohne das Abzeichen im Frontend ohne jeglichen Inhalt gerendert wurden! Können Sie sehen, warum? Das Problem war, dass ich, anstatt $content in meinem Guard-Zustand zurückzugeben, false zurückgab. Aber wirklich gibt es hier viele Schichten von Fehlern.

Warum war ich damit zufrieden, nur zu testen, ob Beiträge ein Badge erhalten haben? Warum habe ich nicht auch getestet, ob andere Pfosten unbeschädigt geblieben sind? Warum habe ich so spät am Tag für die Produktion bereitgestellt? Warum bestand unsere Qualitätskontrolle ausschließlich darin, dass ich ein wenig herumklickte und die Seite aktualisierte?

Die Antwort auf all diese Fragen kann als Reife zusammengefasst werden. Es dauert einfach eine Weile, bis wir es satt haben, diese Art von Fehlern zu machen, bevor wir uns dazu bewegen, in Dinge wie visuelle Regressionstests und Komponententests zu investieren. Dieser spezielle Fehler war unter Hunderten ein Strohhalm, der schließlich das Rückgrat des Kamels brach und dazu führte, dass ich mich sehr für phpUnit und xDebug interessierte. Diese Tools wiederum haben mich gelehrt, testbaren Code zu schreiben, was wahrscheinlich mehr Fehler verhindert hat als die Tests selbst.

Die Zeit, die ich innerhalb einer Endlosschleife durch Null geteilt habe

Die Kundenanfrage bestand darin, die Byline des WordPress-Blogposts so umzuformatieren, dass das Datum „vor XYZ“ statt „10. November 2011“ lautet. Ich war mir nicht ganz sicher, wie ich das erreichen sollte, aber ich war mir bewusst, dass es sich um ein Datumsformat handelte, das immer beliebter zu werden schien, und tatsächlich lieferte mir Dr. Google sehr schnell einen Ausschnitt. Bei meinem Lokal hat es funktioniert! Es hatte viel Mathematik, insbesondere viel Division . Ich war mir nicht ganz sicher, warum es funktionierte – es gab viele verschachtelte Schleifen, Reste, Rundungen und so weiter. Aber es war auf Google und es schien zu funktionieren, und ich war glücklich genug, es in der Produktion bereitzustellen.

Ungefähr 30 Minuten später bekam ich ein unfreundliches Skype von unserem Systemadministrator. Die Produktion war ausgefallen. Tot im Wasser. Er fragte mich, ob ich in letzter Zeit durch Null geteilt hätte, und ich hatte keine Ahnung, worauf er sich beziehen könnte. Folgendes ist passiert.

Ob Sie es glauben oder nicht, das unlesbare Snippet „funktionierte auf meinem lokalen Gerät“, das ich gefunden habe, war bei einer ausreichend großen Stichprobengröße zu einem abweichenden Verhalten fähig. Ausgestattet mit einigen unglücklichen Kombinationen von Tagen, Stunden und Minuten versuchten die Schleifen von Rube Goldberg gelegentlich, eine Zahl durch Null zu teilen. Rückruf aus dem Gymnasium Mathe:

In der gewöhnlichen Arithmetik hat der Ausdruck keine Bedeutung, da es keine Zahl gibt, die, wenn sie mit 0 multipliziert wird, a ergibt (unter der Annahme, dass a ≠ 0), und daher die Division durch Null undefiniert ist. -Wikipedia

Was bedeutet das für Computer? Normalerweise nur eine Fehlermeldung in den Protokollen, aber in meinem Fall war es schlimmer: Der mathematische Fehler störte meine Schleifenlogik, was dazu führte, dass meine verschachtelten Schleifen ausgeführt wurden, ohne jemals abgeschlossen zu werden – eine Endlosschleife, die zu einem weißen Bildschirm des Todes führte. Und es kommt noch schlimmer! Da jede Iteration der Schleife einen Fehler für die Division durch Null schrieb, wuchs das Fehlerprotokoll zu fantastischen Ausmaßen und begann, unser Dateisystem zu behindern. Das wirkte wie ein DDoS-Angriff, wenn auch ein absurder selbstverschuldeter.

Das Schlimme an diesem Fehler war, dass er eine stark frequentierte Website zum Erliegen brachte. Das Gute an diesem Fehler ist, dass er meine Arbeitsweise dramatisch verändert hat. Vor allem schämte ich mich für meine Umsetzungsbereitschaft ohne Verständnis. Ich habe mir geschworen, nie wieder ein Snippet einzufügen, ohne mich nach Kräften zu bemühen, jede Zeile zu verstehen, und notfalls sogar den Autor des Snippets zu kontaktieren.

Darüber hinaus habe ich mir geschworen, nie wieder Code auszuliefern, der für unerfahrene Entwickler nicht gut lesbar ist. Ich war besessen von den WordPress-Codierungsstandards, Texteditorerweiterungen, Inline-Kommentaren und Docblocks und sogar Tabs versus Spaces, diesem klassischen Übergangsritus! Zusammenfassend habe ich beschlossen, mich mehr darum zu kümmern, wie einfach es war, meinen Code zu lesen , als wie einfach es war, ihn zu schreiben . Diese Rebellion gegen das Einfügen ohne Verständnis führte dazu, dass ich mich beruflich intensiv mit der Verwaltung von Abhängigkeiten von Drittanbietern befasste, ein Thema, das mir in den folgenden zehn Jahren verschiedene Schreib- und Redegelegenheiten bescherte.

Oh, und das wirklich Lustige an diesem Fehler? WordPress Core hat dafür eine Einzeiler-Lösung.

Die Zeit, in der ich ein Projekt außer Kontrolle geraten ließ, bis alle es satt hatten

Ich hatte ein wirklich faszinierendes Projekt gelandet. Ich sollte der technische Leiter und WordPress-Entwicklungsingenieur sein, und ich würde einen Amazon AWS Lambda-Entwickler und einen tiefgreifenden JavaScript-Experten haben, der mir Bericht erstattet. Dies war das erste Mal, dass mir mehrere Leute unterstellt waren, und es war bei weitem das komplexeste Projekt, an dem ich je gearbeitet hatte. Es auch nur als WordPress-Projekt zu bezeichnen, würde die Sache stark untertreiben, aber WordPress war der Kitt, der das Ganze zusammenhielt, also machte es Sinn, dass ich als technischer Leiter fungierte.

Da meine primäre Rolle in der Regel darin bestand, ausschließlich Techniker zu sein, und weil ich auch eine Affinität zum Minimalismus habe, kam ich nie auf die Idee, etwas wie Jira oder Basecamp oder eine echte Plattform für das Aufgabenmanagement zu implementieren. Die Dinge liefen ziemlich gut für die erste Iteration des Projekts. Wir konnten an unseren eigenen individuellen Komponenten arbeiten, auf das Kundenspezifikationsdokument als unsere Produkt-Roadmap verweisen und uns einfach über Slack anpingen, wenn wir Dinge miteinander verbinden mussten.

Die Probleme begannen, als wir anfingen, dem Kunden den Fortschritt zu präsentieren und sein Feedback umzusetzen. Was als dreiköpfiges Team begann, fühlte sich sofort in eine neue Größenordnung gehoben: Es war unklar, wer für welches Feedback verantwortlich war, wie der Stand der Umsetzung dieses Feedbacks war oder wer überhaupt mit wem sprach . Wir haben das Gmail-Limit von 100 Antworten pro Thread mehrmals überschritten!

Die Dinge begannen unangenehm zu werden. Ich denke, der Kunde hatte das Gefühl, die Kontrolle über die Projektrichtung verloren zu haben, und was ebenso wichtig ist, er hatte das Gefühl, den Überblick über den Projektstatus verloren zu haben. Mein Amazon-Entwickler sagte eines Tages: „Ich frage mich, ob wir Trello verwenden sollten.“

Hach , dachte ich. Braucht ein dreiköpfiges Team so eine Plattform? Auch hier ist meine übliche Tendenz, weniger Tools, weniger Overhead und weniger Komplexität zu bevorzugen. Aber das Projekt zog uns bereits alle in den Dreck, also was schadete es, es zu versuchen?

Ich habe alle unsere E-Mails, alle unsere Spezifikationsdokumente, alle unsere unterschiedlichen Kommentar-Threads durchkämmt und sie alle auf Trello-Boards abgebildet. Sofort erhob sich das Projekt aus seinem digitalen Grab, weil wir mit weit weniger mentalem Aufwand kommunizieren konnten. Anstatt nach Text in meinem E-Mail-Posteingang oder einem größtenteils veralteten Spezifikationsdokument zu suchen, hatten wir schöne Boards, Listen und Karten. Es war einfach, den Status jeder Funktion zu sehen, Feedback zu integrieren und neue Aufgaben zu verteilen. Es fühlte sich an, als würden wir allmählich erblinden, so langsam, dass wir es nicht bemerkten, und dann plötzlich wieder sehen könnten.

Zugegeben, der Code schrieb sich nicht von selbst, es war immer noch ein sehr herausforderndes Projekt, und wir mussten unser gesamtes technisches Können einsetzen. Aber das ist so ungefähr der Punkt: Da wir endlich eine Infrastruktur hatten, um das Projekt zu verstehen, konnten wir unsere technischen Fähigkeiten jetzt frei einsetzen.

Ich freue mich sagen zu können, dass dieses Projekt zur vollsten Zufriedenheit des Kunden abgeschlossen wurde. Heutzutage halte ich Trello oder Jira für eine De-facto-Voraussetzung für Teams ab zwei Personen.

Gehen Sie voran und lernen Sie aus den Fehlern anderer

Hier ist eines der klügsten Dinge, die mir während meiner Zeit beim Militär beigebracht wurden: „Es ist in Ordnung für Leutnants, Leutnantfehler zu machen, und es ist in Ordnung für Kapitäne, Kapitänsfehler zu machen. Was nicht in Ordnung ist, ist, dass Kapitäne Leutnantfehler machen, oder dass Leutnants private Fehler machen.“

Mit anderen Worten, es ist in Ordnung, die üblichen Fehler zu machen, die für Ihre aktuelle Verantwortungsstufe selbstverständlich sind. Wichtiger ist, wie Sie an ihnen wachsen.

Ich hoffe, dass wir als Entwickler lernen, mit anderen mitfühlend zu sein, wenn sie Fehler machen, so wie andere es hoffentlich mit uns gemacht haben. Ich hoffe, dass ich neugierig und rechenschaftspflichtig bleibe, wenn ich Fehler mache, damit ich sie weiter erneuern kann. Ich hoffe, immer von einer inspirierenden Community von WordPress-Experten umgeben zu sein – Menschen, von deren Fehlern ich lernen und die ich vermeiden kann. Und nicht zuletzt hoffe ich, dass andere aus meinen Erfahrungen lernen können, wie die WordPress-Fehler, die ich hier geteilt habe.