Uups. Da gibt es wieder viel zu antworten.
Zunächst möchte ich euch erstmal wieder auf den neuesten Stand bringen.
Hier die aktuellste Version des Admin-Templates. Einfach im Template-Odner ersetzen:
hi-admin_01---02.zip
Und, ich muss wohl nochmal erklären, was das Ganze eigentlich soll.
Also:
Ziel ist es, die Bedienoberfläche von XH zu modernisieren und zu vereinheitlichen.
Wenn möglich, sollten bisher bestehende Style-Konflikte vermieden werden.
Holgers hi_admin-Plugin bedient den zweiten Punkt schon ziemlich gut.
Ich stelle mir vor, dass am Ende zumindest die wichtigsten Elemente des Plugins in den Core übernommen werden.
Ich bin allerdings kein Programmierer. Deshalb konzentriere ich mich hier darauf, das spätere
Aussehen des Adminbereichs zu simulieren und zu präsentieren - als Möglichkeit/Angebot.
Die (
alters historisch bedingten) Schwächen von hi_admin kann und werde ich nicht korrigieren.
Auch Problemstellen im Core rühre ich nicht an (bis auf die kleine Korrektur in admin.min.js).
Was ich momentan tue ist, mithilfe eines Templates alles soweit hinzubiegen, dass man sich vorstellen kann, wie es später mal aussehen
könnte. Dabei ist das Plugin eine gute Hilfe - und sollte es schiefgehen, ist nichts kaputtgemacht.
Dann könnte man mit anderen Templates weitermachen, bis eine Lösung gefunden ist, die allen gefällt.
cmb wrote:Hm, diese Feinheiten erscheinen mir überflüssig bzw. nicht wirklich passend. Ich denke, es sollte genügen (und sehr viel Flexibilität ergeben), wenn Plugins ihre Ausgabe in ein <div class="…"> einschließen ...
Es geht ja nicht nur um Plugins, sondern auch um den Core.
Beispiel:
Bei beinahe allen Konfig-Optionen steht am Ende: <input class="submit" value="Sichern" type="submit">
Bei "Passwort ändern" steht am Ende: <button name="action" value="save">Sichern</button>
Also einmal Input und einmal Button.
Mit "Regeln für Programmierer" meinte ich, dass sowas vereinheitlicht werden könnte/sollte.
Das Admin-Template könnte letztendlich auch dazu dienen ein "Style Guide" zu bieten, wo jeder sehen kann was passiert/ wie sieht es aus, wenn Input oder Button ... usw. verwendet wird.
Außerdem müssen auch die Listen unter "Einstellungen", "Plugins", "Links prüfen" ... usw. irgendwie benannt werden - zum unterscheiden.
cmb wrote:
(betrifft Filebrowser)
Das hat aber eigentlich mit dem Gestalten nichts zu tun. Was stört dich konkret?
Gar nichts. Ich habe es nur nicht geschafft den Filebrowser wie die anderen Sachen "optisch umzubiegen" (Icons ...).
Das ist zu diesem Zeitpunkt aber auch gar nicht nötig. Die Templates will ich nicht anfassen, es soll ja erstmal alles bleiben wie es ist und auch ohne Admin-Template sauber weiter funktionieren.
(Beim Pagemanager konnte ich eingreifen - gesehen?)
cmb wrote:Zurzeit wird dieses Select-Menü wohl per hiAdmSelectNav() im Template erzeugt (könnte man nicht XH\Pages::linkList() verwenden?); man könnte es aber auch direkt im Plugin erzeugen lassen, und es an $bjs. anhängen
Richtig.
Bin mir allerdings immer noch nicht ganz sicher, ob das wirklich viel Nutzen bringt. Theoretisch sollte das Seiten-Template auch im Admin-Modus ein bedienbares Menü bieten.
Allerdings: Sollte das verschiebbare Select-menü standardmäßig immer vorhanden sein, dann könnten sich Template-Entwickler darauf verlassen ...
You do not have the required permissions to view the files attached to this post.