Wie man sich der modernen WordPress-Entwicklung nähert (Teil 1)

Veröffentlicht: 2022-03-11

Es ist kein Geheimnis, dass die WordPress-Codebasis ein Durcheinander ist. Persönlich möchte ich mich jedes Mal, wenn ich es durchmache, zusammenrollen und weinen. Auf der anderen Seite ist WordPress seiner Konkurrenz weit voraus. Ein benutzerfreundliches und leistungsstarkes CMS ist ein enormes Unterfangen, und WordPress bleibt beliebt, weil es dies bietet.

Warum sollten wir uns also um die Qualität des Codes im WordPress-Kern kümmern? Es funktioniert, oder?

Ja, es funktioniert, und es ist unwahrscheinlich, dass die 15 Jahre alte Codebasis von ihren freiwilligen Betreuern vollständig umgestaltet wird. Leider bedeutet dies, dass es auch als Beispiel für die Codierung „auf WordPress-Weise“ fungiert und zahlreiche Entwickler dafür entschuldigt, dass sie Best Practices und moderne Entwicklungstechniken nicht befolgt haben. So viele WordPress-Plugins und -Themes haben einen berüchtigt schlechten Code, und das blinde Befolgen von Legacy-Praktiken setzt den Trend nur fort.

Aber wen kümmert schon schlechter Code, der immer noch seinen Zweck erfüllt? Nun, nichts ist umsonst, und jemand bezahlt für eine schlecht gemachte Arbeit. Mit der WordPress-Codebasis selbst bezahlen ihre Betreuer glücklicherweise mit ihrer Zeit. Aber mit Ihrem eigenen Code zahlt Ihr Kunde.

Selbst für ein mäßig komplexes System sind die Kosten für die anfängliche Entwicklung im Vergleich zu den Wartungskosten unbedeutend, und Wartung bedeutet auch das Hinzufügen neuer Funktionen. Die Beauftragung eines Entwicklers mit der Reparatur schlecht entworfener und implementierter Software wird ein Vielfaches mehr kosten, als sie von Anfang an richtig zu entwickeln.

Billige Lösungen sind auf Dauer immer die teuersten. Oder sie werden aufgegeben, nachdem das Budget aufgebraucht ist. Wir sparen unseren Kunden tatsächlich Geld, wenn wir bewährten Softwaredesign-Prinzipien und -Praktiken folgen. Diese Methoden sind weder eine aufgebauschte Modeerscheinung noch eine Veränderung um der Veränderung willen. Die Weisheit hier ist aus der kollektiven Erfahrung der Entwickler entstanden, und es zahlt sich wirklich aus, sich daran zu halten.

Offensichtlich gilt dies nicht für wirklich einfache Aufgaben wie das Hinzufügen einiger CSS-Zeilen oder ein paar benutzerdefinierter Posts und Umschreibungen. Aber ein paar Plugins (oder häufiger mehrere Dutzend Plugins) zusammenzuschlagen oder eine Visual Composer-betriebene Site am laufenden Band zu produzieren, ist ohnehin keine Softwareentwicklung.

Das ist an sich keine schlechte Sache – die Tatsache, dass einige Lösungen so einfach sind, ist der Grund, warum WordPress so beliebt ist. Aber in dieser Serie werde ich über echte WordPress-Entwicklung sprechen: das Schreiben von bedeutendem PHP-, HTML-, CSS- und JavaScript-Code. Ich beginne mit dem allgemeinen Arbeitsablauf und konzentriere mich dann in diesem Artikel auf die Entwicklung des WordPress-Frontends.

Moderner WordPress-Entwicklungsworkflow

Im Allgemeinen ist der Qualitätscode:

  • Lesbar. Es ist leicht zu verstehen, was Code tut und warum.
  • Modular. Kleine Codeblöcke mit einem klaren Zweck sind leicht zu verstehen, zu entwickeln und zu testen.
  • Wiederverwendbar. Die Wiederverwendung bereits entwickelter Module zur Lösung ähnlicher Probleme beschleunigt die Entwicklung erheblich.
  • Wartbar. Das Ändern alter Funktionen oder das Einführen neuer Funktionen ist einfach.

Die Hauptergebnisse – niedrigere Entwicklungs- und Betriebskosten – haben viele Nebenvorteile, auf die ich hier nicht eingehen werde.

