WordPress-Widgets: Refactoring, Teil 1

Der letzte Beitrag enthielt viele Informationen zum Einrichten von Tools zur Codequalität in Ihrer WordPress-Entwicklungsumgebung, aber sie sind notwendig, wenn wir viel Refactoring durchführen werden.

Aber wie ich zu Beginn dieses Beitrags erwähnt habe, bietet uns das Verlegen von Codequalitätstools zunächst eine Grundlage, die wir verwenden können, wenn wir die Boilerplate umgestalten (was wir angesichts der Menge an Rot, die von GrumPHP angezeigt wird, eindeutig tun müssen).

Ehrlich gesagt sehe ich diese als notwendig an, wenn Sie irgendeine Art von Entwicklung durchführen wollen, daher müssen Sie zeigen, wie man sie einrichtet.

Unabhängig davon zeigt der vorherige Beitrag, wie viel Arbeit wir uns vorgenommen haben, oder?

Jetzt beginnen wir mit dem Refactoring des WordPress Widget Boilerplate.

Dies wird nicht nur die Codequalität verbessern, sondern uns auch durch einige objektorientierte Prinzipien führen, die wir beim Erstellen unserer Widgets und bei zukünftigen WordPress-Entwicklungsbemühungen anwenden können.

Das WordPress-Widget Boilerplate: Refactoring, Teil 1

Das vielleicht Spannendste für mich ist es, dieses Repository auf moderne Standards zu bringen. Wenn Sie sich zum Zeitpunkt dieses Beitrags den Master-Branch in GitHub (oder später die Geschichte des Repositorys) ansehen, werden Sie feststellen, dass er sechs Jahre alt ist.

Dieses Ding ist sechs Jahre alt (zum Zeitpunkt dieses Beitrags).

Das ist eine lange Zeit in Internetjahren, oder?

Wie auch immer, bei unseren Refactoring-Bemühungen werden wir einige Dinge tun:

• einen Branch erstellen, von dem aus gearbeitet werden kann, bevor er wieder in den Master-Branch gemergt wird,
• Implementierung einer kohärenteren Art der Organisation von Dateien,
• Aktualisierung der Codierungsstandards, um dem zu folgen, was mehr im Einklang mit PSR steht,
• und mehr.

Ich lege dies jetzt dar, weil wir in diesem Beitrag wahrscheinlich nicht alles erreichen werden, aber wir werden eine Menge Boden abdecken. Also mit diesen Worten, fangen wir an.

1 Erstellen eines Entwicklungszweigs

Angenommen, Sie haben eine Kopie des Repositorys von auf Ihrem lokalen Rechner, die Sie nach dem letzten Beitrag haben sollten, müssen wir als Erstes einen Zweig erstellen, von dem aus wir unsere Arbeit erledigen können.

Es hat sich bewährt, nicht am Master-Zweig zu arbeiten. Stattdessen sollte der Master immer verwendet werden, um die neueste stabile Version des Codes bereitzustellen.

Geben Sie dazu in Ihrem Terminal folgenden Befehl ein:

$ git checkout -b develop

Dadurch wird eine neue lokale Verzweigung erstellt. Es wurde noch nicht auf GitHub oder Ihr Remote-Repository hochgeladen (wo auch immer Sie es aufbewahren).

Geben Sie als nächstes den folgenden Befehl ein:

$ git push --set-upstream origin develop

Dadurch wird der Entwicklungszweig in das Remote-Repository verschoben. Sobald dies erledigt ist, sollten Sie alle Änderungen sehen können, die wir im letzten Beitrag in Ihrem Remote-Repository implementiert haben.

Wenn Sie GitHub verwenden, sollte es in etwa so aussehen:

Wenn Sie einen anderen Dienst verwenden, sollte es immer noch ähnlich aussehen. Das heißt, die Verzeichnisstruktur sollte dieselbe sein, aber die Art und Weise, wie sie im Browser aussieht, wird variieren.

Eine Anmerkung zur Filiale

