Verwaltbare WordPress-Themes schreiben Namenskonventionen

Im ersten Beitrag dieser Serie haben wir einige der Strategien beschrieben, die verfügbar sind, wenn es darum geht, unsere WordPress-Theme-Verzeichnisse zu organisieren, um sie wartungsfreundlicher zu machen.

Konkret haben wir angesprochen, wie man sich organisiert:

  1. JavaScript- und CSS-Dateien
  2. Vorlagen und Vorlagenteile
  3. Übersetzungen
  4. Hilfsdateien und Hilfsprogrammfunktionen
  5. Drittanbieter-Bibliotheken

Letztendlich bestand das Ziel darin, ein Verzeichnisschema bereitzustellen, in dem wir unsere Dateien so organisieren können, dass wir für die von uns geleistete Arbeit ein gewisses Maß an Zusammenhalt, Verständnis und Wartbarkeit haben.

Aber das ist noch nicht alles, um wartbare WordPress-Themes zu schreiben. Eine andere ist, den Konventionen der WordPress-Codierungsstandards zu folgen; Dieser Artikel wird sich jedoch nicht mit den Standards befassen. Der Codex macht das gut und wir haben sie in einer anderen Serie behandelt.

Stattdessen betrachten wir einige der Strategien und Tools, die wir verwenden können, um ein wenig detaillierter zu sein, um sicherzustellen, dass wir unsere Themen so wartungsfähig wie möglich gestalten. In diesem speziellen Beitrag werden wir uns die Strategien anschauen und dann die Serie mit einigen der verfügbaren Tools abschließen.

Wartungsfreundlichkeit steigern

Wie bereits erwähnt, ist es eine Sache, einen logischen Weg zu haben, um alle Verzeichnisse, Dateien und Bibliotheken zu organisieren, aus denen sich Ihr Design zusammensetzt. Dies ist jedoch nur die Hälfte von dem, was zur Konstruktion eines Themas benötigt wird.

Schließlich gibt es vordefinierte Vorlagen, Funktionen, Namenskonventionen und Tools, die alle dazu beitragen, entweder das Thema zusammenzustellen oder das Thema zu testen, um sicherzustellen, dass es keine veralteten API-Aufrufe verwendet und mit der neuesten Version kompatibel ist von WordPress.

Ich denke, es ist wichtig, jedes dieser Themen zu verstehen, sowohl als jemanden, der gerade mit dem Erstellen von WordPress-Themes beginnt, als auch als jemand, der es schon seit einiger Zeit macht.

Immerhin gibt es keine bessere Zeit, um sich zu verbessern. Darüber hinaus sind die Kommentare auch ein großartiger Ort, um die Diskussion fortzusetzen und alternative Ideen auszutauschen.

Aber bevor wir dort ankommen, wollen wir eigentlich über einige praktische Dinge sprechen, die wir tun können, wenn es um WordPress-Themes geht, und das erhöht die Wartungsfreundlichkeit unserer Aktivitäten.

Vorlagen

Wenn Sie nicht mit der Vorlagenhierarchie vertraut sind, sollten Sie zuerst die entsprechende Codex-Seite lesen, bevor Sie mit diesem Artikel fortfahren.

Kurz gesagt, Vorlagen können wie folgt beschrieben werden:

WordPress-Vorlagen fügen sich wie Puzzleteile zusammen, um die Webseiten auf Ihrer WordPress-Site zu erstellen. Einige Vorlagen (zum Beispiel Kopf- und Fußzeilen-Vorlagendateien) werden auf allen Webseiten verwendet, während andere nur unter bestimmten Bedingungen verwendet werden.

Eine andere Denkweise ist folgende: Wenn es sich um WordPress handelt, stammt alles, was dem Benutzer angezeigt wird, aus der Datenbank. Dazu gehören der Posttitel, die Postdaten, die Postkategorien, der Postinhalt, die Kommentare usw..

Vorlagen sind die Fahrzeuge, durch die die Informationen dem Benutzer präsentiert werden. Sie bestehen aus Markup und PHP, die über CSS gestaltet wurden, und können durch die Verwendung von JavaScript einige Auswirkungen haben.

Vorausgesetzt, Sie machen keine fortgeschrittenen Dinge mit benutzerdefinierten Post-Typen und / oder benutzerdefinierten Taxonomien (eigentlich ein Thema für einen anderen Post), dann gibt es eine einzigartige Sache in der WordPress-Vorlagenhierarchie, die als Luxus und als Luxus dient ein Wartungsproblem, je nachdem, wie Sie es betrachten.

Beachten Sie, dass WordPress im verknüpften Codex-Artikel einen Standardwert hat index.php, header.php, und footer.php Vorlagen. Die Wahrheit ist, dass Sie mit dem Erstellen eines gesamten WordPress-Themes wirklich fertig werden können nur index.php.

Klingt irgendwie attraktiv, richtig? Ich meine, wer muss so viele verschiedene Dateien erstellen, wenn Sie ein schönes, kleines, schlankes Design erstellen können, das alles tut, was Sie brauchen.