Stattdessen konzentriere ich mich darauf, welche Entwicklungstechniken und Best Practices Ihnen helfen können, qualitativ hochwertigen Code zu produzieren. Beginnen wir mit der Versionskontrolle.

Versionskontrolle verwenden

Dies bedeutet, Git zu verwenden. Leider ist „Cowboy-Codierung“ bei der Produktion über FTP immer noch so ziemlich eine Sache. Erst kürzlich habe ich für eine in Großbritannien ansässige Agentur gearbeitet und sie hatten Dateien mit Namen wie diesen in ihrer gesamten Codebasis:

  • functions copy.php
  • functions copy 2.php
  • functions test.php
  • functions2.php
  • functions test2.php

Das allererste, was Sie tun sollten, wenn Sie eine WordPress-Site übernehmen, ist, sie unter Versionskontrolle zu stellen. Tanking Servers ist eine unterhaltsame Retrospektive von WordPress-Entwicklungsfehlern. Es wäre sehr einfach gewesen, diese – und ähnliche Pannen, die wahrscheinlich jedem passiert sind – mit Git zu beheben.

Du hast einen Fehler in deinem Code gemacht und die ganze Seite ist ausgefallen? git reset bringt alles wieder so wie es war. Neues Versionsupdate hat alles kaputt gemacht? git reset funktioniert als Zeitmaschine. Ein bösartiger Code ist aus dem Nichts aufgetaucht? git status zeigt alle neuen Dateien, gelöschten Dateien oder Änderungen an verfolgten Dateien an. Dann git checkout und stellst die Originale wieder her.

Achten Sie darauf, den .git Ordner offenzulegen

OK, es ist eindeutig wichtig, Git zu verwenden. Aber wenn Sie dies tun, ist es genauso wichtig, dass Sie Ihr Git-Repository nicht hacken. Das Problem tritt auf, wenn Sie .git -Ordner offengelegt haben und Ihre Anmeldeinformationen darin speichern.

Eine Standard-WordPress-Installation lebt vollständig in einem öffentlichen Webordner, und der .git -Ordner ist sehr wahrscheinlich auch dort. Offensichtlich sollten keine Anmeldeinformationen im Git-Repository gespeichert werden, aber es kommt vor, dass die meisten Repositories einige sensible Informationen enthalten, die nicht nach außen durchsickern sollten.

Daher sollte der öffentliche Zugriff auf den .git Ordner blockiert werden. Wenn Sie Apache verwenden, blockiert das Hinzufügen des unten stehenden Snippets oben in der .htaccess -Datei den Zugriff auf den .git -Ordner und auch auf die Protokolldateien. Protokolldateien enthalten oft vertrauliche Informationen, daher ist es ratsam, sie ebenfalls nicht verfügbar zu machen. Für unterschiedliche Webserver-Setups fragen Sie bitte Ihren DevOps-Experten um Hilfe.

 RedirectMatch 404 /\.git RedirectMatch 404 ^.*\.log

Verwenden Sie separate Umgebungen

Führen Sie keine Entwicklung auf Live-Sites durch – das ist ein Rezept für Ausfallzeiten und unzufriedene Kunden. OK, aber wie soll man es einrichten?

Idealerweise sollte es drei Entwicklungsumgebungen geben, wobei der Code immer in eine Richtung geht: lokal → Staging → Produktion. Dies ist eine bewährte Methode zur Kollisionsvermeidung. Alle Core-, Plugin- und Theme-Updates werden zuerst lokal durchgeführt, dann beim Staging getestet und schließlich in der Produktion bereitgestellt.

Beispielsweise könnte die serverspezifische Konfiguration in einer separaten Datei gespeichert werden. Du kannst eine wp-config-local.php für jede lokale und Staging-Umgebung erstellen. (Vergiss nicht, es zu deiner .gitignore -Datei hinzuzufügen!) Dann füge das folgende Snippet zu wp-config.php :

 if (file_exists(dirname(__FILE__) . '/wp-config-local.php')) : // use local settings require_once(dirname(__FILE__) . '/wp-config-local.php'); else : // production settings endif;

Häufig ist der beste Weg, verschiedene Umgebungen einzurichten, die Verwendung von Umgebungsvariablen. Wenn Sie mit diesem Konzept nicht vertraut sind, würde ich Ihnen raten, eine komplette moderne Lösung wie Roots zu verwenden.

