Was muss ich genau machen, um den Cache von Modul-Informationen vollständig zu löschen? Bisher lösche ich immer das tmp/ Verzeichnis per # rm !(.) (und einmalig shopt -s extglob vorweg), aber das reicht oft nicht. Mein Workaround bisher: Modul in einen Ordner modules-inactive verschieben, im Backend die Erweiterungen anzeigen lassen und falls das Modul Klassen überschreiben sollte, findet man dann jetzt dort einen Button, um die Infos zu löschen. Dann das Modul zurückschieben. Aber das kann es ja nicht sein…
Danke. Das hat bei mir zu einer Fehlermeldung geführt auf der Modul-Seite im Backend. Irgend ein Parameter sei kein Array. Ich hab dann im Quellcode (im Core) ein (array) vor die Variable gesetzt und ich glaube, dann gings ohne weitere Kopfstände. Ich frag mich, was das soll? Im Entwicklungsmodus kann man doch nun wirklich nichts mit solchen Caches anfangen. Ich schau mal, ob ich die Stelle finde, in der das Zeug ausgelesen wird.
Wobei ich das nicht so ganz verstehe, um ehrlich zu sein. Beim Aktivieren des Moduls werden die Parameter in die Datenbank geschrieben, richtig. Wenn ich die Moduldateien (den Modulordner) lösche, Werde ich beim Aufruf von “Extensions” im Admin gefragt, ob die Parameter des Moduls wieder gelöscht werden sollen. Das passiert - zumindest in meiner Umgebung - zuverlässig.
Ja, das stimmt. Das heißt aber auch, dass der Workflow, wenn man an der metadata.php etwas rumschrauben muss so aussieht:
Modulverzeichnis umbenennen
Modul-Seite im Backend aufrufen
Auf den Button klicken
Module-Seite wieder zurück benennen
Und, das Ganze funktioniert nur, wenn Klassen überschrieben werden, meine ich. Andernfalls merkt die View im Backend gar nicht, dass das Modul fehlt. Oder irgendwie so war das, meine ich.
So oder so lässt sich damit nicht gescheit arbeiten. Mit dem Modul musst Du dann immernoch das Modul deaktivieren und wieder aktivieren, aber das geht zumindest einmal einiges schneller, zumal wenn Du die Seite im Backend offen lassen kannst. Nervig bleibt es allemal. Aber jetzt bei jedem Request im Dev-Modus die metadatas neu einlesen war mir für den Moment zu viel Aufwand. Wäre aber sicherlich die feinere Variante.
Na ja. Wir hatten das vorher anders (bevor Du zu uns gestossen bist) und die Änderung auf das neue Modul-System wurde eigentlich mit einem grossen Hallo begrüßt.
Hast Du Ideen dazu, was kann anders gemacht werden, damit sowohl der dev als auch die Anwender sich wohlfühlen?
Die Modulinfos werden bei jedem Request komplett aus den Modulverzeichnissen ausgelesen und zusammen mit den Infos aus der Datenbank werden dann die Arrays im Config-Objekt zusammengebaut. Das alles wird gecacht und der Cache kann mit einem Button im Backend gelöscht werden. Im Dev-Modus ist der Cache prinzipiell abgeschaltet.
Performance-technisch wäre das kein Nachteil. Man packt die kompletten Modul-Einstellungen (also den Cache der eingelesenen Werte) in einen JSON-String oder so und steckt es in memcached oder in die DB bei verteilten Systemen oder in eine Datei eben. Und fürs Entwickeln sind die paar Millisekunden absolut irrelevant.
Weiter könnte man das noch dahingehend verbessern, indem man die Überschreib-Klassen immer im Modul definieren muss und ggf. in der config.inc.php überschreibt oder ergänzt. Dort wird ebenfalls definiert, welche Module aktiv sind. Auch die Reihenfolge der Modulklassen wird in der config.inc.php gesetzt, dort, wo sie eine Rolle spielt. Im Backend wird lediglich die im Backend einstellbare Konfiguration der Module (Settings) gespeichert.
Ein Shop-Betreiber wird sicherlich keinen lokalen Testserver einrichten und im laufenden Betrieb auf dem Produktivsystem ein Modul im Backend anzuklicken … gibt dann diese Notruf-Anrufe oder -E-Mails, die man besonders mag. Also überlässt man die Modulzusammenstellung doch besser den Entwicklern und gewinnt dadurch auch noch eine Abspeckung des Backends. Ist für mich ohnehin nicht nachvollziehbar, wie man im Backend per Default z.B. den Menüpunkt Erweiterungen und Stammdaten und so etwas über den Bestellungen, den Benutzern und der Artikelverwaltung platziert. Ich meine, die tägliche Aufgabe eines Shop-Betreibers sind die Bestellungen, Kunden, Artikel, Kategorien. Aber doch nicht die Stammdaten oder Themes. Ich weiß nicht, was für eine Idee dahinter steckt. Und genau so wenig kann ich nachvollziehen, warum man ein Backend brauchen soll, um Module neu einzuladen. Man kommt da einfach schwer dran, wenn ein Modul einem das Backend zerschossen hat… und es ist aus meiner Perspektive eben absolut kein Vorteil, denn, wie gesagt ein Shop-Betreiber ist gut beraten, da nicht herumzuklicken im Produktivsystem.
[QUOTE=toxid;102080]…dort passiert halt nichts, wenn ich das Modul erweitere…[/QUOTE]
Doch: schick mir einen Pull-Request, dann kann ich das übernehmen. Das schöne dort ist: Je zentralisierter wir das hinbekommen, desto viraler wird es, desto größer ist die Chance, dass jemand mitarbeitet.
Gibt es eigentlich einen einfachen Weg, eine Liste aller installierten (aktivierten) Module zu erhalten? Ich habe bisher die Namen aller Unterverzeichnisse von Modules in ein Array gepackt und irgendwo gab es dann ein Array in der Config, das alle deaktivierten Module enthalten hat. Aber die Verzeichnisnamen müssen ja nicht zwingend die Bezeichnungen der Module sein, oder?
müssen sie nicht, es gibt auch vendor Ordner, in dem dann mehrere Module liegen können.
in der oxconfig gibts aInstalledModules und aDisabledModules, du musst aber von aInstalledModules die aDiabledModules “subtrahieren”, damit nur die aktiven bleiben
[QUOTE=vanilla thunder;104833]müssen sie nicht, es gibt auch vendor Ordner, in dem dann mehrere Module liegen können.
in der oxconfig gibts aInstalledModules und aDisabledModules, du musst aber von aInstalledModules die aDiabledModules “subtrahieren”, damit nur die aktiven bleiben[/QUOTE]
aInstalledModules habe ich in der Config nicht gefunden, aDisabledModules schon.
Ich habe das Modul jetzt dahingehend angepasst, dass die Modul-Infos bei jedem Request neu eingeladen werden - abgesehen von den Modul-Settings. Ich habe aus Deinem Modul, “vanilla thunder” lediglich 2, 3 Zeilen Code übernommen, den man eh nicht anders schreiben kann, daher steht das Modul nach wie vor unter der MIT-Lizenz.
