WordPress-Widgets: Refactoring, Teil 6

Sie sollten mit dem Refactoring vertraut sein, das wir in Bezug auf das WordPress Widget Boilerplate durchführen. Falls nicht, empfehle ich die bisherige Serie nachzuholen durch:

• beim Lesen des vorherigen Beitrags ,
• oder lesen Sie die gesamte Serie bis zu diesem Punkt,
• und den Entwicklungszweig des Projekts auf GitHub betrachten.

Was die Codebasis angeht, sind wir im Moment an einem guten Ort. Wir haben damit begonnen, einen Großteil des Codes in kleinere, fokussiertere Klassen umzugestalten. Und wir haben gerade eine Registrierung eingerichtet, damit wir mit der Arbeit mit Instanzen von Objekten im gesamten Plugin beginnen können, ohne dass zu viel Kopplung erforderlich ist.

Aber es gibt immer noch ein Problem, mit dem wir konfrontiert sind, und es befasst sich mit Namensräumen und dem automatischen Laden. Ich habe vor ein paar Jahren ein wenig darüber gesprochen, aber nicht in Bezug auf Composer.

Und das werden wir uns in diesem Beitrag ansehen.

Das WordPress-Widget Boilerplate: Refactoring, Teil 6

Im zweiten Beitrag dieser Serie haben wir begonnen, über Composer zu sprechen. Wenn Sie die meisten PHP-Entwickler fragen (einschließlich derjenigen, die mit WordPress arbeiten), werden Sie wahrscheinlich hören, dass Composer ein Paketmanager oder ein Abhängigkeitsmanager ist.

Kurz gesagt, es ist eine Möglichkeit für uns, Bibliotheken von Drittanbietern in unser Projekt einzubinden und dann ihre Funktionen zu nutzen (damit wir dafür keinen eigenen Code schreiben müssen).

Aber es gibt noch eine weitere Funktion, die Composer bietet, die von immensem Nutzen ist, insbesondere wenn Sie viele Klassen verwenden und nicht in Ihrer gesamten Codebasis require_once-Anweisungen verwenden möchten.

Und das ist der Autoloader.

Der Autoloader definiert

Direkt aus dem Handbuch:

Für Bibliotheken, die Autoload-Informationen angeben, generiert Composer eine vendor/autoload.phpDatei. Sie können diese Datei einfach einbinden und ohne zusätzliche Arbeit die Klassen verwenden, die diese Bibliotheken bereitstellen:

Wenn Sie den Code bisher verfolgt haben, werden Sie sehen, dass wir tatsächlich bereits den von Composer generierten Autoloader verwenden.

Zuerst haben wir die notwendige Konfiguration definiert :

{
    "name": "wordpress-widget-boilerplate/wordpress-widget-boilerplate",
    "description": "An organized, maintainable boilerplate for building widgets using WordPress best practices.",
    "type": "wordpress-plugin",
    "license": "GPL-3.0-or-later",
    "homepage": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate",
    "authors": [
      {
        "name": "Tom McFarlin",
        "email": "tom@pressware.co",
        "homepage": "https://pressware.co"
      }
    ],
    "support": {
      "issues": "https://github.com/tommcfarlin/WordPress-Widget-Boilerplate/issues"
    },
    "config": {
      "preferred-install": "dist",
      "platform": {
          "php": "7.1"
      }
    },
    "repositories": [
      {
        "type": "composer",
        "url": "https://wpackagist.org"
      }
    ],
    "require": {
      "php": "7.1",
      "composer/installers": "^1.4"
    },
    "require-dev": {
        "friendsofphp/php-cs-fixer": "^2.13.1",
        "jakub-onderka/php-parallel-lint": "^1.0.0",
        "phpmd/phpmd": "^v2.6.0",
        "nikic/php-parser": "^4.0",
        "ocramius/proxy-manager": "^2.0.0",
        "phpro/grumphp": "^0.13.1"
    },
    "scripts": {
      "test": [
        "./vendor/bin/grumphp run"
      ]
    },
    "minimum-stability": "stable"
  }

Dann haben wir begonnen, es in den Bootstrap des Plugins aufzunehmen (was wir heute fertigstellen werden):

Aber hier gibt es ein Problem: Wie laden wir nur die Klassen, die wir für die Verteilung brauchen?

Anders ausgedrückt: Es gibt viele Bibliotheken, die wir in der Entwicklung verwenden, um sicherzustellen, dass wir qualitativ hochwertigen, standardkonformen Code schreiben. Aber wir wollen nicht 10 MB Daten an diejenigen verteilen, die unser Projekt nutzen.

