Composer-Namespace-Kollisionen in der WordPress-Plugin-Entwicklung

Ich stoße auf ein völlig vorhersehbares, aber unglaublich ärgerliches und schwer zu lösendes Problem.

Ich habe an einem PHP-Framework für die Entwicklung von WordPress-Plugins gearbeitet. Es verwendet Composer für das Abhängigkeitsmanagement. Das Problem ist natürlich, wenn Sie zwei Instanzen meines Frameworks in derselben Installation von WordPress haben, haben Sie zwei Anbieterordner und zwei Kopien aller Pakete, die vom Framework benötigt werden. Was zu einem Fehler führt.

Das Framework fungiert als separates Plugin, das dann von allen darauf aufbauenden Apps/Plugins geerbt wird.

Verschieben Sie den Vendor-Ordner in den Core-Framework-Ordner?

Probleme: Ich weiß nicht, was passieren würde, wenn ich zwei composer.json-Dateien und zwei composer.phar-Dateien habe, die in denselben Vendor-Ordner schreiben und denselben Autoloader verwenden. Vermutlich wäre es nicht gut. Abgesehen davon löst es nicht das Problem von Kollisionen mit Composer-Paketen, die von anderen Skripten oder Plugins verwendet werden könnten, als von dem, was ich zu handhaben versuche.

Ich stecke also fest. Ist das ein Problem, das gelöst werden kann, oder ist es einfach PHP eigen?

Composer ist nicht wirklich dazu gedacht, mehrmals im selben Projekt verwendet zu werden. Auf der anderen Seite ist auch nichts schlimmes daran, aber Sie verlieren seine Abhängigkeitsfunktionen und müssen dies wie einen allgemeinen Fall von Abhängigkeiten in der WordPress-Umgebung behandeln.

Mit anderen Worten – wenn Sie Abhängigkeiten nicht auf Composer-Weise machen und WordPress überhaupt keine Abhängigkeiten macht, wird es Ihr persönliches Problem, wie Sie damit umgehen.

Ich weiß nicht, was passieren würde, wenn ich zwei composer.json-Dateien und zwei composer.phar-Dateien habe, die in denselben Herstellerordner schreiben und denselben Autoloader verwenden

Ich verstehe nicht, warum der Vendor-Ordner derselbe wäre, wenn Sie mehrere Composer-Installationen verwenden … Können Sie erläutern, wie Sie ihn strukturieren und ob er für den öffentlichen oder privaten Gebrauch gedacht ist?

Ich bin mit Composer oder dem von Ihnen verwendeten Plugin-Framework nicht sehr vertraut, aber im Allgemeinen – das Vermeiden von Funktions-/Klassennamenkollisionen in WordPress-Plugins geschieht auf folgende Weise:

• Angenommen, Ihr Plugin (z. B. MyCoolPlugin) ist objektorientiert geschrieben, z. B. als Klasse namens MyCoolPlugin, können Sie die Hilfsklasse/Bibliothek als Unterklasse von MyCoolPlugin einschließen.

• class_exists(), das ist PHPs Methode, um herauszufinden, ob eine Klasse definiert wurde. Angenommen, Ihre Hilfsklasse hat Folgendes:

class MyHelperClass{
}

Sie können die folgende Prüfung verwenden, bevor Sie die Klasse in jedem Ihrer Plugins deklarieren:

if(!class_exists('MyHelperClass')){
   class MyHelperClass{
   }
}

Natürlich gibt es hier einen Kompromiss, da nur die erste Instanz der Klasse in unserem WordPress verwendet wird. Wenn Sie beispielsweise zwei Plugins mit zwei verschiedenen Versionen der Hilfsklasse haben, ist immer nur eines davon aktiv und verfügbar.

• Eine globale Variable – zB define('MY_HELPER_IS_LOADED', true); in den Hilfsdateien (falls Sie sie per include() oder require()). Dann am Anfang jede enthaltene Hilfsdatei mit überprüfen if(defined('MY_HELPER_IS_LOADED')) return;was dazu führt, dass die aktuell angeforderte Datei für include/require NICHT eingeschlossen wird.

Auch hier werden die oben genannten Taktiken im Allgemeinen in PHP verwendet, ich bin mir nicht sicher, wie Ihr Plugin-Framework genau eingerichtet ist.