Aber denken Sie dann darüber nach, wenn Sie mit einem Team von Kollegen oder Kollegen zusammenarbeiten, die möglicherweise zu einem offenen Repository beitragen, oder mit denen, die möglicherweise aufholen, wo Sie aufgehört haben.

Wenn der gesamte zum Rendern von Informationen aus der Datenbank erforderliche Code in einer einzigen Datei enthalten ist, ist die Wahrscheinlichkeit sehr groß, dass die Komplexität dieser Datei von ihrer Erstellung an steigt.

Grundsätzlich betrachten wir eine einzelne Datei mit einer Reihe von Bedingungen, möglicherweise einigen Anweisungen zum Wechseln und so weiter. All dies geschieht, weil Sie die Archivseiten, die einzelnen Postseiten, die einzelnen Posts, die Hauptauflistung usw. berücksichtigen müssen.

Verstehst du, was ich meine?

Dann aber eine separate Datei erstellen gerade Diese Komplexität abzuschwächen kann ein Tier für sich sein. Nehmen wir zum Beispiel an, dass Sie dies getan haben single.php für die Anzeige eines einzelnen Beitrags und Sie haben page.php für die Anzeige einer Seite haben beide Vorlagen genau die gleichen Informationen außer single.php hat Post-Metadaten und page.php nicht.

Dies ist ein Paradebeispiel dafür, wie Sie Post-Meta-Daten in ihre eigenen Partialdaten extrahieren können, wie im vorherigen Artikel beschrieben. Oder Sie extrahieren vielleicht den Code, der für die Wiedergabe des Inhalts verantwortlich ist es ist eigenes partielles.

Was immer der Fall sein mag, der Punkt, den ich versuche zu machen, ist, dass ein Gleichgewicht gefunden werden muss, wenn es um das Arbeiten mit WordPress-Vorlagen und der WordPress-Vorlagenhierarchie geht.

Ich denke nicht, dass es eine gute Idee ist, eine minimale Anzahl von Vorlagen zu verwenden, aber ich denke auch nicht, dass es notwendig ist, jede einzelne unterstützte Vorlage zu verwenden ob Dies führt zu zu viel Code-Duplizierung. Dort ist ein Gleichgewicht zwischen Vorlagen und Teilstücken.

Letztendlich denke ich, dass die Erfahrung mit der Anwendung, die mit der Zeit einhergeht, aber diese Einstellung von Anfang an mit sich bringen kann, dazu beitragen kann, ein Maß an Organisation und Wartbarkeit zu bieten, das Ihrem Ziel einen großen Schritt voraus ist kann beginnen Sie nicht nur ein bisschen Vorplanung.

Benennungsfunktionen

Wenn Sie mit Funktionen und Namenskonventionen arbeiten, sind in der Regel zwei Daumenregeln zu beachten:

  1. Benennen Sie Ihre Funktionen eindeutig,
  2. Nennen Sie sie richtig, um anzugeben, was sie wollen Rückkehr Daten und was wird Echo Daten

Aber wenn Sie jemand sind, der gerade erst mit der Themenentwicklung beginnt, oder wenn Sie Ihre Fähigkeiten verbessern wollen, wie sieht das praktisch aus??

Wenn es um die eindeutige Benennung Ihrer Funktionen geht, sind die Gründe dafür, dass Sie nicht versehentlich mit einer bereits vorhandenen Funktion kollidieren, die in WordPress definiert ist, oder einem Plugin, das möglicherweise in Ihrer Umgebung ausgeführt wird.

Angenommen, Sie schreiben eine eigene Funktion, die den Inhalt filtert, bevor er auf die Seite gerendert wird. Der richtige Weg, dies zu tun, ist offensichtlich die Verwendung der add_filter Funktion; Würden Sie Ihrer Funktion jedoch einen Namen geben? der Inhalt?

Nein natürlich nicht. Der Grund ist, dass WordPress bereits definiert ist der Inhalt. Wenn Sie eine Funktion mit diesem Namen umbenennen, werden Fehler angezeigt. Zu diesem Zweck sollten Sie Ihren Funktionen immer einen eindeutigen Schlüssel voranstellen, z. B. den Namen Ihres Designs oder ähnliches.

Nehmen wir also an, wir möchten eine Signatur am Ende unseres Inhalts einfügen und sagen, dass wir ein Thema haben, das wir nennen Gipfel. Zu diesem Zweck empfehle ich die Erstellung einer Funktion namens acme_the_content da es den Namen des Designs und den Namen der Funktion angibt, an die es angehängt ist.

Nehmen wir an, Sie möchten jeden Beitrag mit Ihrem Namen und Twitter-Handle abschließen. Dazu können Sie dies in Ihrem definieren Functions.php Datei:

'; $ signature. = 'Tom | @tommcfarlin '; $ Signatur. = '

'; Rückgabe von $ content. = $ Signatur;

