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

Veröffentlicht: 2022-03-11

WordPress ist die am weitesten verbreitete Site-Technologie der Welt und das aus gutem Grund. Doch Legacy-Code ist in seinem Kern ein Durcheinander, und dieses Problem überträgt sich auf Drittentwickler. Einige Entwickler nehmen dies als Vorwand, um in ihrem eigenen WordPress-PHP-Code Abstriche zu machen, aber dieser Ansatz ist auf lange Sicht für alle außer den trivialsten Änderungen teurer.

In Teil 1 unserer zweiteiligen Serie haben wir uns auf allgemeine Projekt- und Workflow-Tools konzentriert, gefolgt von der Front-End-Entwicklung. Jetzt ist es an der Zeit, den Stier bei den Hörnern zu packen und mit PHP zu ringen: Insbesondere, wie man Best Practices bei der Arbeit mit Back-End-WordPress-Code befolgt. Sie können sich dies als ein PHP/WordPress-Tutorial vorstellen, aber etwas fortgeschrittener, mit der Annahme, dass Sie bereits einige WordPress-Backend-Anpassungen vorgenommen haben.

Also, welche modernen Software-Designprinzipien und PHP-Funktionen bieten Ihnen den besten Wert für Ihre Zeit? Im Folgenden sind 10 WordPress- und PHP-Entwicklungspraktiken aufgeführt, die ich sehr empfehle.

Best Practice Nr. 1 für die moderne WordPress-Entwicklung: „Separation of Concerns“ befolgen

Trennung von Bedenken bedeutet, dass Teile des WordPress-PHP-Codes mit unterschiedlichen Funktionen oder Zwecken nicht miteinander vermischt werden sollten. Stattdessen sollten sie in getrennten Abschnitten oder Modulen organisiert sein und Daten über eine definierte Schnittstelle aneinander übergeben. (Eine Schnittstelle ist ein Satz definierter Parameter, die ein Modul als Eingabe nimmt und was es zurückgibt.) Ein eng verwandter Begriff ist das Single-Responsibility-Prinzip : Jedes Codemodul (oder jede Funktion) sollte nur für eine Sache verantwortlich sein.

Das ultimative Ziel bei der Befolgung dieser Prinzipien ist die Erstellung von Code, der modular und somit wartbar, erweiterbar und wiederverwendbar ist.

Das war ein ziemlicher Schluck, also schauen wir uns ein Beispiel für WordPress PHP (aus dem WordPress-Kern) an, das alles durcheinander bringt. Dieser Codierungsstil wird oft als „Spaghetti-Code“ bezeichnet, da es fast unmöglich ist, sein Innenleben zu verstehen. Der folgende Auszug wurde der Kürze halber redigiert; Der ursprüngliche Stil und die Formatierung wurden jedoch beibehalten.

 $id = isset( $_REQUEST['id'] ) ? intval( $_REQUEST['id'] ) : 0; <table class="form-table"> <?php $blog_prefix = $wpdb->get_blog_prefix( $id ); $sql = "SELECT * FROM {$blog_prefix}options WHERE option_name NOT LIKE %s AND option_name NOT LIKE %s"; $query = $wpdb->prepare( $sql, $wpdb->esc_like( '_' ) . '%', '%' . $wpdb->esc_like( 'user_roles' ) ); $options = $wpdb->get_results( $query ); foreach ( $options as $option ) { if ( strpos( $option->option_value, "\n" ) === false ) { ?> <tr class="form-field"> <th scope="row"><label for="<?php echo esc_attr( $option->option_name ); ?>"><?php echo esc_html( ucwords( str_replace( '_', ' ', $option->option_name ) ) ); ?></label></th> <?php if ( $is_main_site && in_array( $option->option_name, array( 'siteurl', 'home' ) ) ) { ?> <td><code><?php echo esc_html( $option->option_value ); ?></code></td> <?php } else { ?> <td><input class="<?php echo $class; ?>" name="option[<?php echo esc_attr( $option->option_name ); ?>]" type="text" value="<?php echo esc_attr( $option->option_value ); ?>" size="40" <?php disabled( $disabled ); ?> /></td> <?php } ?> </tr> <?php } } // End foreach </table>

