Die Bedeutung von WordPress Boilerplate in der Plugin-Entwicklung

In den letzten fünf bis zehn Jahren ist die Erstellung von Websites und Anwendungen für das Web viel komplexer geworden als viele Dinge, die in den 90er Jahren erstellt wurden. Vorbei sind die Zeiten, in denen Websites manuell mit HTML in Großbuchstaben, tabellenbasierten Layouts und hässlichem JavaScript erstellt wurden, um eine Art niedliche Animation auf der Seite zu erstellen.

Jetzt verfügen wir über eine Vielzahl von Technologien, Frameworks und Sprachen, die alle zusammenarbeiten, um uns bei der Erstellung vollständiger Softwareanwendungen zu helfen, die im Browser ausgeführt werden.

Es ist eine großartige Zeit, Entwickler zu sein.

Boilerplate wird aufgrund der Vielfalt der uns zur Verfügung stehenden Technologien immer beliebter. Für diejenigen, die es nicht kennen: Boilerplate ist im Grunde eine Codebasis, die Entwicklern hilft, ein Projekt schnell zu starten, ohne Code oder bestimmte Komponenten schreiben zu müssen, die allen Websites und/oder Anwendungen gemeinsam sind.

Natürlich übertreiben sie es möglicherweise so sehr, dass sie klobiger und komplexer als nötig sind, aber alle guten sind dazu gedacht, ein Fundament zu legen – d Funktionen für Sie, die speziell auf Ihr Projekt und Ihre Bedürfnisse zugeschnitten sind.

Vor etwas mehr als einem Jahr begann ich mit der Arbeit an zwei Projekten – WordPress Plugin Boilerplate und WordPress Widget Boilerplate – die jeweils darauf abzielten, Entwicklern eine Grundlage für die Erstellung von Plugins mithilfe der Best Practices von WordPress zu bieten. Glücklicherweise erhalten diese Projekte auch viele andere Beiträge von der Open-Source-Community, die ihnen helfen, so leistungsfähig wie möglich zu werden.

Ein Aspekt bei der Pflege dieser Projekte ist, dass ich oft gefragt werde, warum ich die Dinge auf diese Weise organisiere. In dieser zweiteiligen Serie befassen wir uns also mit Boilerplate-Dateien und den Gründen (und Vorteilen), sie so zu organisieren, wie ich es tue. Anschließend erstellen wir ein einfaches Plugin mit einer dieser Boilerplate-Dateien, um ein Beispiel dafür zu geben wie Sie sie in Ihren zukünftigen Projekten verwenden können.

---

Dateiorganisation

Eine der Schlüsselkomponenten beim Erstellen jeder Softwareanwendung, egal wie groß oder klein, ist die Organisation des Programms. Dies beschränkt sich nicht nur auf die Beziehung zwischen Klassen und/oder Funktionen (was ein Thema für einen anderen Artikel ist), sondern auch darauf, wie Dateien organisiert sind.

Idealerweise sollten Dateien nicht einfach in einem Verzeichnis abgelegt und dann von anderen Entwicklern durchsucht werden, um das Projekt zu verwalten. Stattdessen sollten sie logisch in zusammenhängenden Verzeichnissen organisiert, klar benannt (statt clever) sein und es sollte für jeden Entwickler, der am Projekt mitwirkt, wenig Aufwand erfordern, um zu wissen, wo sich bestimmte Dateien befinden und wo er oder sie ihre eigenen Ergänzungen ablegen kann.

Es ist wie das alte Sprichwort:

Ein Ort für alles und alles an seinem Platz.

Bei der Erstellung dieser beiden Boilerplates habe ich nicht nur versucht, diesem spezifischen Prinzip zu folgen, sondern mich auch von der Art und Weise inspirieren zu lassen, wie Ruby on Rails sein Layout modelliert. Insbesondere bevorzugen sie „Konvention statt Konfiguration“.

Natürlich ist WordPress weder Rails noch ein MVC-Framework, und das möchte ich auch nicht. Ich möchte einfach gute Ideen von anderen Entwicklern übernehmen, um unser Leben in unserer Umgebung einfacher zu machen.

Kern-Plugin-Dateien

Egal wie einfach oder komplex Ihr Plugin ist, es muss mindestens eine PHP-Datei enthalten. Diese Datei dient als Kern-Plugin-Datei und enthält den gesamten Code, die gesamte Logik und die gesamte Funktionalität, die Ihr Plugin zum Leben erweckt.

Wenn Sie sich die verschiedenen Plugins ansehen, werden Sie feststellen, dass die Entwickler unterschiedliche Ansätze verfolgen:

