.. bevor die Zeit ablaeuft.
Stimmt das ungefaehr?
Was ich aber nicht glauben kann, so ein Konstrukt habt ihr auf einer Shared Umgebung, engl.
Shared Hosting, aufgebaut? Reicht die Leistung? Wie ist es mit der Bedienung, "Panel" sprich GUI, oder habt ihr eine echte Shell.
Wenn das so stimmt, habt ihr eine Regel, die immer wieder auf engl.
Forum wiederholt wird,
wwwroot programmatisch zu bestimmen sei nicht unterstuetzt, gebrochen. Dann kann man z.B. keinen ueblichen
Cron-Job, d.h. mit PHP-CLI laufen lassen - der kennt diese HTTP-Parameter nicht. Man ist gezwungen cron.php von aussen via HTTP(S) aufzurufen, und damit auf webbasierte PHP (PHPCGI) auszuweichen, die mehrfach langsamer als direkte PHP-CLI ist. OK, das habt ihr hingekriegt.
Neu kommt eben diese Trennung vom Moodle-Code in zwei: von einem "oberen" (oberhalb von DocumentRoot) Teil und public/, welche direkt unter DocumentRoot ansprechen soll. Das alleine kann man auch mit Datei-Links hinkriegen.
Aaaber, ob beides zusammen geht, das bezweifele ich. Ich sage nicht, dass es nicht geht, irgendwie sollte es schon gehen. Aber nicht vergessen, die Entwickler arbeiten aktiv gegen solche Konstrukte, eben nach ihrer meinung "unsicher". (Das habe in Frage gestellt, aber gegen Mauer gelaufen. Darueber zu reden ist es wirklich zu spaet.)
Vielleicht der Wechsel 4.5 > 5.1 die Gelegenheit die Architektur unter der Lupe zu nehmen und gegebenfalls auch nachhaltiger aufbauen. Ich meine, mit 1300 Moodle-Instanzen betreibt ihr ein Mini-MoodleCloud! Sie machen es mit Docker. Genaue Rezepte existieren nicht, das ist ihr Handwerk. Bekanntlich ist Moodle nicht gerade Docker-freundlich, hauptsaechlich wegen diesem moodledata/ "Mehrzweck"verzeichnisbaum.
Also wie am Eingang gewarnt, eine Loesung habe ich nicht. Vorerst mal das (meine) Bild bereinigen, damit andere da einsteigen koennen. Die Frage reizt mich schon, darf ja nicht anfangen!