Stattdessen müssen wir nur die erforderlichen Dateien einfügen, richtig? Und um das zu tun, müssen wir sicherstellen, dass wir einen Autoloader generieren, den wir einbinden können und der genau das tut.

Zuerst zeige ich Ihnen den Befehl und erkläre dann, was er alles tut:

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Dadurch wird genau das generiert, was wir für unser Projekt benötigen, um für eine Produktionsumgebung zu funktionieren. Hier ist, was jede Flagge tut:

• Composer installieren. Dadurch werden einfach alle Abhängigkeiten installiert. Wenn Sie bereits einige davon in Ihrem Anbieterverzeichnis haben, werden dadurch alle außer den erforderlichen entfernt.
• kein Entwickler. Dadurch wird verhindert, dass Composer die Pakete im Abschnitt require-dev seiner Konfigurationsdateien installiert (nämlich Abhängigkeiten, die wir mit GrumPHP verwenden).
• nein-ansi. Dadurch wird verhindert, dass eine ANSI-Ausgabe auftritt. Es kann Ihnen egal sein, ob Sie dies ausführen möchten oder nicht. Wenn Sie sich für eine Art der automatischen Bereitstellung entscheiden, verwenden Sie sie. andernfalls kann es aus dem Befehl weggelassen werden.
• keine Interaktion. Dies ist ein weiteres Flag, das speziell für Umgebungen verwendet wird, in denen Sie das Projekt automatisch erstellen möchten und sich nicht mit Fragen, Ausgaben und ähnlichen Dingen beschäftigen müssen.
• Optimieren-Autoloader. Kurz gesagt, dies erzeugt einen schnelleren Autoloader. Abhängig von der Größe Ihres Projekts kann es eine Weile dauern, bis es ausgeführt wird, aber es zahlt sich aus, wenn Sie Ihre Arbeit starten.
• kein Fortschritt. Dadurch wird die Anzeige des Fortschrittsbalkens im Terminal ausgeblendet. Vielleicht möchten Sie das tatsächlich sehen, und wenn ja, ist das großartig; Einige Umgebungen können jedoch bestimmte Zeichen (z. B. die Rücktaste) möglicherweise nicht gut verarbeiten.
• Vorzugsabstand. Dadurch wird sichergestellt, dass die installierten Pakete mit der Distributionsversion installiert werden (im Gegensatz zu etwas, das weniger stabil ist).

Noch interessiert?

Wenn Sie wirklich neugierig sind, den Autoloader für Projekte außerhalb dieses Beitrags zu optimieren, empfehle ich Ihnen, diese Seite in der Composer-Dokumentation zu lesen. Es liegt außerhalb des Rahmens dessen, was wir hier tun, aber es kann bei anderen Arbeiten nützlich sein, die Sie jetzt haben oder die Sie in Zukunft erledigen werden.

Wie sieht dieser Look in der Boilerplate aus?

Wenn Sie auf Ihrem lokalen Computer an der Boilerplate arbeiten, sehen Sie möglicherweise Folgendes:

Wenn Sie jedoch den oben enthaltenen Befehl ausführen, sehen Sie Folgendes:

Das ist ein großer Unterschied und das ist ein kleines Projekt. Stellen Sie sich vor, etwas viel Größeres zu tun, das in der Produktion laufen wird.

Aus Erfahrung kann ich Ihnen sagen, dass Projekte schnell 20 MB oder mehr an Abhängigkeiten erreichen können, wenn Sie eine Vielzahl von Bibliotheken von Drittanbietern für Dinge wie Protokollierung, HTTP-Anforderungen und Tools zur Codequalität verwenden.

Werden wir in unser Lieferantenverzeichnis aufgenommen?

Die Leute werden oft sagen, dass Sie das Herstellerverzeichnis nicht in die Quellcodeverwaltung aufnehmen sollten, und das aus gutem Grund: Es kann riesig sein.

Sogar die Composer-Dokumentation spricht darüber:

Die beste Vorgehensweise besteht darin, alle Entwickler Composer verwenden zu lassen, um die Abhängigkeiten zu installieren. Ebenso sollten der Build-Server, das CI, die Bereitstellungstools usw. angepasst werden, um Composer als Teil ihres Projekt-Bootstrappings auszuführen.

Was sollen wir also tun? Wir brauchen den Autoloader und wir brauchen bestimmte Abhängigkeiten, weil unsere Benutzer nicht wissen, dass sie Composer ausführen müssen (und sie auch nicht ausführen müssen müssen!), wenn sie unsere Arbeit herunterladen.

