Kategorien
Konfigurieren von Verzeichnissen in Plugins
Wochenende schon wieder rum. Eigentlich eine Sauerei. Wir sind aber ganz harte und stürzen uns auch diesen Montag wieder in Arbeit. Naja so lange ist es nicht mehr. Habe bald drei bis viel Wochen Urlaub, da muss ich mal schauen, was ich mache. Aber genug über mich. Wir wollen lieber über PHP und Co. reden, was wir jetzt auch machen.
Nehmen wir an, wir wollen ein Plugin konfigurieren. Wobei?! Nochmal einen Schritt zurück. Wir bauen ein Plugin, dass man konfigurieren kann. Dabei ist es egal für welches Framework, CMS, Tool oder sonst was diese Erweiterung geschrieben wird. Wir nennen es einfach Plugin und wissen alle was wir meinen. Jetzt gehen wir mal davon aus, dass unser Framework schon ein paar Verzeichnisse vordefiniert. Sowas wie eine Pfad in dem man schreiben darf. Das ist eine Pflichtangabe. Ich kann also davon ausgehen, dass ich in jedem möglichen Plugin auf diese Variable zugreifen kann.
Wir schreiben unser Plugin und nutzen in unserem Source-Code also diesen allgemeinen Kopnfigurationparameter. Nööööö. Machen wir nicht. Vor kurzem sind wir nämlich in folgendes Problem gelaufen. Wir haben eine neue Infrastruktur aufgebaut, in der es auch neue Pfade gibt. Dummerweise ist sie so, dass User Generated Content (UGC) woanders hinkopiert wird, als redaktionell gepflegter. Sicherheit und so … ihr wisst schon. Jetzt mussten wir das ganze Projekt durchgehen und schauen, wo wir diese Pfade auseinanderziehen müssen. Ihr könnt euch ja denken, dass dies in einem großen Projekt (und es war ein großes) eine Menge Zeit in Anspruch nehmen kann. Hat es dann auch.
Was wir von Anfang an hätten machen müssen ist folgendes. Jedes Plugin hat die Möglichkeit alle seine Pfade selbst zu setzen. Natürlich kann es einen Fallback geben, dass sie, falls sie nicht gesetzt sind mit Standardwerten des Framework gefüllt werden. Kostet nur ein paar Zeilen Code, macht es aber viel flexibler. Wenn man Fallbacks gearbeitet wird, so steigt dadurch auch nicht der Konfigurationaufwand. Einfache Lösung und alle haben gewonnen. Ist jetzt kein Hexenwerk, aber oft denkt man an solche Dinge nicht, wenn man nicht selbst mal drauf reingefallen ist. Und deswegen schreibe ich es ja auch.
Jetzt wo ich mir den Artikel noch mal anschaue: Das gleiche gilt natürlich für alle Konfigurationsparameter. Egal ob Verzeichnis oder nicht.
„Jedes Plugin hat die Möglichkeit alle seine Pfade selbst zu setzen“ – auf welcher grundlage?
woher weiss dann ein plugin, was ein volatiles filesystem ist, das nicht gesichert wird und fuer tmp-daten geeignet ist, und woher wissen plugin1 und plugin2, dass sie in ein verzeichnis schreiben duerfen, welches generell fuer allen ugc geeignet ist?
meinst du sowas wie „Convention over Configuration“?
und inwiefern löst die neue vorgehensweise dein problem „Jetzt mussten wir das ganze Projekt durchgehen und schauen, wo wir diese Pfade auseinanderziehen müssen.“ – du muesstest zukuenftig jedes plugin nach seiner strategie verzeichnisse zu ermitteln prüfen.
Hab nen alternativen Vorschlag anzubieten:
Ich würde vorschlagen sich unterhalb des vom Framework vorgesehen Pfades zu halten und sich dort einen Plugin-spezifischen Unterpfad zu machen und darunter dann erst zu unterscheiden. Und diese Pfade unterhalb des Framework-Default-Pfads für das Plugin zu nutzen. Ggf sollte man dann gar nicht erst im Plugin eine Config ‚writeable_path‘ vom Framework für das Plugin umkonfigurieren sondern eher neue einführen a la
config:set(‚my_plugin_ugc_writeable_subpath‘) = $this->getPluginName().DIRECTORY_SEPARATOR.’ugc‘;
config:set(‚my_plugin_ugc_writeable_path‘) = config:set(‚writeable_path‘).DIRECTORY_SEPARATOR.config:get(‚my_plugin_ugc_wirteable_subpath‘);
//und das gleiche nochmal analog für redaktionellen Content
Analog machen es (zumind beim 1.4er) symfony-Plugins mit Assets.
Dadurch hat man weiterhin alle gleichartigen Daten in einem Pfad den man gleichartig administrieren, verarbeiten, auslagern oder sonst was mit tun kann.
Sonst verteilen Plugins ihre beschreibbaren Pfade auf zig Stellen und du hast eine ähnliche Hölle wie die von Dir beschriebene wenn man irgendwo Schreibrechte konfigurieren will, Backups aller generierten Daten vor einem Deployment basteln muss oder das ganze auf Netzlaufwerke auslagern muss um die App auf einem Webserver-Cluster laufen zu lassen.
@jeichhor: Da hab ich mich vielleicht ein wenig falsch ausgedrückt. In jedem Plugin kann separat konfiguriert werden, wo die Pfade liegen. Das Plugin weiß es also, weil man es ihm sagt. Wir wollen keine KI die das System danach scant, wo man schreiben kann.
@Jan: Bei uns hat diese Lösung leider nicht geklappt, da UGC und redaktioneller Content anders gepflegt und gebackuped werden und dadurch auch an ganz anderen Stellen im Dateisystem liegen.
————–
da UGC und redaktioneller Content anders gepflegt und gebackuped werden
————–
Hat das einen besonderen Grund?
@Ragtek: Um ehrlich zu sein … keine Ahnung. Ich gehe mal davon aus, dass es rechtliche Gründe haben kann.
@Nils: aber auch dann würde ich die 2 versch Pfade projektweit, also auf FW-Ebene, einführen und die Plugins darunter Subpfade nutzen lassen. Denn Du willst doch auch den UGC nicht aus 5 plugin-spezifischen Pfaden zusammensuchen. Und rein zufällig alle 5 Plugins die mit UGC rummachen gleich zu konfigurieren ist zerbrechlich.
Mein Anliegen ist einfach: In Plugins nur zu konfigurieren was auch nur für dieses eine Plugin und niemals ein andres nötig ist. Sowas wie UGC ist ja weitreichender, auch wenn es derzeit noch nur 1 Plugin betrifft, so lange es nicht „DAS“ UGC-Plugin ist, wird es ehe Du Dich versiehst ein 2. Plugin geben was entweder gleichartig konfiguriert werden muss oder die Konfig vom 1. Plugin mitverwenden muss; beides nicht grad soooo sauber.
Es sollte ja kein Problem sein Konfigurations-Werte auf Projektebene hinzuzufügen.
Bei uns noch komplizierter: durch Load-Balancer haben die Anwendungen gar kein Verzeichnis, in dem UGC abgelegt werden kann. Alles muss in die Datenbank. Außer vielleicht auf einem Developmentsystem.
In dem Fall löst man das Problem mit einem DataAdapter. Dabei kann man ein entsprechendes Interface implementieren oder eine abstrakte Klasse erweitern und wahlweise eine Datenbankanbindung, Dateisystem oder statische Daten (für Unit-Tests) liefern. Den DataAdapter gibt man dem Plugin über ein Dependency Injection. Natürlich über einen Manager, der sich um das Laden und Konfigurieren der Plugins kümmert.
Typisches Beispiel für eine abstrakte Datenquelle 😉
Ich stimme aber jeichhor zu. Du löst doch keins deiner Probleme. Ich finde das sogar schlimmer. Denn vorher gab es einen zentralen Platz für Konfigurationseinstellungen. Da hat das System dem Plugin den Speicherplatz zugewiesen. Jetzt kann jedes Plugin seinen eigenen Pfad bestimmen. Hoffentlich sagt ihr dem Praktikanten der anfängt wenn ihr alle das vergessen habt wo er die Files hinspeichern muss 😉
Für mich klingt es umständlicher und wartungsunfreundlich.
Du musst doch immer an die Stelle wo die Daten geschrieben werden bei Umstellungen. Dann doch lieber zwei Konfig-Pfade ala SYSTEM_PATH und USER_PATHS. Da weiß jeder was gemeint ist und wie er es zu benutzen hat.
Oder? 🙂
Irgendwie weiss ich nicht, worauf der Artikel hinauswill. Nach dem Nöööö bin ich ausgestiegen, weil der Anwnedungsfall sehr abstrakt dargestellt ist. Im Prinzip würde ich gültige Anwendungsverzeichnisse definieren (bspw. als Konstante [KISS – ‚Wissenschon]) und diese dann im Modul konventionell verwenden. Selbstredend mehrere Pfade, bspw. einen öffentlichen und einen Systempfad ausserhalb des doc root. Was die Applikation nicht kann, kann das Plugin nicht nutzen, so einfach scheint mir das zu sein. Wär ja noch schöner, wenn sich das Plugin diese Freiheiten herausnehmen darf.
Oder habe ich das Problem falsch verstanden?