Erstens ist es völlig unverständlich. Und ich finde es toll, dass der einzige Kommentar End foreach ist, was völlig überflüssig ist. Wir haben Datenbankabfragen, die Verarbeitung von Abfrageergebnissen, zusätzliche in HTML eingebettete Verarbeitung (es gibt dort ein if / else , wenn Sie es nicht bemerkt haben), Ausgabe-Escapezeichen und HTML-Vorlagen, die alle zusammengemischt sind. Ein weiteres Problem ist, dass der $id Parameter direkt aus dem globalen $_REQUEST kommt, anstatt einen tatsächlichen Parameter an eine Funktion zu übergeben.

Wenn man sich das ansieht, ist es vollkommen verständlich, warum der WordPress-Kern seit Jahren größtenteils gleich geblieben ist. Das Refactoring dieser Art von Code – insbesondere unter Beibehaltung des bestehenden Verhaltens – ist eine wirklich epische Aufgabe, die niemand machen möchte.

Wie machen wir es also richtig? Nun, eine Sache, an die man sich erinnern sollte, ist, dass es nicht den einen wahren Weg gibt. Wir haben die oben genannten Eigenschaften erwähnt, nach denen wir streben sollten: Wir brauchen benutzerdefinierten WordPress-PHP-Code, um wartbar und modular zu sein. Schauen wir uns an, wie wir den obigen Code in Module aufteilen können.

  • SQL-Abfragen sollten natürlich in einem separaten Modul sein. WordPress hat bereits eine schön abstrahierte WP_Query -Klasse, die als Beispiel verwendet werden sollte.
  • Alle HTML geht in eine Vorlage. Wir werden weiter unten auf PHP-Templates eingehen.
  • Der restliche PHP-Code sollte in eine Funktion verpackt werden – mehrere Funktionen, wenn der Code für eine Funktion zu lang oder zu komplex ist. Parameter wie $id werden über Funktionsargumente übergeben.