• Einige enthalten den gesamten Inhalt in ​​einer Datei
• Einige teilen verwandte Funktionen in separate Dateien auf und verwenden Kern-Plugin-Dateien, um einfach jede Funktion einzubinden
• Einige trennen einen Teil des Front-End-Codes vom serverseitigen Code

Ich bin nicht hier, um zu beweisen, warum diese Methoden (oder auch nur die genannten) besser sind als andere; nur, warum das Board so aufgebaut ist und wie es für Sie funktionieren könnte.

Plugin-Homepage basierend auf der README-Datei.

Zusätzlich zu den Kern-Plugin-Dateien benötigen WordPress-Plugins auch eine Readme-Datei, um Endbenutzern einige Anweisungen zur Verwendung des Plugins und zum Füllen der Seiten im WordPress-Plugin-Repository zu geben.

Grundsätzlich ist dies alles, was Sie für ein WordPress-Plugin benötigen: die Kern-Plugin-Dateien und die Readme-Datei. Sie können einige sehr komplexe Plugins nur mit diesen beiden Dateien erstellen. Die Wartung kann jedoch sehr schwierig werden, insbesondere wenn andere Entwickler Beiträge leisten, was schließlich zu unerwarteten Fehlern führen kann.

Ich bin also ein großer Fan von Komponenten, die Code logisch trennen.

Ansichten

View ist ein Wort, das ich dem MVC-Muster entlehnt habe (und von Rails inspiriert wurde).

Ansichten können als Front-End-Markup definiert werden, das Elemente auf dem Bildschirm für Administratoren und Website-Besucher darstellt.

Das ist alles. Einfach, oder?

Da wir mit PHP arbeiten, werden natürlich im gesamten Code einige kleinere PHP-Tags platziert, aber der Großteil der Ansichtsdatei sollte HTML mit Klassen- und ID-Attributen sein.

Im Boilerplate gibt es zwei Ansichten:

1. admin.php ist die Ansicht, die zum Rendern von Elementen für den Benutzer im Admin-Dashboard verwendet wird
2. widget.php oder plugin.php ist die Ansicht, die zum Rendern von Elementen für Website-Besucher verwendet wird

Natürlich verfügt das Plugin möglicherweise nicht über ein Dashboard oder eine Ansicht der Website-Besucher. In diesem Fall wird das Verzeichnis views gelöscht und der Code, der für die Aufnahme in die Kern-Plugin-Dateien verantwortlich ist, wird entfernt.

Stylesheet

Dies ist eine triviale Komponente des Boilerplates, da jeder, der irgendeine Art von Frontend-Entwicklung durchführt, weiß, wie man Stylesheets verwaltet, und wahrscheinlich seine eigene Art hat, diese zu organisieren.

Aber der Konsistenz halber ist es erwähnenswert, dass im css-Verzeichnis alle Ihre Stylesheets gespeichert sind. Auch für diese Dateien gelten dieselben Namenskonventionen wie für die zugehörigen Ansichten.

Spezifisch:

1. admin.css ist die Ansicht, die zum Stylen von Elementen für Benutzer im Admin-Dashboard verwendet wird
2. widget.css oder plugin.css sind Ansichten, die zum Gestalten von Elementen für Website-Besucher verwendet werden

Ich habe darüber nachgedacht, eine Verzeichnisstruktur für LESS oder SASS einzuführen, aber ich denke, das ist zu eigensinnig für die Entwicklung und es ist nicht die Richtung, in die ich mit dem Boilerplate gehen möchte. Mir wäre es lieber, wenn die Entwickler ihren eigenen Stil wählen und ihn darin integrieren.

Um dies zu erreichen, organisiere ich meine Stylesheets in meinen eigenen Projekten normalerweise so, dass ich ein dev-Verzeichnis innerhalb des css-Verzeichnisses einfüge und dann eine admin.less- und eine plugin.less-Datei einfüge kompilieren und minimieren Gehen Sie zum Stammverzeichnis css.

Dies folgt weiterhin dem organisatorischen Boilerplate-Ansatz und ermöglicht mir gleichzeitig, meine WENIGER-Dateien einzubeziehen.

JavaScript

JavaScript-Dateien sind wie Stylesheets eine einfache Komponente von Boilerplate, da die meisten Leute, die WordPress verwenden und Themes oder Plugins entwickeln, JavaScript verwendet haben.

Leider ist es für Benutzer und Entwickler einer der frustrierendsten Aspekte bei der Verwendung von JavaScript in WordPress, dass Entwickler sich oft nicht an Best Practices halten.

Generell sollten Entwickler immer Folgendes tun:

1. Verwenden Sie die mit WordPress gebündelte Version von jQuery
2. Vermeiden Sie Konflikte mit der jQuery-Funktion „$“, indem Sie eine anonyme Funktion verwenden, um darauf zuzugreifen
3. Registrieren Sie jQuery nicht als anderes Plugin, da das Theme es möglicherweise verwendet

