Angenommen, Sie arbeiten an einem Projekt für jemanden und Sie haben es festgelegt, Aufgaben werden delegiert, Sie haben alle Bibliotheken und Tools, die Sie für den Einstieg benötigen, und Sie haben getrennt, was das Thema oder die Präsentation sein wird, und was wird die Funktionalität oder die Plugins sein.
Aber anstatt eine Handvoll einzelner Plugins zu haben, was wäre, wenn es ein Paket kleinerer funktionaler Plugins oder Mikro-Plugins oder wie auch immer Sie sie nennen möchten, gäbe, die das Paket antreiben?
Darüber hinaus bauen diese alle auf der gleichen Grundlage auf, teilen aber auch Code miteinander, und um die Sache interessanter zu machen, entscheiden Sie sich dafür, einen PSR-4-Autoloader über Composer zu verwenden, um all dies zu erledigen?
PSR-4 Automatisches Laden von WordPress-Plugins
Erstens, um darüber nachzudenken, was ich zu sagen versuche (denn wer weiß, ob ich mich klar ausdrücke 🙃), ist, dass Sie Ihre Arbeit im wp-content/pluginsVerzeichnis haben. Und Ihr Plugin befindet sich beispielsweise in acme-pluginsund hat Unterverzeichnisse für Ihre Mikro-Plugins.
Wir werden es für dieses Beispiel einfach halten und sagen, dass es das Haupt-Plugin und dann nur ein Mikro-Plugin gibt. Das Verzeichnis würde etwa so aussehen;
Jetzt gibt es die Dateien, die Sie in einem Plugin erwarten:
- LIESMICH,
- LIZENZ,
- ÄNDERUNGSPROTOKOLL,
- composer.json
- komponist.lock
- Verkäufer
- die Plugin-Bootstrap-Datei,
- usw.
Hier ist die Sache: Wenn Sie PSR-2 verwenden und einen PSR-4- Autoloader verwenden werden, dann gibt es zwei Dinge, die Sie wissen müssen:
- Die Namespaces sollten der Verzeichnisorganisation entsprechen. Ich habe während meiner Präsentation auf dem WordCamp Atlanta 2017 (insbesondere unter virtueller und logischer Organisation) ein wenig darüber gesprochen.
- So arbeiten Sie mit
composer.json, um Ihre Autoloader zu definieren. Sie können hier viel darüber lesen, aber ich werde die Klippennotizen im Rest dieses Beitrags geben.
Das Problem ist also, dass sich das vendorVerzeichnis eine Ebene über dem befindet, wo einige der Quelldateien vorhanden sind. Daher funktioniert die Standardmethode zum Einrichten eines benutzerdefinierten Autoloaders in Composer nicht.
Zum Beispiel ist es sehr typisch , dies zu sehen :
{
"name": "pressware/acme-plugins",
"description": "A demo plugin",
"autoload": {
"psr-4": {
"Acme": "src/",
}
},
// ...
}Aber um unsere Arbeit zu kompensieren, müssen wir Folgendes tun :
{
"name": "pressware/acme-plugins",
"description": "A demo plugin",
"autoload": {
"psr-4": {
"Acme": "",
"AcmeMicroPlugin": "MicroPlugin/src/"
}
},
// ...
}Es ist eine einfache Änderung, aber es ist ein einfaches Beispiel, richtig? Also, was ist der Takeaway daraus?
Beachten Sie, dass wir einige Änderungen am Autoload- Speicherort aktualisiert haben. Konkret geht es um Folgendes:
- Das erste Element ist der Namespace der obersten Ebene, zu dem alle Plugins gehören, die zum Acme-Plugin gehören.
- Der zweite Eintrag bezieht sich auf das MicroPlugin, das Sie im oben abgebildeten Verzeichnis sehen. Dies stellt den Namensraum für dieses bestimmte Plugin dar und weist Composer an, nach Quelldateien zu suchen, die mithilfe des Eigenschaftsverzeichnisses automatisch geladen werden sollen
Von hier aus fügen Sie einen neuen Eintrag für den Autoloader hinzu, der jedem Mikro-Plugin entspricht, das zum Top-Level-Plugin gehören wird.
Organisation zukünftiger Mikro-Plugins
Es gibt einige Möglichkeiten, wie Sie Ihren Code so organisieren können, dass Sie einen Standard-Autoloader verwenden können.
Wenn Sie dem Micro-Plugin-Modell (mangels eines besseren Begriffs) folgen, wird es nicht funktionieren, sodass Sie Ihre Dateien neu organisieren müssen, und das kann mit der Zeit mühsam sein.