Denken Sie daran, dass der Zweck dieses Zweigs darin besteht, dass wir all unsere Arbeit erledigen. Auf diese Weise greifen wir nicht in den Master-Zweig ein, von dem viele Leute ziehen werden.

Um es klar zu sagen, vielleicht wird niemand daraus ziehen. Vielleicht werden sie es. Ungeachtet dessen sollen diese hier vorgestellten Praktiken zeigen, wie Sie ein Projekt mit Quellcodeverwaltungs- und Codequalitätstools ausführen, damit Sie bessere Projekte für sich selbst, Ihr Unternehmen und mehr erstellen können.

2 Dateien neu organisieren

Als erstes sollten wir die Dateien neu organisieren, damit sie eine modernere Struktur nachahmen. Ich werde mein Bestes tun, um die Entscheidungen zu rechtfertigen, die ich für das Projekt treffe, während wir dies tun; Nehmen Sie sich jedoch frei, wie Sie es tun möchten.

Die Entscheidungen, die ich treffe, werden sich letztendlich auf die primäre Boilerplate auswirken. Wofür Sie sich entscheiden, wirkt sich darauf aus, wie Sie es in Ihrer täglichen Arbeit verwenden oder wie Sie sich entscheiden, mit dem Projekt als Ganzes voranzukommen.

Aktualisieren von Verzeichnissen

Eines der Dinge, die ich versuche, ist, meine Verzeichnisse aufzuschlüsseln, damit sie so übersichtlich wie möglich sind. Das heißt, ich versuche Folgendes zu tun:

• Erstellen Sie ein Assets – Verzeichnis für JavaScript und Stylesheets,
• Erstellen Sie ein src- Verzeichnis für alle PHP-Dateien,
• ein Sprachverzeichnis für Internationalisierungsdateien erstellen,
• Bewahren Sie alle anderen Dateien im Stammverzeichnis des Repositorys auf, damit andere der bereitgestellten README-Datei leicht folgen können.

Dazu werde ich zuerst ein paar Dinge entfernen und verschieben. Ich habe versucht, dies in einer bestimmten Reihenfolge zu organisieren:

1. Ich werde die Datei README.txt entfernen. Diese Datei wird als standardmäßige README-Vorlage verwendet, wenn Sie Code an das WordPress-Plug-in-Repository senden möchten, aber sie ist für das, was ich für das Boilerplate möchte, nicht erforderlich.
2. Ich werde plugin.php in Plugin .php umbenennen, um den PSR-Konventionen zu folgen.
3. Ich werde auch lang in Sprachen umbenennen .
4. Ich werde ein Assets – Verzeichnis erstellen und die css- und js-Verzeichnisse verschieben und dann in dieses Verzeichnis verschieben. Ich werde in jedem dieser Verzeichnisse ein dev -Unterverzeichnis erstellen, in dem wir an Sass- und nicht minimierten JavaScript-Dateien arbeiten können (beide werden später in der Serie erscheinen).
5. Danach erstelle ich ein src- Verzeichnis und verschiebe das Views -Stylesheet in dieses Verzeichnis.
6. Ich werde Ansichten auch in Ansichten umbenennen und die darin enthaltenen Dateien in Großbuchstaben schreiben.
7. Abschließend verschiebe ich alles in das Stammverzeichnis des Verzeichnisses. Das bedeutet, dass Widget-Boilerplate verschwindet und sich alle Dateien im Stammverzeichnis des Repositorys befinden.

Das sind viele Schritte, aber sie sind klein. Ich lege sie gerne zuerst dar, damit klar ist, was im Rest dieses Abschnitts passieren wird.

Entfernen Sie die README

Geben Sie dazu einfach den folgenden Befehl in Ihrem Terminal aus dem Stamm des Widget-Boilerplate- Verzeichnisses ein:

$ rm readme.txt

Dadurch wird die Datei entfernt. Wenn Sie in Ihrem Terminal folgenden Befehl eingeben:

$ git status

Sie sollten so etwas sehen:

Ich bin ein Fan davon sicherzustellen, dass die verschiedenen hochgeladenen Änderungen klar und prägnant sind, damit es einfacher ist, sie einzeln rückgängig zu machen. Also lasst uns weitermachen und diese Änderung festschreiben und vorantreiben.

Gebe folgendes ein:

$ git rm README.txt
$ git add. $ git commit -n -m "Removing the original README.txt template."
$ git push

Dadurch wird Git angewiesen, die Datei zu entfernen, die einzelne Änderung zum Änderungssatz hinzuzufügen, sie zu übertragen, ohne irgendwelche Codequalitätstools auszuführen (weil wir das jetzt nicht tun müssen; andernfalls schlägt es fehl) und sie zu pushen zum Entwicklungszweig des entfernten Repositorys .

Nachdem wir das erledigt haben, können wir einige Dateien umbenennen.

Dateien umbenennen

Wo wir gerade dabei sind, werden wir nicht nur die Plugin .php-Datei umbenennen, sondern auch die anderen PHP-Dateien. Dies sind Dateien, die logisch im selben Änderungssatz gruppiert werden können, daher ist es sinnvoll, dies zu tun.

Geben Sie also von Ihrem Terminal aus die folgenden Befehle ein:

$ mv plugin.php Plugin.php
$ mv views/admin.php views/Admin.php
$ mv views/widget.php views/Widget.php

Dabei haben wir noch keine Änderungen an Dateien vorgenommen, also gibt es nichts zu übergeben. Lassen Sie uns mit dem Umbenennen von Verzeichnissen fortfahren.

Verzeichnisse erstellen; Verzeichnisse umbenennen

Lassen Sie uns wie bei den Dateien fortfahren und ein neues Assets – Verzeichnis erstellen. Geben Sie in Ihrem Terminal den folgenden Befehl ein:

$ mkdir assets

Als nächstes wollen wir die css- und js- Verzeichnisse in dieses Verzeichnis verschieben, also geben Sie auch Folgendes im Terminal ein:

$ mv css assets
$ mv js assets

Und benennen wir das Verzeichnis lang in Languages ​​um, indem wir den folgenden Befehl eingeben:

$ mv lang Languages

Zum Schluss benennen wir die Ansicht in Ansichten um:

$ mv views Views

An diesem Punkt haben wir alles getan, was wir mit den Dateien tun können, die sich derzeit im Hauptverzeichnis befinden. Wir müssen jedoch noch Unterverzeichnisse für unsere vorverarbeiteten Assets vorbereiten.

Bevor Sie dies tun, ist es jedoch eine gute Angewohnheit, eine schnelle Git – Statusprüfung durchzuführen, um zu sehen, was vorhanden ist, das einem Änderungssatz hinzugefügt werden kann. Wenn Ihr Repository wie meines ist, sehen Sie wahrscheinlich so etwas wie das Folgende:

In diesem Fall denke ich, dass es in Ordnung ist, alles in einem einzigen Änderungssatz mit einem Kommentar hinzuzufügen, der angibt, dass wir Dateien umbenannt und verschoben haben.

Sie können abweichen und wenn ja, ist das völlig in Ordnung. Ihre Befehle werden sich ein wenig von meinen unterscheiden, aber hier ist, was ich für mein Commit habe:

$ git add. $ git commit -n -m "Creating new directories; Renaming files."
$ git push

Nun zu den Unterverzeichnissen für unsere vorverarbeiteten Dateien.

Unterverzeichnisse erstellen

Erstellen Sie im CSS-Verzeichnis ein Unterverzeichnis namens dev und erstellen Sie eine leere Datei namens admin.scss und widget.scss, da wir später in der Serie mit diesen Dateien arbeiten werden.

Fügen Sie als Nächstes ein dev – Verzeichnis zum JavaScript-Verzeichnis hinzu und fügen Sie diesen Dateien leere admin.js -Dateien und widget.js- Dateien hinzu. Wenn Sie Lust dazu haben, können Sie die bereits vorhandenen Dateien in die dev – Verzeichnisse verschieben, da dies die Dateien sind, die wir als Grundlage für unsere Entwicklungsdateien verwenden werden.