Davon abgesehen sind Boilerplate-Dateien wie Stylesheets und Ansichten wie folgt organisiert:

1. admin.js ist das JavaScript, das zum Verwalten des Verhaltens von Benutzerelementen im Admin-Dashboard verwendet wird
2. widget.js oder plugin.js ist JavaScript
, das zum Verwalten des Verhaltens von Elementen für Besucher verwendet wird

Wie bei Stylesheets haben Entwickler auch die Möglichkeit, das JavaScript ihres Plugins zu überprüfen und/oder zu minimieren, bevor sie es veröffentlichen. Um bei der Verwaltung von JavaScript-Dateien nicht zu streng zu sein, enthält das Boilerplate keine Unterverzeichnisse, aber ich erstelle oft ein dev-Verzeichnis innerhalb des js-Verzeichnisses, um mein vorab überprüftes und vorab minimiertes JavaScript der Reihe nach zu verwalten.

Sprache

Ein Aspekt beim Erstellen von Plugins besteht darin, sicherzustellen, dass sie von Personen, die andere Sprachen sprechen, aufgerufen und übersetzt werden können. Um die Dinge so einfach wie möglich zu halten, enthält das Boilerplate auch ein lang-Verzeichnis und eine Framework-Datei plugin.po.

Diese Datei ist für die Verwendung in Verbindung mit POEdit konzipiert, sodass Sie nach Abschluss der Entwicklung problemlos mit allen lokalisierten Zeichenfolgen umgehen können.

Was ist mit Bildern und anderen Assets?

Außer Stylesheets und JavaScript-Dateien stellt das Boilerplate keine Verzeichnisse oder Konventionen für die Verwaltung anderer Assets wie Bilder bereit.

Auch hier geht es darum, eine Balance zwischen dem Versuch zu vermeiden, zu eigensinnig zu sein, und gleichzeitig genügend Gerüst bereitzustellen, damit sich Entwickler auf die Kernfunktionalität konzentrieren können. Obwohl nicht jedes Plugin administratives CSS, JavaScript oder Ansichten enthält, sind sie häufiger anzutreffen als das Einbinden von Bildern und anderen Ressourcen.

Die bereitgestellten Konventionen besagen jedoch, dass Sie ein Verzeichnis „Assets“, ein Verzeichnis „Bilder“, ein Verzeichnis „Symbole“ oder jede andere Art von Datei erstellen können, die Sie verwenden würden. Warum sich die Mühe machen?

WordPress-Widget-Vorlage

---

Was ist also der Sinn des Ganzen? Wäre es nicht einfach, eine Datei zu öffnen und mit dem Schreiben des gesamten Codes zu beginnen? Wirklich. Denken Sie jedoch daran, dass die meiste Entwicklung nach der Veröffentlichung des Produkts stattfindet und wenn Sie es mit der Plugin-Entwicklung ernst meinen, sind Sie mit der Entwicklung des Produkts beschäftigt.

Sie müssen also mit dem Ende im Hinterkopf beginnen. Verwenden Sie ein einheitliches Schema zum Organisieren von Dateien, Benennen von Dateien und mehr:

• Vereinfachen Sie die Entwicklung auf lange Sicht, damit Sie und die beitragenden Entwickler wissen, wie Sie Dateien verwalten, wo neue Dateien abgelegt werden und wo bei Bedarf Abhängigkeiten zu finden sind
• Erleichtern Sie die Wartung, indem Sie eine gemeinsame Organisation und ein gemeinsames Muster bereitstellen, das Plugins verbessern kann
• Verbesserte Möglichkeit, Projekte über die erste Version hinaus zu skalieren, ohne dass umfangreiches Refactoring erforderlich ist, wenn die Codebasis unhandlich wird

Vor allem sollte das Gerüst es Entwicklern ermöglichen, problemlos mit der Arbeit an der Kerngeschäftslogik ihres Produkts zu beginnen, ohne ihnen im Weg zu stehen.

---

Fazit

In diesem Artikel haben wir das „Warum“ der Boilerplate-Organisation untersucht, aber nicht wirklich das „Wie“ der Boilerplate-Organisation, daher werden wir im nächsten Artikel nur darauf eingehen.

Konkret werden wir Schritt für Schritt ein Plugin unter Verwendung einer der Boilerplate-Dateien erstellen, damit wir die typischen Schritte identifizieren können, die erforderlich sind, um eine Kopie des Boilerplates zu erhalten und mit der Entwicklung zu beginnen.

Das obige ist der detaillierte Inhalt vonDie Bedeutung von WordPress Boilerplate in der Plugin-Entwicklung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!