Verwenden Sie WP-CLI

Die WordPress-Befehlszeilenschnittstelle (WP-CLI) ist ein äußerst nützliches Tool zur Verwaltung von WordPress-Installationen. Zugriff auf WP-CLI zu haben bedeutet, praktisch jede WordPress-API-Funktion ausführen zu können. Beispielsweise können Sie mit WP-CLI Benutzer und ihre Passwörter hinzufügen, entfernen und bearbeiten. Nützlich, wenn Sie gerade eine Website geerbt haben und der Besitzer sich selbst ausgesperrt hat.

Ein weiteres Beispiel ist, dass die anfängliche Bereitstellung mit WP-CLI ein Kinderspiel ist. Diese können mit wenigen Befehlen erreicht werden:

  • Herunterladen von Core, Themes und Plugins
  • Suchen und Ersetzen in der Datenbank
  • Admin-Benutzer hinzufügen

Darüber hinaus können diese Aktionen skriptgesteuert und automatisiert werden.

Verwenden Sie erweiterte Bereitstellungsoptionen

Apropos Automatisierung: Es lohnt sich, einige Bereitstellungstechnologien und -prozesse zu lernen, wie zum Beispiel:

  • Continuous Integration/Continuous Deployment/Delivery (CI/CD)
  • Docker
  • Automatisierte Tests (einschließlich Front-End-Regressionstests)

Zugegeben, der Wechsel von der Nichtverwendung der Versionskontrolle zum Umgang mit Docker ist ein großer Schritt und wird für ein typisches Ein-Personen-WordPress-Projekt wahrscheinlich überwältigend sein. Einige Optionen sind je nach Hosting-Anbieter möglicherweise nicht einmal möglich. Aber Advanced Deployment ist ein Muss für Teams und für größere Projekte.

Linting verwenden

Für Projekte jeder Größe ist Linting jedoch ein Segen für die meisten Entwickler. Linting bedeutet, dass Ihr Code automatisch auf Fehler überprüft wird. Eine voll funktionsfähige IDE wie PHPStorm erledigt dies bereits von Haus aus; einfachere Editoren wie VSCode oder Sublime Text benötigen jedoch ein spezielles Programm namens Linter. Eine Möglichkeit, dies einzurichten, besteht darin, Ihren Editor so zu konfigurieren, dass er einen Linter ausführt, wenn Sie eine Datei speichern.

PHP_CodeSniffer ist der De-facto-Linter für PHP. Zusätzlich zur Überprüfung auf Syntaxfehler kann es auch überprüfen, ob Ihr Code Stilrichtlinien wie PSR-2 entspricht. Dies vereinfacht das Befolgen von Codierungsstandards erheblich.

Für JavaScript ist ESLint ein beliebter Linter. Es verfügt über ein umfangreiches Regelwerk und unterstützt benutzerdefinierte Konfigurationen für alle verfügbaren JavaScript-Varianten und -Frameworks.

Ein leistungsstarker Anwendungsfall ist hier die Integration von Linting in eine CI/CD-Build-Pipeline, sodass der gesamte Code vor der Bereitstellung automatisch validiert wird.

Moderne WordPress-Frontend-Entwicklungstechniken

Nachdem Sie nun einen geeigneten Workflow für Ihr gesamtes WordPress-Projekt eingerichtet haben, lassen Sie uns in die Best Practices für das Frontend eintauchen.

Verwenden Sie moderne Tools: Sass und ES6+

Die Welt der Front-End-Entwicklung verändert sich ständig und ist immer in Bewegung. Früher dachten wir, Sass sei das beste Werkzeug zum Schreiben von CSS – und für die WordPress-Entwicklung vor Gutenberg ist es das immer noch –, aber dann fingen alle an, über CSS in JS und gestylte Komponenten zu sprechen.

Sogar WordPress konnte nicht widerstehen und hat einige dieser neuen Technologien aufgegriffen. Gutenberg, der neue Blockeditor, basiert auf React und einer REST-API.

Sie sollten sich unbedingt mit diesen zentralen Front-End-Technologien vertraut machen:

  • ES6+. Die WordPress-Dokumentation nennt es ESNext und empfiehlt sogar, es zu verwenden.
  • Sass. Wird von WooCommerce verwendet und ist der beste Weg, CSS zu schreiben, wenn Sie sich noch nicht mit CSS in JS beschäftigen.
  • Webpaket. Sogar der WordPress-Kern verwendet jetzt Webpack und Babel.

