+1
Das könnte möglicherweise schwierig werden. Das Problem: CMSimple_XH weiß oft nicht, was eigentlich passiert. Typisches Beispiel sind die Plugin-Administrationsseiten; die Gestaltung des Content-Bereichs obliegt vollständig dem jeweiligen Plugin, und CMSimple_XH erkennt selbst nachdem das Plugin am Werk war, nur, dass irgendwelche Ausgaben erzeugt wurden, weiß aber eben nicht mal dann, um was es sich handelt. Daher müsste man es wohl den Plugins überlassen, den Container korrekt zu erzeugen, oder CMSimple_XH müsste ein bisschen raten. Okay, letzteres ist vielleicht kein wirkliches Problem, weil man annehmen könnte, dass im Adminmodus ein ?plugin=… eben die Pluginadministration aufruft (ist nicht zwingend so, aber in aller Regel halten sich Plugins daran). Und die Administration des Core ist ja einigermaßen im Voraus bekannt.
Ich arbeite mal einen Patch aus, der die .xhContainer erzeugt.
Was ich subotimal finde, ist dass .xhContainer und Co. jede Menge mögliche Einstellungen zurücksetzen (müssen) – kommt mir jedenfalls so vor. Da wäre aber längerfristig vielleich das Shadow-DOM eine Hilfe.
Die Filebrowser-Templates rufen schon lange nach einer Überholung. Was mich da u.a. sehr stört, ist die Mischung von PHP-Tags, und %PLATZHALTER%n – entweder, oder (ich würde erstere bevorzugen). Und ich frage mich, ob man die beiden Templates nicht sinnvoll zu einem einzigen zusammenfassen kann.