Dies ist eine stark vereinfachte Umschreibung des obigen Beispiels:

 function betterSiteSettings($args) { $data = WP_Settings_Query($args); // process $data here $context = array_merge([], $data_processed, $other_data); return Template::render('template.name', $context); }

Best Practice Nr. 2 für die moderne WordPress-Entwicklung: Vermeiden Sie globale Variablen

WordPress hat viel zu viele globale Variablen. Warum sind globale Variablen schlecht? Sie machen es schwer, Ihrem WordPress-PHP-Code zu folgen, und machen den Anwendungsstatus unzuverlässig. Jeder PHP-Code – und das bedeutet jedes in WordPress installierte Plugin – kann globale Variablen lesen und schreiben, daher gibt es keine Garantie dafür, dass sie gültige Daten enthalten. Zu versuchen zu verstehen, welche globalen Variablen in so etwas wie der Schleife verwendet werden, ist ebenfalls keine triviale Aufgabe.

Betrachten wir dies aus einem praktischen Blickwinkel. Dieses Beispiel stammt von WooCommerce. Wahrscheinlich weiß jeder WordPress-Entwickler, was es ist – der Loop:

 <?php while ( have_posts() ) : the_post(); ?> <?php wc_get_template_part( 'content', 'single-product' ); ?> <?php endwhile; // end of the loop. ?>

Das obige Snippet rendert eine Produktvorlage. Woher weiß es, welches Produkt angezeigt werden soll, wenn keine Parameter an wc_get_template_part ? Wenn wir uns die Vorlage ansehen, sehen wir, dass sie mit global $product; , also wird dort das aktuelle Produktobjekt gespeichert.

Stellen Sie sich nun vor, wir haben eine Katalogseite, die Produkte sucht und filtert, und wir möchten ein „Produktdetails“-Popup anzeigen, während wir auf derselben Seite bleiben. Hinter den Kulissen führt das Front-End-Skript eine AJAX-Anfrage aus, um diese bestimmte Produktvorlage abzurufen. Wir können wc_get_template_part('content', 'single-product') nicht einfach aufrufen, weil es keine Parameter verwendet, also müssen wir ein paar globale Variablen setzen, damit das funktioniert.

Komplexere Anwendungsfälle würden mehr als eine Vorlage beinhalten, in diesen Vorlagen ausgelöste Hooks und Plugins von Drittanbietern, die ihre Callbacks zu diesen Hooks hinzufügen. Es kann schnell eskalieren. Wir haben keine Möglichkeit zu wissen, auf welchem ​​globalen Zustand diese Rückrufe beruhen. Plugins von Drittanbietern können beliebige globale Variablen in ihren Callbacks ändern. Anstatt das System zu verwenden, fangen wir an, mit dem System zu kämpfen und stoßen auf seltsame Fehler, die von einem unzuverlässigen globalen Zustand herrühren.

Wäre es nicht sinnvoller, diese Produkt-ID als Parameter zu übergeben? Dann könnten wir diese Vorlage wiederverwenden, ohne uns Sorgen machen zu müssen, dass die von WordPress verwendeten globalen Variablen durcheinander gebracht werden.

Best Practice Nr. 3 für die moderne WordPress-Entwicklung: Objektorientierte Programmierung (OOP) verwenden

Modularität führt zum Konzept der Objekte und der objektorientierten Programmierung. Auf der sehr grundlegenden Ebene ist OOP eine Möglichkeit, Code zu organisieren. Funktionen und Variablen werden zu Klassen gebündelt und heißen Klassenmethoden bzw. Eigenschaften . Das WordPress-Plugin-Handbuch empfiehlt die Verwendung von OOP zum Organisieren Ihres benutzerdefinierten WordPress-PHP-Codes.

Ein wichtiges Prinzip in OOP ist die Beschränkung des Zugriffs auf Methoden und Eigenschaften – oder in PHP-Begriffen, sie als private oder protected zu bezeichnen –, sodass nur andere Klassenmethoden darauf zugreifen und sie ändern können. Ein OOP-Begriff dafür ist Kapselung : Daten werden innerhalb der Klasse gekapselt, und die einzige Möglichkeit, diese Daten zu ändern, besteht darin, bereitgestellte Klassenmethoden zu verwenden.

Dies macht das Debuggen und Verwalten Ihres Codes viel einfacher als bei der Verwendung globaler Variablen, die überall in der gesamten Codebasis geändert werden können. Betrachten Sie die globale post -Variable von WordPress. Sie können überall in Ihrem Code darauf zugreifen, und viele Funktionen hängen von seiner Verwendung ab. Was wäre, wenn Sie Änderungen nur auf WordPress-Kernfunktionen beschränken könnten, aber das Lesen für jeden erlaubt wäre? Das Verstecken oder Kapseln der globalen post -Variablen in einer Klasse und das Erstellen einer Schnittstelle um sie herum würde dies ermöglichen.

Dies ist nur eine sehr grundlegende Beschreibung von OOP und wie es in der modernen WordPress-Entwicklung verwendet werden kann. Zum weiteren Studium empfehle ich Carl Alexanders E-Book „Entdecken Sie die objektorientierte Programmierung mit WordPress“, das den umfassendsten und nützlichsten Inhalt zum Thema OOP in WordPress enthält.

Es ist wichtig, sich daran zu erinnern, dass OOP keine Wunderwaffe ist: Schlechter Code kann mit OOP so einfach geschrieben werden wie mit jedem anderen Programmierparadigma.

Lassen Sie uns in einige spezifische Ratschläge zur Verwendung von PHP für die WordPress-Entwicklung eintauchen.

Best Practice Nr. 1 für modernes PHP: Zielen Sie auf PHP 7.0+ ab

Die Verwendung moderner PHP-Funktionen erfordert, nun ja, eine moderne Version von PHP. Es gibt einfach keinen Grund, PHP-Versionen kleiner als 7.0 zu unterstützen. Auch der WordPress-Core wird bereits Ende 2019 PHP 7.0 benötigen.

Dennoch ist es eine gute Praxis, nach Ihrer Mindestversion zu suchen, um den „weißen Bildschirm des Todes“ in inkompatiblen Umgebungen zu vermeiden. Das folgende Snippet zeigt die Verwendung eines Plugin-Headers, um eine minimale PHP-Version mit einer Guard-Bedingung im Code zu deklarieren.

 <?php /** * Plugin Name: My Awesome Plugin * Requires PHP: 7.0 */ // bails if PHP version is lower than required if (version_compare(PHP_VERSION, '7.0.0', '<')) { // add admin notice here return; } // the rest of the actual plugin here

Modern PHP Best Practice Nr. 2: Übernahme von PHP-Industriestandards (PSR-2 Coding Style Guide)

PSRs sind Empfehlungen, die von der PHP Framework Interop Group veröffentlicht werden. Sie sind die De-facto-Industriestandards in jedem modernen PHP-Workflow, und es kann mit Sicherheit gesagt werden, dass die PHP-Community als Ganzes diesen Standards folgt. PSR-2 ist eine Empfehlung, die den Codierungsstil beschreibt. Beliebte PHP-Frameworks wie Symfony und Laravel folgen PSR-2.

Warum sollten Sie PSR-2 anstelle des WordPress-Codierungsstandards verwenden? Hauptsächlich, weil WordPress-Standards veraltet sind und keine der neueren Sprachfunktionen verwenden. Das ist verständlich, denn der WordPress-Kern muss seinen eigenen Standards folgen. Bis vor kurzem musste es PHP 5.2 unterstützen, und PSR-2 ist nicht mit PHP 5.2 kompatibel.

Es mag nicht offensichtlich sein, aber es ist nicht erforderlich, WordPress-Codierungsstandards zu verwenden, es sei denn, Sie verpflichten sich zum Kern. Es wäre kein Problem, ein Plugin, das dem PSR-2-Standard folgt, in das WordPress-Plugin-Verzeichnis einzureichen. Tatsächlich gibt es einige sehr gute Argumente dafür.

Modern PHP Best Practice Nr. 3: Verwenden Sie eine PHP-Template-Engine

PHP ist keine Template-Engine. Es begann als eine, entwickelte sich dann aber zu einer voll funktionsfähigen Programmiersprache, und es gibt keinen Grund, sie weiterhin für die Erstellung von Vorlagen zu verwenden. Die beiden beliebtesten Template-Engines für PHP sind Twig und Blade, die von Symfony bzw. Laravel verwendet werden. In diesem Artikel wird Twig als Beispiel für eine Templating-Engine verwendet. Blade hat jedoch vergleichbare Merkmale und Funktionen. Ich bitte Sie, sich beide anzusehen und selbst zu entscheiden, was am besten zu Ihnen passt.

Das folgende Beispiel vergleicht eine PHP-Vorlage und die entsprechende Twig-Vorlage. Das Anzeigen und Escapen der Ausgabe ist im PHP-Beispiel besonders ausführlich:

 foreach ( $options as $option ) { ?> <tr class="form-field"> <th scope="row"> <label for="<?php echo esc_attr( $option->option_name ); ?>"> <?php echo esc_html( strtolower( $option->option_name ) ); ?> </label> </th> </tr> <?php } // End foreach

In Twig ist dies prägnanter und lesbarer:

 {% for option in options %} <tr class="form-field"> <th scope="row"> <label for="{{ option.option_name }}"> {{ option.option_name }} </label> </th> </tr> {% endfor %}

Die Hauptvorteile von Twig sind:

  • Lesbare und prägnante Syntax
  • Automatisches Ausgabe-Escape
  • Vorlagenerweiterung durch Vererbung und Blöcke

In Bezug auf die Leistung kompiliert Twig in PHP-Vorlagen und hat praktisch keinen Overhead. Twig hat nur eine Teilmenge von PHP-Sprachkonstrukten, die nur auf Templating beschränkt sind. Dies zwingt Entwickler dazu, Geschäftslogik aus Vorlagen zu entfernen, wodurch die Trennung von Bedenken erzwungen wird.

Es gibt sogar Twig für WordPress. Es heißt Timber und ist eine großartige Möglichkeit, mit der Erstellung besserer Vorlagen zu beginnen. Das Timber-Starterthema ist ein perfektes Beispiel für die Organisation von Themen auf OOP-Weise.

Modern PHP Best Practice Nr. 4: Verwenden Sie Composer

Composer ist ein Abhängigkeitsmanager für PHP. Es ist ein Tool, das es ermöglicht, Bibliotheken zu deklarieren, die ein Projekt verwendet, und dann ihre Downloads, Installationen und Updates zu automatisieren. Dann brauchen Sie nur noch die Autoload-Datei von Composer ' vendor/autoload.php ' einzufügen, anstatt jede Bibliothek manuell anzufordern.

WordPress-Plugins und -Themes verwenden nicht oft Bibliotheken von Drittanbietern. Das liegt zum Teil daran, dass WordPress über eine umfangreiche API verfügt, die fast alle Anforderungen erfüllt, und zum Teil an möglichen Versionskonflikten. Stellen Sie sich zwei Plugins vor, die dieselbe PHP-Bibliothek, aber unterschiedliche Versionen davon erfordern. Das zuerst ausgeführte Plugin erhält die richtige Version und das zweite Plugin erhält diese Version ebenfalls. Dies ist möglicherweise eine weitere White-Screen-of-Death-Situation.

Um Konflikte zu vermeiden, sollte das Abhängigkeitsmanagement auf Anwendungsebene, also auf der gesamten WordPress-Seite, eingesetzt werden. Dies ist, was Roots (genauer gesagt Bedrock) tut. Bei Verwendung auf Paketebene (Plugin oder Design) kann Composer Konflikte verursachen, wenn Bibliotheken von Drittanbietern verwendet werden. Es ist ein bekanntes Problem. Die einzige Lösung, die es bisher gibt, besteht darin, die Namespaces dieser externen Bibliothek in etwas Einzigartiges umzubenennen, und das ist keine triviale Aufgabe.

Es gibt jedoch immer noch einen Nutzen für Composer: das automatische Laden Ihrer eigenen Klassen. Aber bevor wir mit dem automatischen Laden fortfahren, müssen wir uns mit PHP-Namespaces vertraut machen.

Modern PHP Best Practice Nr. 5: Verwenden Sie Namespaces

Da der WordPress-Kern ein Legacy-Projekt ist, verwendet er einen globalen Namensraum oder, anders gesagt, überhaupt keinen Namensraum. Alle global deklarierten Klassen oder Funktionen (d. h. nicht innerhalb einer anderen Klasse oder Funktion) sind überall in der gesamten Codebasis sichtbar. Ihre Namen müssen nicht nur innerhalb Ihrer Codebasis eindeutig sein, sondern für alle Plugins und Themes, die jetzt oder in Zukunft verwendet werden.

Eine Namenskollision (z. B. das Deklarieren einer Funktion mit einem bereits existierenden Namen) führt normalerweise zum White Screen of Death, und das wollen wir nicht. Der WordPress-Codex empfiehlt, all Ihren Funktionen und Klassen etwas Einzigartiges voranzustellen. Anstatt also einfache Klassennamen wie Order zu haben, erhalten wir so etwas wie Akrte_Awesome_Plugin_Order , wobei „Akrte“ das eindeutige Präfix ist, das ich mir gerade ausgedacht habe.

Namespaces können als Gruppen betrachtet werden – oder Ordner, wenn wir eine Dateisystem-Analogie verwenden – die dabei helfen, Code zu organisieren und Namenskollisionen zu vermeiden. Sie können komplexe Namespaces haben, die durch einen Schrägstrich getrennt sind, genau wie verschachtelte Ordner. (PHP-Namespaces verwenden insbesondere einen Backslash.)

Diese Namespace-Teile werden als Sub-Namespaces bezeichnet. Unsere Beispielklasse Akrte_Awesome_Plugin_Order wäre Akrte\Awesome_Plugin\Order , wenn sie Namespaces verwendet. Hier sind Akrte und Awesome_Plugin Namespace-Teile (oder Sub-Namespaces) und Order ist der Klassenname. Dann können Sie eine use -Anweisung hinzufügen und danach nur noch den Klassennamen verwenden. Das sieht auf jeden Fall besser aus:

 use Akrte\Awesome_Plugin\Order; $a = new Order;

Offensichtlich sollten Namensräume eindeutig sein; Daher sollten wir dem ersten „Root“-Unternamensraum einen eindeutigen Namen geben, und das ist normalerweise ein Herstellername. Als Beispiel könnte die WooCommerce-Klasse WC_REST_Order_Notes_V2_Controller mit Namespaces wie diesem neu erstellt werden:

 namespace WooCommerce\RestApi\V2\Controllers; class OrderNotes {}

Die WooCommerce-Codebasis verwendet heutzutage Namespaces; zum Beispiel in der WooCommerce REST API Version 4.

Modern PHP Best Practice Nr. 6: Verwenden Sie einen Autoloader

In den meisten PHP-Workflows werden PHP-Dateien normalerweise mithilfe von require oder include -Anweisungen verknüpft. Wenn ein Projekt wächst, erhalten Sie Dutzende von require -Anweisungen in Ihrer Haupt-Plugin-Datei. Ein Autoloader automatisiert das Einschließen von Dateien und tut dies nur bei Bedarf. Technisch gesehen ist es eine Funktion, require , die eine Klasse oder eine Funktion enthält, wenn sie zum ersten Mal im Code auftritt. Es ist nicht mehr erforderlich, require Anweisungen manuell hinzuzufügen.

Oft ergibt sich auch ein deutlicher Performance-Gewinn, da ein Autoloader nur Module lädt, die in einer bestimmten Anfrage verwendet werden. Ohne einen Autoloader ist Ihre gesamte Codebasis enthalten, selbst wenn eine Anfrage beispielsweise nur 10 Prozent Ihres Codes verwendet.

Eine Autoloader-Funktion muss wissen, in welchen Dateien sich Ihre Klassen und Funktionen befinden. Und dafür gibt es einen PHP-FIG-Standard, PSR-4.

Es besagt, dass ein Teil eines Namensraums, das Präfix, einem Basisordner entsprechen soll. Die darauffolgenden untergeordneten Namensräume entsprechen Ordnern innerhalb des Basisordners. Schließlich entspricht der Klassenname dem Dateinamen. Eine Beispielklasse Akrte\AwesomePlugin\Models\Order würde die folgende Ordnerstruktur benötigen:

 /awesome-plugin awesome-plugin.php /includes /Models Order.php

Das Namespace-Präfix Akrte\AwesomePlugin\ entspricht dem Ordner " includes ", wie in der unten beschriebenen Autoloader-Konfiguration angegeben. Der Models -Unternamensraum hat einen entsprechenden Models -Ordner, und die Order -Klasse ist in Order.php enthalten.

Glücklicherweise müssen Sie keine Autoloader-Funktion selbst implementieren. Composer kann einen Autoloader für Sie erstellen:

  1. Composer installieren
  2. Erstellen Sie eine composer.json -Datei im Stammordner Ihres Projekts. Es sollte diese Zeilen enthalten:
 { "name": "vendor-name/plugin-name", "require": {}, "autoload": { "psr-4": { "Akrte\\AwesomePlugin\\": "includes/" } } }
  1. Führen Sie composer install .
  2. Integrieren Sie vendor/autoload.php oben in Ihre Haupt-Plugin-PHP-Datei wie folgt:
 <?php /** * Plugin Name: My Awesome Plugin */ defined('ABSPATH') || exit; require __DIR__ . '/vendor/autoload.php'; // do stuff

Neben Namensräumen verwendet die neueste Codebasis von WooCommerce auch einen Composer-Autoloader.

Nachdem diese PHP-Designprinzipien behandelt wurden, ist es an der Zeit, alle unsere PHP-Lektionen mit einer letzten Empfehlung an die WordPress-Backend-Anpassung zu binden.

Best Practice Nr. 4 für die moderne WordPress-Entwicklung: Erwägen Sie die Verwendung des Roots-Stacks

Roots ist der umfassendste moderne WordPress-Entwicklungsworkflow, den es gibt. Allerdings würde ich sagen, dass es nicht unbedingt in jedem WordPress-Projekt verwendet werden sollte, denn:

  • Roots müssen von Anfang an verwendet werden. Der häufigste Grund, wirklich. Das Refactoring eines bestehenden Projekts wäre zu kostspielig.
  • Es ist rechthaberisch. Gut, wenn Sie zustimmen, schlecht, wenn Sie es nicht tun. Möglicherweise bevorzugen Sie beispielsweise andere Möglichkeiten, Ihr Thema zu organisieren. Meinungsstarke Projekte brauchen auch Zeit, um „ihren Weg“ zu lernen.
  • Nicht jeder kennt es. Der Entwickler, der nach Ihnen kommt, um die Website zu warten, die Sie mit dem Roots-Stack erstellt haben, hat möglicherweise keine Ahnung, was es ist, und fragt sich, was mit WordPress-Ordnern passiert ist. Wir sollten an unsere WordPress-Entwicklerkollegen denken.

Im Allgemeinen sollten Sie alle Vor- und Nachteile eines stark eigensinnigen Projekts vollständig verstehen, bevor Sie sich dazu verpflichten, es zu verwenden.

Moderne PHP- und Software-Prinzipien: Die WordPress-Backend-Entwicklung robust machen

Es ist ziemlich offensichtlich, dass es nicht den einen wahren Weg gibt, Software zu schreiben. Die Konzepte, wie die Trennung von Anliegen, sind Jahrzehnte alt; Was es praktisch bedeutet, war jedoch immer umstritten. Nehmen wir zum Beispiel CSS. Am Anfang haben wir es als style in HTML eingebunden, dann entschieden wir, dass separate CSS-Blätter das sind, worum es bei der Trennung von Anliegen geht.

Ein Jahrzehnt vorspulen: Heutige JavaScript-Apps verwenden Komponenten als eine Separation-of-Concerns-Implementierung. Front-End-Entwickler tendieren zu CSS-in-JS, und das bedeutet im Grunde wieder, CSS in HTML einzubetten (na ja, so einfach ist es nicht, aber Sie verstehen schon). Der Kreis schließt sich!

Bei Best Practices ging es schon immer darum, das Entwicklererlebnis zu verbessern:

Programme müssen geschrieben werden, damit Menschen sie lesen können, und nur nebenbei, damit Maschinen sie ausführen können.

Abelson & Sussman, Struktur und Interpretation von Computerprogrammen

Einige der Praktiken in diesem PHP-WordPress-Tutorial lassen sich schnell und einfach in Ihrem Projekt implementieren. Zum Beispiel Autoloader: Mach es einmal pro Projekt und genieße es einfach. Auf der anderen Seite brauchen neue Softwarearchitekturideen Zeit, Übung und zahlreiche Iterationen, um praktisch und komfortabel zu werden. Die Belohnungen sind jedoch viel größer. Sie werden nicht nur effizienter bei dem, was Sie tun, sondern auch mehr Freude an dem haben, was Sie tun. Und regelmäßige Freude an der Arbeit, die Sie für Kunden leisten, ist vielleicht der einzige Weg, wie sie nachhaltig sein kann.