ES6 und Sass sind modernes JavaScript bzw. CSS, und Webpack ist ein Tool, das die Verwendung all dieser modernen Funktionen ermöglicht, ohne sich Gedanken über die Abwärtskompatibilität machen zu müssen. Webpack kann als Front-End-App-Compiler bezeichnet werden, der Dateien zur Verwendung in einem Browser generiert.

Übergang von jQuery zu Vue.js oder React

Der WordPress-Kern und fast alle WordPress-Plugins hängen von jQuery ab, sodass Sie nicht einfach aufhören können, es zu verwenden. Tatsächlich macht es keinen Sinn, es für einfache Aufgaben wie das Verstecken einiger <div> s oder das Ausführen einer einmaligen AJAX-Anfrage einzustellen, wenn Sie es gewohnt sind, es auf diese Weise zu tun. jQuery wird sowieso geladen und ist einfach und leicht zu bedienen.

Bei komplexen Apps hat jQuery Probleme: Schwer nachvollziehbare Logik, Callback-Hölle, globale Variablen und kein HTML-Template. Dies erfordert eindeutig eine andere Art, die Frontend-App zu organisieren.

Moderne Front-End-Bibliotheken wie React verwenden Prinzipien der objektorientierten Programmierung (OOP) und organisieren die Front-End-App-Architektur in modulare, wiederverwendbare Komponenten. Eine Komponente enthält den gesamten Code, das Markup und den „Komponentenstatus“ (Variablen) für ein bestimmtes Element. Ein Element kann fast alles sein: eine Schaltfläche, ein Eingabefeld, ein Benutzerformular oder ein Widget, das die letzten Beiträge aus dem Backend der WordPress-REST-API anzeigt. Komponenten können andere Komponenten enthalten und eine hierarchische Beziehung bilden.

Bei der heutigen Komplexität von Webseiten ist die Organisation einer App in Komponenten eine bewährte Methode, um wartbare, schnelle Web-Apps beliebiger Komplexität zu erstellen. Komponenten sind in hohem Maße wiederverwendbare, isolierte und somit leicht testbare „Bausteine“, daher lohnt es sich wirklich, dieses Konzept zu lernen.

Es gibt zwei komponentenbasierte Bibliotheken, die derzeit im Trend liegen: Vue.js und React. React wäre eine naheliegende Wahl, da es bereits von Gutenberg verwendet wird. Für jemanden, der neu in modernem JavaScript ist, könnte Vue.js jedoch besser sein, um damit zu beginnen.

React wirft Sie ins kalte Wasser, indem es ES6-Funktionen, -Klassen, die proprietäre JSX-Syntax und die Webpack-Build-Pipeline sofort verwendet. Die Lernkurve ist ziemlich steil.

Vue.js hingegen ist viel anfängerfreundlicher und kann verwendet werden, indem einfach ein <script> -Tag eingefügt wird. Vue.js verwendet einfaches JavaScript (ES5), HTML und CSS. Die Einführung in neue Konzepte erfolgt viel schrittweiser.

Nachdem Sie einige Vue.js-Projekte durchgearbeitet haben, sind Sie besser darauf vorbereitet, tief in React einzutauchen. Nicht, dass es immer notwendig wäre, aber die Entwicklung von Gutenberg zum Beispiel erfordert es.

Verwenden Sie die WordPress-REST-API

Die REST-API von WordPress ist nur eine standardisierte Schnittstelle für die Remote-Anforderung und -Änderung von Daten von WordPress. Es ist eher eine Sache der Softwarearchitektur als eine völlig andere Art des Codierens. Dieselben alten jQuery-AJAX-Snippets könnten mit etwas anderen Parametern verwendet werden.

Der wichtigste Vorteil? Da die WordPress-REST-API die Kommunikation zwischen Backend und Frontend standardisiert, ist dies ein großer Schritt in Richtung Modularität, Wiederverwendbarkeit und Lesbarkeit in Ihrem Code. Diese schrecklichen Templates mit HTML und PHP gemischt und etwas SQL, das in die Mischung geworfen wird, müssen weg. Sobald Vorlagen nur HTML mit Platzhaltern für Daten sind, die als Parameter übergeben werden, gibt es keinen großen Unterschied zwischen der Übergabe dieser Daten in PHP oder über eine REST-API an eine Front-End-App.