Aufgrund der Art von WordPress und der Arbeit, die wir leisten, müssen wir das Vendor-Verzeichnis verpflichten, aber nur mit sehr bestimmten Anforderungen.

1. Wir erstellen einen Zweig, der für die Veröffentlichung verwendet wird (wir nennen ihn auf kreative Weise Veröffentlichung und können bei Bedarf Entwicklung damit zusammenführen).
2. Wir werden sicherstellen, dass das Vendor-Verzeichnis nicht Teil der gitignore-Datei ist; Wir stellen jedoch sicher, dass die .git-Verzeichnisse innerhalb des Herstellerverzeichnisses ignoriert werden (das kann immer noch viel Platz beanspruchen).

Lassen Sie uns also jeden Schritt ausführen und sehen, wie es aussieht, wenn wir fertig sind.

Erstellen des Release-Zweigs

Um einen neuen Zweig innerhalb des Terminals zu erstellen, geben Sie den folgenden Befehl ein :

$ git checkout -b release

Dies nimmt den gesamten Code, an dem wir arbeiten, und erstellt dann einen neuen Zweig damit. Da dies der Zweig sein wird, den wir verwenden, um als das zu fungieren, was unsere Benutzer verwenden werden (wir werden in einem zukünftigen Beitrag über master sprechen).

Überprüfen Sie zunächst Ihre Datei composer.json und stellen Sie sicher, dass sie Folgendes enthält:

"autoload": {
    "psr-4": {
        "WordPressWidgetBoilerplate": "src/",
        "WordPressWidgetBoilerplateSubscriber": "src/Subscriber/",
        "WordPressWidgetBoilerplateUtilities": "src/Utilities/",
        "WordPressWidgetBoilerplateViews": "src/Views/"
    }
},

Jetzt müssen wir sicherstellen, dass wir den obigen Composer-Befehl ausführen, um sicherzustellen, dass sich nur das, was wir brauchen, im Herstellerverzeichnis befindet .

$ composer install --no-dev --no-ansi --no-interaction --optimize-autoloader --no-progress --prefer-dist

Jetzt müssen wir gitignore aktualisieren.

Aktualisieren, was wir ignorieren

Und wenn Sie sowohl die Serie als auch den Beitrag bis hierher verfolgt haben, wissen Sie, dass es ungefähr so ​​​​aussehen wird (es kann mehr oder weniger enthalten, sollte aber mindestens dies enthalten).

Bei mir sieht das so aus :

*.DS_Store
*.log
wp-config.php
wp-content/advanced-cache.php
wp-content/backup-db/
wp-content/backups/
wp-content/blogs.dir/
wp-content/cache/
wp-content/upgrade/
wp-content/uploads/
wp-content/mu-plugins/
wp-content/wp-cache-config.php
wp-content/plugins/hello.php

/.htaccess
/license.txt
/readme.html
/sitemap.xml
/sitemap.xml.gz

/vendor/**/.git
/vendor/bin
composer.lock

Je nachdem, ob Sie ein Terminal oder einen Client verwenden, werden Sie sehen, dass neue Dateien zu übergeben sind (insbesondere aus dem Vendor-Verzeichnis). Fügen Sie diese also Ihrem Zweig hinzu.

Bestätigen Sie dann Ihre Änderungen. Wenn Sie im Terminal arbeiten, müssen Sie möglicherweise Folgendes angeben:

$ git push --set-upstream origin release

Und damit sollte Ihr Code funktionieren und auf GitHub (oder dem von Ihnen verwendeten Quellcodeverwaltungsdienst) verfügbar sein. Hier können Sie sehen, was ich zur Verfügung habe.

Funktionalität hinzufügen

Jetzt, da wir alle notwendigen Teile an Ort und Stelle haben, ist es an der Zeit, Composer, den Autoloader, unsere abstrakten Klassen und unsere Registrierung zu verwenden, um damit zu beginnen, dem WordPress-Widget Boilerplate einige grundlegende Funktionen hinzuzufügen, damit wir etwas für unsere Arbeit zeigen können .

Für diejenigen, die neugierig sind, plane ich im Moment, die Zweige so zu organisieren:

• master wird das sein, was für jeden verfügbar ist, der ein WordPress-Widget erstellen möchte,
• entwickeln ist ausschließlich für Entwickler gedacht, darunter diejenigen, die wissen, wie man Composer und die in diesem Beitrag behandelten Themen verwendet.
• Release wird verwendet, um eine funktionierende Demo bereitzustellen.

Sehen Sie sich jedoch vorerst an, was in diesem Beitrag behandelt wird, und wir werden dies im nächsten Beitrag fortsetzen.