Mahlzeit,
ich wollte mal hören, wer das Problem kennt, dass sich unter bestimmten Umständen die OXID-Modulverwaltung verschluckt, und fälschlicherweise den Namen eines Vendor-Ordners (innerhalb /modules) in die config-Var aDisabledModules schreibt!? Beispiel:
Es gibt den Ordner /modules/wendnet, und dort liegen meine Module. Wenn nun durch eine Art Fehlbedienung (z.b. fehlende vendormetadata.php) dieser “Bug” ausgelöst wird, bewirkt dies, dass [B]alle[/B] wendnet-Module disabled sind, obwohl sie im Backend auf grün stehen! Aber unter “Installierte Shop-Module” ist halt alles durchgestrichen… :eek:
Das ist nämlich ziemlicher Käse und passiert auch meinen Kunden ab und zu. Das schlimmste ist halt: mir ist kein Weg bekannt, es mit Boardmitteln wieder zu flicken, und man könnte auf den falschen Gedanken kommen, das Modul ist buggy, grmpf!
Also hieß die Devise mal wieder: mitmachen, und dabei kam ein kleines Script heraus, welches man im Shop-Basedir aufrufen kann, um [B]aDisabledModules[/B] automatisch von allen “falschen” Vendor-Ordnern zu bereinigen (nicht nur wendnet). Und ja ich weiß, es hätte auch im Github landen können, ist es aber nicht… 
Mir geht es erstmal mehr um die Diskussion, ob bekannt, was (in)offiziell dazu geplant ist oder was man sonst tun kann, um das Problem möglichst zu umschiffen. Aber hier mal das Scriptchen:
Hi,
[QUOTE=Mitmacher;120448]ob bekannt, was (in)offiziell dazu geplant ist oder was man sonst tun kann, um das Problem möglichst zu umschiffen.[/QUOTE]
Mach am besten mal einen Bug dazu auf.
Danke und Gruß
[QUOTE=Mitmacher;120448]Und ja ich weiß, es hätte auch im Github landen können, ist es aber nicht… ;)[/QUOTE]
…macht nix - kanns ja noch 
Eventuell wäre das ja was zur Erweiterung hierfür? Da sind schon so manche nützliche “Krücken” drin gelandet: https://github.com/vanilla-thunder/vt-devutils
@marco:
Ja klar, wenn es denn ein Bug ist. Das Ding ist, ich weiß bisher nicht, wie man es am besten reproduziert. Ich glaube man muß im Backend fehlende Module löschen, wenn gleichzeitig ein Vendor-Ordner existiert, wo eben keine vendormetadata drin liegt (z.b. beim Kopieren vergessen). Das ist evtl. aber noch zu schwammig für den Bugtracker, oder?
@ray:
Yep, da bin ich vorher auch schon drauf gestoßen, und richtig: es braucht sicherlich nur ein cooles Cleanup-Tool für alle Modul-Workarounds. Aber mein Script existierte auch schon eine Weile und ich wollte wenigstens eine getrennte Debatte dazu starten. Das vt-Tool ist definitiv eine gute Idee, aber man kann sich notfalls (umständlich) auch ohne behelfen. Mein geschildertes Probleme konnte ich bisher nur durch einen beherzten DB-Eingriff korrigieren, von daher räume ich dem erstmal eine höhere Priorität ein.
Übersehe ich aber evtl. noch einen anderen Workaround? Und vor allem: lasst mich bitte nicht wieder (fast) der einzige mit diesem Problem sein (ich scheine da echt eine Ader für zu haben)! :o
PS: es betrifft übrigens wohl alle OXID-Versionen seit 4.6.0
PPS: mir kam noch eine Stück Erleuchtung: es ist eine Art Henne-und-Ei-Problem, da einem die Abwärtskompatibilität dazwischen funkt. Es werden ja immer noch alte Module berücksichtigt, die [B]keine[/B] metadata.php haben. Und da stellt sich die Frage, wie man solch einen Modul-Ordner von einem Vendor-Ordner (ohne vendormetadata) unterscheiden will. Kann ja gar nicht gehen, also muss man wohl echt anders herum denken, und wie @vt halt die nachträgliche Prüfung optimieren. Spätestens, wenn wieder eine vendormetadata vorhanden ist, müsste der Eintrag aus aDisabledModules automatisch verschwinden, dann wäre wohl alles gut.