Das ist ein optionaler Schritt; Ich habe es jedoch getan, weil ich so am liebsten arbeite. Hier ist der Satz von Befehlen, die ich ausgeführt habe.

Aus dem CSS- Verzeichnis…

$ mkdir dev
$ mv admin.css admin.scss && mv widget.css widget.scss
$ mv *.scss dev

Oben habe ich das dev- Verzeichnis für meine Stylesheets erstellt, sie in Sass-Dateien umbenannt und sie in das dev- Verzeichnis verschoben.

Bevor Sie fortfahren, ist jetzt ein guter Zeitpunkt, um eine Git-Statusprüfung durchzuführen und Änderungen in Bezug auf die Stylesheets zu übernehmen:

$ git add. $ git commit -n -m "Renaming and moving stylesheets into a dev directory."
$ git push

Nun, aus dem js- Verzeichnis…

$ mkdir dev
$ mv *.js dev

Da wir den Dateityp der zugehörigen Dateien nicht ändern müssen, können wir sie einfach in das neue Verzeichnis verschieben.

Lassen Sie uns schließlich das Gleiche tun und sehen, ob es irgendwelche Änderungen gibt, die wir durch eine schnelle Git-Statusprüfung nach oben bringen können (was es geben sollte). Hier ist eine Liste der Befehle, die ich ausgeführt habe, um meine Änderungen zu übernehmen und zu pushen:

$ git add. $ git commit -n -m "Adding a JavaScript dev directory and moving the development files."
$ git push

Wir sind fast fertig. Sie müssen nur noch bestimmte Verzeichnisse in das Stammverzeichnis des Repositorys verschieben und das Kernverzeichnis in src umbenennen. Also machen wir das jetzt.

Verschieben Sie Verzeichnisse in das Stammverzeichnis

Im Wesentlichen müssen wir alles außer der Plugin-Datei und dem Views – Verzeichnis aus dem Widget-Boilerplate- Verzeichnis verschieben, und wir müssen Widget-Boilerplate in src umbenennen .

Klingt einfach, oder? Es ist ziemlich einfach. Aus dem Widget-Boilerplate- Verzeichnis:

$ mv assets .. && mv languages ..
$ cd ..
$ mv widget-boilerplate src

Dann übertrage ich die Änderung wie folgt auf GitHub:

$ git add. $ git commit -n -m "Reorganizing the directory structure."
$ git push

Jetzt haben wir eine viel modernere Verzeichnisstruktur eingerichtet. Sie können es hier in meinem Entwicklungszweig sehen .

Ein Wort über OOP

Und jetzt, da wir all dies an Ort und Stelle haben, können wir mit dem Schreiben von Code beginnen. Aber täuschen Sie sich nicht: Ein Teil der objektorientierten Programmierung ist auch objektorientierte Analyse und objektorientiertes Design.

In diesem Beitrag haben wir im Wesentlichen ein objektorientiertes Architekturdesign angewendet, das auf der Analyse basiert, wie das Plugin zusammenpasst.

Der nächste Teil ist jedoch die Aktualisierung des Codes, um all das Rot loszuwerden, das wir beim Sniffen unseres Codes gesehen haben.

Im nächsten Beitrag

Das Hauptziel des nächsten Beitrags ist es, die Codierungsstandards weiter zu aktualisieren, damit wir alle Probleme gelöst haben, die von unserer IDE oder den Codequalitätstools ausgelöst wurden, die wir auf der Befehlszeile ausführen.

Wir sollten auch ein viel saubereres, besser organisiertes Repository haben und in der Lage sein, unsere Arbeit wieder in den Master-Zweig zusammenzuführen.

Stellen Sie jedoch zunächst sicher, dass Sie alles oben Genannte gut im Griff haben, bevor Sie fortfahren, da dies für den Rest der Arbeit, die vor uns liegt, erforderlich ist.