Na ja.lck wrote:a, bitte nicht umsetzen. Mit obigen Code ist es relativ einfach das Backend anders zu gestalten.
Dann gäbe es vielleicht noch etwas eleganteres (einfacheres).cmb on Github wrote:Therefore it appears to be sensible to introduce respective abstractions as soon as possible.
Hm, so wie es ist, ist es aber dennoch fragil. Z.B. wurde in XH 1.7 ein eigenständiger Password-Ändern-Screen eingeführt – konsistent zum Rest mit der neuen Variable $xh_change_password. Wenn weitere solche Funktionen eingeführt werden, müsste immer wieder extern nachgebessert werden. Oder wenn z.B. der Linkchecker mal als Plugin ausgelagert wird, dann würde die Verwendung von $validate eine Notice erzeugen. Da sollte also schon eine Abstraktion angeboten werden. Die Frage ist halt wie detailliert diese nutzbar sein müsste. Mir sieht es so aus als ob das was hi_admin bezüglich des Admintemplates konfigurierbar macht, schon eher die Obergrenze darstellt.lck wrote:Ja, bitte nicht umsetzen. Mit obigen Code ist es relativ einfach das Backend anders zu gestalten. Und man kann sogar bestimmte Bereiche davon ausnehmen, wenn man vor der Variable ein ! setzt. Also zum Beispiel man möchte den Pagemanager im Vorschau-Modus anzeigen, dann braucht man nur $xhpages zu !$xhpages ändern.cmb wrote:Ja. So in dieser Art ist es auch bei hi_admin gelöst. Das ganze ist im Core ganz fürchterlich gelöst, und wenn wir viewtopic.php?f=29&t=13071 umsetzen würden, dann würden solche Lösungen nicht mehr möglich sein.
Wobei hi_admin im Originalzustand zum Beispiel 'xh_plugins' und 'xh_change_password' noch gar nicht berücksichtgt.cmb wrote:Mir sieht es so aus als ob das was hi_admin bezüglich des Admintemplates konfigurierbar macht, schon eher die Obergrenze darstellt.
Eben, Änderungen wird es immer wieder geben (hoffe ich auch) und die Nachbesserung wäre ja dann, in meinem Code, wirklich minimal.frase wrote:Wobei hi_admin im Originalzustand zum Beispiel 'xh_plugins' und 'xh_change_password' noch gar nicht berücksichtgt.
Auch da müsste jeweils nachgebessert werden (bei Neueinführung/Weglassen von Admin-Seiten).
Ja, ausser halt in der Vorschau und das ist halt nicht einfach so zu lösen, indem man $normal hinzufügt. Genau das möchte ich ja nicht!frase wrote:Verstehe ich das richtig?
Du möchtest immer adminedit.css aktiv haben, solange du im Admin-Modus bist?
Ja, wäre minimal. Aber zumindest mich nerven solche kleine Nachbesserungen, vor allem wenn sie an mehreren Stellen durchgeführt werden müssen. Die Plugin-Administrationsinkompatibilität habe ich schon gefühlte 231 mal gefixt, und es gibt immer noch Plugins, bei denen das noch aussteht …lck wrote:Eben, Änderungen wird es immer wieder geben (hoffe ich auch) und die Nachbesserung wäre ja dann, in meinem Code, wirklich minimal.
Im Template könntest du prüfen, ob $s >= 0 ist; falls ja, dann ist eine reguläre Seite gewählt. Bzw. halt umgekehrt, ob $s < 0 ist; dann handelt es sich um eine spezielle Seite.lck wrote:Ja, ausser halt in der Vorschau und das ist halt nicht einfach so zu lösen, indem man $normal hinzufügt. Genau das möchte ich ja nicht!frase wrote:Verstehe ich das richtig?
Du möchtest immer adminedit.css aktiv haben, solange du im Admin-Modus bist?
Code: Select all
if (XH_ADM && ($edit || $normal || "ausser Vorschau")) {
echo '<link rel="stylesheet" type="text/css" href="'.$pth['folder']['template'].'adminedit.css">'."\n";
} Code: Select all
if (XH_ADM && ("ausser Vorschau")) {
echo '<link rel="stylesheet" type="text/css" href="'.$pth['folder']['template'].'adminedit.css">'."\n";
}