Vielleicht möchten Sie sich auch WPGraphQL ansehen. Es kann die WordPress REST API ersetzen oder auch nicht, aber es gewinnt schnell an Zugkraft.

Lernen Sie Gutenberg (Kunden werden es bald benötigen)

Das ultimative Ziel von Gutenberg ist unter anderem die vollständige Anpassung der Website.

Dies legt den Grundstein für ein neues Modell für WordPress Core, das sich letztendlich auf die gesamte Veröffentlichungserfahrung der Plattform auswirken wird.

Die WordPress Gutenberg-Projektseite auf GitHub

Gutenberg erhielt großen Widerstand von WordPress-Entwicklern. Einige der Argumente gegen die Zusammenführung mit dem WordPress-Kern waren:

  • Ein erheblicher Teil der Endbenutzer benötigt es nicht, daher sollte es ein optionales Plugin und nicht Teil des Kerns sein
  • Es brach einige Websites
  • Es war einfach noch nicht fertig und könnte mehr Feinschliff und weniger Bugs gebrauchen

Für Autoren von Inhalten, die WordPress als Blogging-Plattform verwenden, bietet Gutenberg jedoch eindeutig eine bessere Erfahrung als der alte Editor.

Das Deaktivieren von Gutenberg wird unterstützt, solange es benötigt wird, ja. Aber es ist eine kluge Idee, sich jetzt darauf einzulassen: Wenn ein Kunde auf Sie zukommt und Sie um eine Gutenberg-Entwicklung bittet, sind Sie bereit.

Zeit, auf den neuesten Stand zu kommen: Auch der „WordPress-Weg“ entwickelt sich weiter

Das häufigste Argument gegen die Verwendung all der oben beschriebenen Tools und Techniken in der WordPress-Entwicklung ist folgendes: Der „WordPress-Weg“ funktioniert immer noch, und dieser Weg soll besser sein als all diese neuen glänzenden Dinge.

Aber Sie haben jetzt gesehen, dass die Entwickler des WordPress-Kerns über alle neuesten Entwicklungen informiert sind. Nicht nur das, sie verwenden sie wegen ihrer offensichtlichen Vorteile so oft wie möglich in neueren Teilen des Kerns. Das einzige, was uns zurückhält, ist der alte Code, den niemand umgestalten wird.

Seit einiger Zeit verfolgen WordPress und WooCommerce die Praxis, „Feature-Plugins“ zu entwickeln, die neue Technologien implementieren und nutzen. Wenn die Zeit reif ist, werden diese Plugins in den Kern integriert, wie es Gutenberg getan hat. WooCommerce hat auch ein eigenes React-Projekt. Die WordPress-REST-API startete ebenfalls als separates Plugin und ist jetzt Teil des WordPress-Kerns.

Die Frage ist nicht, ob wir Neues lernen und in meinem Arbeitsalltag anwenden sollen, sondern wie . Die Antwort lautet „allmählich“, Schritt für Schritt. Lernen Sie entweder etwas Neues oder tun Sie etwas, das Sie gut kennen, auf eine neue und andere Art und Weise.

Erfahren Sie beispielsweise, wie Sie Webpack mit all Ihren alten Skripten verwenden. Webpack kann Ihren neuen ES6+-Code in „einfaches“ JavaScript transpilieren, das mit älteren Browsern kompatibel ist. Es kann auch Skripte verkleinern und bündeln. Das ist eine neue Sache. Getan? Schreiben Sie dann Ihr JavaScript neu, indem Sie ES6-Funktionen nutzen. Es ist eine neue Art, das zu tun, was Sie gut kennen.

Das Ergebnis: Sie lernen Webpack und ES6 kennen. Als Profis sollten wir aufsteigen und nicht zurücktreten. Lernen Sie immer weiter. Und teilen Sie, wenn Sie dies tun: Toptal führt eine Liste mit Best Practices für die WordPress-Entwicklung und begrüßt Community-Beiträge dazu.

In Teil 2 unserer Serie tauchen wir in den PHP-Teil der modernen WordPress-Backend-Entwicklung ein.