Es ist relativ einfach, nicht wahr? Das Kürze ist, dass ich versuche, das folgende Format zu verwenden, wenn ich meine eigenen Hook-Funktionen erstellt habe: theme_name-name_of_hook.

Dies macht es sehr einfach zu verstehen und zu folgen, nicht nur beim Durchsuchen des Codes, sondern auch beim Anzeigen der Funktionen, aus denen das Design oder die aktuell in Ihrer IDE aktive Datei besteht.

Rückgabe und Echo von Daten

Wie bereits erwähnt, hat WordPress eine andere Konvention, die es verwendet und die damit zusammenhängt, ob Informationen von der aufgerufenen Funktion zurückgegeben werden oder von der aufgerufenen Funktion zurückgegeben werden.

Zum Glück ist diese besondere Faustregel sehr leicht zu merken:

  • Funktionen, die Daten zurückgeben, sind mit einem Präfix versehen erhalten_
  • Funktionen, die Echo-Daten enthalten, sind nicht mit einem Präfix versehen erhalten_

Du wirst vielleicht finden etwas Anomalien, aber das ist der allgemeine Kern, wie die WordPress-API angibt, wie sie Ihnen die Daten zurückgibt, sobald Sie die Funktion aufgerufen haben.

Um unserem vorherigen Beispiel zu entsprechen, möchten wir, dass Sie die Daten beim Aufruf der Funktion wiederholen möchten. Dann würden Sie einfach aufrufen der Inhalt(); Wenn Sie jedoch den Inhalt aus einem Beitrag abrufen möchten, z. B. aus einer benutzerdefinierten Schleife, würden Sie ihn aufrufen get_the_content () und speichern Sie es in Ihrer eigenen Variablen.

Vielleicht so etwas: $ content_for_later = get_the_content (). Jetzt haben Sie die Daten für den Inhalt gelesen, der sich aktuell auf den aktiven Beitrag in The Loop bezieht, und Sie haben ihn in einer Variablen gespeichert, die Sie später verwenden können.

Aber zu wissen, wie WordPress seine Funktionen für Sie benennt, ist nur die Hälfte davon. Schließlich planen Sie die Erstellung eines Designs oder eines Plugins und möchten sicherstellen, dass Sie mit der "WordPress-Methode" übereinstimmen, wenn Sie die richtigen Schritte ausführen?

Fallbeispiel: In dem oben genannten Beispiel, in dem der Inhalt gefiltert wurde, wurde der Funktion ein Präfix vorangestellt, sodass sie benannt wurde acme_the_content, was darauf hindeutet, dass die Gipfel theme gibt den Inhalt von dem Ort zurück, an dem er innerhalb des Themes aufgerufen wird.

Was würde passieren, wenn wir die Funktion benennen würden acme_get_the_content () ?

Nun, technisch gesehen würde die Funktion die Daten immer dort wiedergeben, wo sie aufgerufen wurden. Dies wäre jedoch nicht mit der WordPress-API vereinbar, da der Entwickler erwarten würde, dass die Daten an sie zurückgegeben werden, sodass sie sie in einer Variablen speichern oder an eine andere Funktion übergeben können.

Es besteht ein Missverhältnis zwischen dem, was der Benutzer erwartet, und dem, was tatsächlich passiert.

Wenn wir über etwas in der realen Welt sprechen würden, wäre dies wie ein Schalter an der Wand, für den der Benutzer erwartet Wenn sie den Schalter betätigen, wird ein Licht oder ein Ventilator im selben Raum eingeschaltet, wenn in der Realität möglicherweise nichts passiert oder ein Licht oder ein Ventilator in einem anderen Raum eingeschaltet wird.

Zu diesem Zweck müssen wir mit der Benennung unserer Funktionen vorsichtig sein, damit wir nicht nur Funktionen schreiben, die nicht mit anderen Funktionen kollidieren, sondern auch eindeutig benannt sind und darauf hinweisen Wie Sie behandeln die Informationen, wenn die Funktion aufgerufen wird.

Was ist mit hilfreichen Tools??

Wie zu Beginn dieses Artikels erwähnt, gibt es auch eine Reihe von Tools und Einstellungen, die wir in unserer Entwicklungsumgebung installieren und konfigurieren können, um mögliche Probleme zu erkennen, bevor wir unser Thema starten.

Dies bedeutet, dass wir in der Lage sind, Funktionen zu identifizieren, die letztendlich aus WordPress entfernt werden, sodass wir keinen veralteten Code schreiben. Darüber hinaus gibt es Möglichkeiten, um herauszufinden, ob Variablen, auf die wir zugreifen möchten, beispielsweise keine definierten Indizes oder andere ähnliche Funktionen haben.

Im letzten Artikel der Serie werden wir uns das genau ansehen. Überprüfen Sie in der Zwischenzeit, was hier behandelt wurde, und teilen Sie Ihre Fragen und Kommentare im Feed unten mit. Dann werden wir diese Serie nächste Woche abschließen.