Schönere Gestaltung des klassischen Pluginmenüs
Schönere Gestaltung des klassischen Pluginmenüs
Ich setze mal die Diskussion bezüglich des klassischen Pluginmenüs aus https://cmsimpleforum.com/viewtopic.php ... =20#p62819 hier fort, damit der andere Thread nicht allzu unübersichtlich wird.
Zur Klarstellung: mit "klassischem Pluginmenü" ist dasjenige gemeint, dass bei den meisten Plugins oben im Content-Bereich in der Pluginadministration angezeigt wird.
Dieses sieht bei den meisten (zumindest neueren) Templates sch… aus! Das würde ich aber ungern auf die Templatedesigner abwälzen – zumindest per Default könnte es ja schon vernünftig durchgestylt sein. Der Templatedesigner oder Webmaster kann dann nach Wunsch immer noch nachbessern.
Das Hauptproblem ist vermutlich die unglückliche Struktur. Die meisten Plugins zeigen eine Zeile an, die als einzeilige Tabelle dargestellt wird. Manche Plugins nutzen aber zwei Zeilen (mehr ist mir noch nicht begegnet, aber zumindest möglich), und diese werden als zwei einzeilige Tabellen dargestellt.
Vielleicht ist es wichtig zu erklären, wie Plugins dieses Menü erzeugen. Die meisten Plugins, die keine besonderen Anforderungen an das Menü stellen, rufen einfach print_plugin_admin() auf. Einige wenige, die eben zusätzliche Menüpunkte anbieten möchten (z.B. Register_XH), rufen i.d.R. zusätzlich noch mehrfach pluginMenu() auf, um eine Zeile (ROW) mit den nötigen Zellen (TAB) zu erzeugen. Ein Aufruf mit DATA ist mir noch nicht untergekommen. Diese API ist grausig, kann aber aus Kompatitbilitätsgründen zunächst mal nicht geändert werden – das soll also nicht Thema dieses Threads sein.
Geht man also davon aus, dass die meisten Plugins das Pluginmenü komplett automatisch erzeugen lassen (print_plugin_admin) und die anderen Plugins nur zusätzliche Zeilen mit Menüpunkten per pluginMenu(ROW/TAB) erzeugen, dann könnte man auf die einzeiligen Tabellen ganz verzichten. Letztlich sehe ich noch nicht einmal einen besonderen Sinn darin, dass ein Plugin das Menü auf mehrere Zeilen aufteilt – soweit ich es überblicke erfolgt das wirklich nur um die API-Aufrufe möglichst einfach zu halten.
Sprich, das erzeugte HTML könnte zu einem klassischen <ul> ohne Verschachtelung geändert werden. Diese könnte dann wie von anderen Menüs gewohnt gestylt werden. Die einzige Abwärtskompatibilität, die dadurch verloren ginge, wären eben vom Template durchgestylte Pluginmenüs, aber das erscheint verkraftbar.
PS: Ich hatte ganz verdrängt, dass es pluginMenu() auch erlaubt, individuelle Inline-Styles zu definieren, die u.U. vordefinierte Inline-Styles überschreiben. Djots Example Plugin macht davon Gebrauch; mir ist aber nicht bekannt, dass diese Möglichkeit auch von echten Plugins genutzt wird.
Zur Klarstellung: mit "klassischem Pluginmenü" ist dasjenige gemeint, dass bei den meisten Plugins oben im Content-Bereich in der Pluginadministration angezeigt wird.
Dieses sieht bei den meisten (zumindest neueren) Templates sch… aus! Das würde ich aber ungern auf die Templatedesigner abwälzen – zumindest per Default könnte es ja schon vernünftig durchgestylt sein. Der Templatedesigner oder Webmaster kann dann nach Wunsch immer noch nachbessern.
Das Hauptproblem ist vermutlich die unglückliche Struktur. Die meisten Plugins zeigen eine Zeile an, die als einzeilige Tabelle dargestellt wird. Manche Plugins nutzen aber zwei Zeilen (mehr ist mir noch nicht begegnet, aber zumindest möglich), und diese werden als zwei einzeilige Tabellen dargestellt.
Vielleicht ist es wichtig zu erklären, wie Plugins dieses Menü erzeugen. Die meisten Plugins, die keine besonderen Anforderungen an das Menü stellen, rufen einfach print_plugin_admin() auf. Einige wenige, die eben zusätzliche Menüpunkte anbieten möchten (z.B. Register_XH), rufen i.d.R. zusätzlich noch mehrfach pluginMenu() auf, um eine Zeile (ROW) mit den nötigen Zellen (TAB) zu erzeugen. Ein Aufruf mit DATA ist mir noch nicht untergekommen. Diese API ist grausig, kann aber aus Kompatitbilitätsgründen zunächst mal nicht geändert werden – das soll also nicht Thema dieses Threads sein.
Geht man also davon aus, dass die meisten Plugins das Pluginmenü komplett automatisch erzeugen lassen (print_plugin_admin) und die anderen Plugins nur zusätzliche Zeilen mit Menüpunkten per pluginMenu(ROW/TAB) erzeugen, dann könnte man auf die einzeiligen Tabellen ganz verzichten. Letztlich sehe ich noch nicht einmal einen besonderen Sinn darin, dass ein Plugin das Menü auf mehrere Zeilen aufteilt – soweit ich es überblicke erfolgt das wirklich nur um die API-Aufrufe möglichst einfach zu halten.
Sprich, das erzeugte HTML könnte zu einem klassischen <ul> ohne Verschachtelung geändert werden. Diese könnte dann wie von anderen Menüs gewohnt gestylt werden. Die einzige Abwärtskompatibilität, die dadurch verloren ginge, wären eben vom Template durchgestylte Pluginmenüs, aber das erscheint verkraftbar.
PS: Ich hatte ganz verdrängt, dass es pluginMenu() auch erlaubt, individuelle Inline-Styles zu definieren, die u.U. vordefinierte Inline-Styles überschreiben. Djots Example Plugin macht davon Gebrauch; mir ist aber nicht bekannt, dass diese Möglichkeit auch von echten Plugins genutzt wird.
Last edited by cmb on Sun Oct 22, 2017 2:45 pm, edited 1 time in total.
Reason: PS hinzugefügt
Reason: PS hinzugefügt
Christoph M. Becker – Plugins for CMSimple_XH
Re: Schönere Gestaltung des klassischen Pluginmenüs
Tja, leider wird man die Zeilen nicht zusammenführen können (jedenfalls nicht ohne JS-Tricksereien), aber nach wie vor erscheinen einzeiligen Tabellen wenig sinnvoll. Ich habe diese daher in einem Feature Branch mal durch <ul>s ersetzt. Das ergibt allerdings wieder die üblichen Listenprobleme bei manchen Templates; vielleicht wären daher <div> mit <span> oder verschachteltem <div> sinnvoller.
Jedenfalls habe ich die CSS Klasse edit erst mal beibehalten; sie sitzt jetzt halt im <ul> statt wie zuvor in der <table>. Vielleicht sollte man die Klasse auch gleich umbenennen – xh_pluginmenu o.ä. böte sich an.
Vielleicht mag einer der mitlesender Designer hier mal gestalterisch tätig werden?
Jedenfalls habe ich die CSS Klasse edit erst mal beibehalten; sie sitzt jetzt halt im <ul> statt wie zuvor in der <table>. Vielleicht sollte man die Klasse auch gleich umbenennen – xh_pluginmenu o.ä. böte sich an.
Vielleicht mag einer der mitlesender Designer hier mal gestalterisch tätig werden?
Christoph M. Becker – Plugins for CMSimple_XH
Re: Schönere Gestaltung des klassischen Pluginmenüs
Gerne. Aber ...cmb wrote:Vielleicht mag einer der mitlesender Designer hier mal gestalterisch tätig werden?
Ich denke, dein Ansatz ist richtig.
Die Klasse ".edit" verfluche ich schon, seit es sie gibt.
Bin aber im Moment mit einem "konfigurierbaren Template" beschäftigt. Und eine Abend-Atzung meines Körpers steht auch noch an
Also: Bitte etwas Geduld. Antwort kommt. Fraglich wann.
Re: Schönere Gestaltung des klassischen Pluginmenüs
Nicht schlecht! Da sind ja Sachen dabei, die sind ja echt interessant. Ich könnt mich manchmal in den Po kneifen. Vielen Dank für das Thema und die Links. Ich zieh mir das erstmal in Ruhe reín. Manches wusste ich schon, doch alle Themen habe ich aus Mangel an Zeit mir nie angeschaut.
Aber man lernt ja nie aus.
Die Klasse edit verfluche ich z.Bsp überhaupt nicht. Warum auch?
Aber man lernt ja nie aus.
Die Klasse edit verfluche ich z.Bsp überhaupt nicht. Warum auch?
Re: Schönere Gestaltung des klassischen Pluginmenüs
Mit Klasse .edit:cmb wrote:Ich habe diese daher in einem Feature Branch mal durch <ul>s ersetzt. Das ergibt allerdings wieder die üblichen Listenprobleme bei manchen Templates;
Code: Select all
.edit {
display: table;
width: 100%;
}
.edit li {
display: table-cell;
text-align: center;
background-color: #ff6600;
line-height: 2rem;
}
.edit li:not(:last-child) {
border-right: 2px solid #fff;
}
.edit li:before {
content: none !important;
}
.edit li a {
border: 0 none transparent;
color: #fff;
display: block;
}
.edit li a:hover {
color: #212121;
}
Code: Select all
<div class="xh_pluginmenu">
<ul>
<li>...</li>
...
</ul>
</div>
Code: Select all
.xh_pluginmenu ul {
display: table;
width: 100%;
}
.xh_pluginmenu li {
background-color: #ff6600;
display: table-cell;
font: 14px/2 Arial, sans-serif;
text-align: center;
}
.xh_pluginmenu li:not(:last-child) {
border-right: 2px solid #fff;
}
.xh_pluginmenu li:before {
content: none !important;
}
.xh_pluginmenu li a {
border: 0 none transparent;
color: #fff;
display: block;
}
.xh_pluginmenu li a:hover {
color: #212121;
}
Das wird uns Frank bestimmt noch sagen. Bisher hatte ich auch keine Probleme damit.knollsen wrote:Die Klasse edit verfluche ich z.Bsp überhaupt nicht. Warum auch?
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“ Ludwig's XH-Templates for MultiPage & OnePage
Re: Schönere Gestaltung des klassischen Pluginmenüs
Ich war bisher eigentlich damit zufriedencmb wrote:Zur Klarstellung: mit "klassischem Pluginmenü" ist dasjenige gemeint, dass bei den meisten Plugins oben im Content-Bereich in der Pluginadministration angezeigt wird.
Dieses sieht bei den meisten (zumindest neueren) Templates sch… aus!
„Bevor du den Pfeil der Wahrheit abschießt, tauche die Spitze in Honig!“ Ludwig's XH-Templates for MultiPage & OnePage
Re: Schönere Gestaltung des klassischen Pluginmenüs
Upps – ich wollte eigentlich keine Werbung für pluginMenu() machen. Wie gesagt, die API ist grausig! Plugins, die pluginMenu() schon nutzen – okay, aber ich würde es bei neuen Plugins nicht verwenden. Alternative: die (zusätzlichen) Menüpunkte nur per XH_registerPluginMenuItem registrieren, oder bei den "Main-Settings" (print_plugin_admin('on')), oder direkt beim Aufruf des Plugins (bei meinen Plugins meist ein Info-Screen) ein eigenes Menü einblenden.knollsen wrote:Vielen Dank für das Thema und die Links. Ich zieh mir das erstmal in Ruhe reín. Manches wusste ich schon, doch alle Themen habe ich aus Mangel an Zeit mir nie angeschaut.
Aber man lernt ja nie aus.
@lck: danke! Auf jeden Fall viel besser als bisher. Aber: ist ein tabellenartiges Layout wirklich gewünscht? Zumindest bei mehreren Zeilen sieht das komisch aus:
Hängt natürlich vom Template ab. Bei fhs-simple sieht es derzeit so aus: Geht IMHO gar nicht. Bei lck_overlay_02: Besser, weil wenigstens die Links nicht unterstrichen sind. Aber warum klebt der linke Menüpunkt am linken Rand, aber der rechte hat so viel Abstand zum rechten Rand? Warum haben nicht einfach alle Menüpunkte die gleiche Breite? Ist natürlich Geschmackssache (und sicher auch nicht das wichtigste Thema), aber ich finde, das Pluginmenü wurde bei der Einführung des Adminmenüs in CMSimple_XH 1.5 irgendwie übersehen, und das sollte mal nachgeholt werden. Vor dieser Version waren die beiden Menüs wenigstens konsistent: Vielleicht ist der konsequente Weg ja doch das Pluginmenü ins Adminmenü zu verschieben, und das klassische Pluginmenü aussterben zu lassen. Ich hätte zumindest nichts dagegen, print_plugin_admin() und pluginMenu() ab CMSimple_XH 1.8.0 weich (d.h. nur per Dokumentation, aber ohne Warnung) zu missbilligen, in einer späteren Version 1.x dann auch eine Deprecated-Warning auszugeben, und die Funktion für XH 2.0.0 ganz zu entfernen (könnte in cmsimple/compat.php für eine Weile erhalten bleiben).lck wrote:Ich war bisher eigentlich damit zufrieden
You do not have the required permissions to view the files attached to this post.
Christoph M. Becker – Plugins for CMSimple_XH
Re: Schönere Gestaltung des klassischen Pluginmenüs
Au Backe.
Da sind wir ja wieder mal an einem kritischen Punkt angekommen.
Seit ich hier im Forum aktiv bin (ca. 1 1/2 Jahre), versuche ich auf diese Problematik hinzuweisen.
Zunächst die Klasse ".edit". Da bin ich noch eine Erklärung schuldig:
(core.css)
Und weil wir gerade dabei sind: Es gibt noch mehr solche Kandidaten (hier vor allem ".text"):
Hier werden also Schriftarten, Schriftgrößen, Farben und anderes festgeschrieben, die sich beinahe immer mit dem gerade aktiven Template "beißen" werden.
Alle CMS- und Plugin-Einstellungen spielen sich im content()-Bereich ab. Listen, Formulare, Links, Buttons ... und und und ... werden also immer von DREI Stylesheets beeinflusst: Core, Plugins und Template.
CMSimple_XH zeichnet sich ja u.A. dadurch aus, dass man sozusagen direkt in der eigenen Seite bearbeitet. Für die Bearbeitung der Seiten(-Inhalte) selbst finde ich das auch wirklich super.
Ich frage mich aber, warum die diversen Einstellungen auch noch unter dem Template-Layout und -Style bearbeitet werden sollen.
Da können wir noch Jahre herumfummeln und Krücken bauen - es wird immer wieder zu Stylekonflikten kommen.
Nun gut. Ich weiß ja auch, welche Probleme daran hängen. Hier war nun aber genau der richtige Zeitpunkt, mal wieder darauf hinzuweisen.
Zurück zum Plugin-Menü.
Da wir ja nicht hexen und oben beschriebene Probleme einfach wegzaubern können, müssen wir vorerst rumbasteln.
Ludwigs Lösungsvorschlag mit Klasse "xh_pluginmenu" scheint mir unter diesen Umständen am sinnvollsten.
Ich habe mal in allen 3 verfügbaren Templates Ludwigs Style-Definitionen (allerdings noch für ".edit") eingefügt.
Es ist ein Kompromiss, der eine gewisse Allgemein-Gültigkeit hat. Über Farbe kann man noch reden. Die Schrift bleibt bei "Arial 14px", ist nicht schön und ist auch nicht dynamich (kleine/große Viewports).
Deutlich zu sehen sind die Beeinflussungen durch die jeweiligen Templates. Mal haben die ULs einen Abstand unten, mal ein Padding links (lck).
Da gibt es nur zwei Möglichkeiten:
1. So lassen und mit den Mängeln leben.
oder
2. Der Template-Designer schreibt in sein Template noch extra-Definitionen für ULs in Plugins, in Pagemanager, in Filebrowser und für alle anderen Fälle. Das dann auch noch für DLs, für INPUTs, ... usw.
Das habe ich bei fhs-simple (und auch anderswo) zumindest für Listen und den Pagemanager gemacht.
Ihr seht also: Alles nicht so einfach
Ohne eine entscheidende Änderung bleibt alles Frickelei und Notlösung.
Da sind wir ja wieder mal an einem kritischen Punkt angekommen.
Seit ich hier im Forum aktiv bin (ca. 1 1/2 Jahre), versuche ich auf diese Problematik hinzuweisen.
Zunächst die Klasse ".edit". Da bin ich noch eine Erklärung schuldig:
(core.css)
Code: Select all
.edit {
font-family: arial, sans-serif;
font-size: 14px;
line-height: 1.2em;
border: 1px solid;
margin: 2px 0;
}
.edit td {
padding: 4px 6px;
}
Code: Select all
.text, .xh_captcha_input, .xh_mailform textarea {
font-family: "Lucida Sans Unicode", "Lucida Grande", sans-serif;
font-size: 13px;
color: #222;
background-color: white;
padding: 2px 4px;
margin: 0 0 2px 0;
}
Alle CMS- und Plugin-Einstellungen spielen sich im content()-Bereich ab. Listen, Formulare, Links, Buttons ... und und und ... werden also immer von DREI Stylesheets beeinflusst: Core, Plugins und Template.
CMSimple_XH zeichnet sich ja u.A. dadurch aus, dass man sozusagen direkt in der eigenen Seite bearbeitet. Für die Bearbeitung der Seiten(-Inhalte) selbst finde ich das auch wirklich super.
Ich frage mich aber, warum die diversen Einstellungen auch noch unter dem Template-Layout und -Style bearbeitet werden sollen.
Da können wir noch Jahre herumfummeln und Krücken bauen - es wird immer wieder zu Stylekonflikten kommen.
Nun gut. Ich weiß ja auch, welche Probleme daran hängen. Hier war nun aber genau der richtige Zeitpunkt, mal wieder darauf hinzuweisen.
Zurück zum Plugin-Menü.
Da wir ja nicht hexen und oben beschriebene Probleme einfach wegzaubern können, müssen wir vorerst rumbasteln.
Ludwigs Lösungsvorschlag mit Klasse "xh_pluginmenu" scheint mir unter diesen Umständen am sinnvollsten.
Ich habe mal in allen 3 verfügbaren Templates Ludwigs Style-Definitionen (allerdings noch für ".edit") eingefügt.
Es ist ein Kompromiss, der eine gewisse Allgemein-Gültigkeit hat. Über Farbe kann man noch reden. Die Schrift bleibt bei "Arial 14px", ist nicht schön und ist auch nicht dynamich (kleine/große Viewports).
Deutlich zu sehen sind die Beeinflussungen durch die jeweiligen Templates. Mal haben die ULs einen Abstand unten, mal ein Padding links (lck).
Da gibt es nur zwei Möglichkeiten:
1. So lassen und mit den Mängeln leben.
oder
2. Der Template-Designer schreibt in sein Template noch extra-Definitionen für ULs in Plugins, in Pagemanager, in Filebrowser und für alle anderen Fälle. Das dann auch noch für DLs, für INPUTs, ... usw.
Das habe ich bei fhs-simple (und auch anderswo) zumindest für Listen und den Pagemanager gemacht.
Ihr seht also: Alles nicht so einfach
Ohne eine entscheidende Änderung bleibt alles Frickelei und Notlösung.
You do not have the required permissions to view the files attached to this post.
Re: Schönere Gestaltung des klassischen Pluginmenüs
Ich meine immernoch, dass es eigentlich egal sein könnte, wie empfangreich eine Pluginkonfigurazion sein mag. Die Bausteine sind immer die gleiche. Die können (sollen) dann auch standardmäßig gestaltet werden. So ein universale Stylesheet würde auch ganz klein und eine CSS/ unter einem Plugin könnte evtl. ganz rausfallen.
Es gibt ja Plugins, die ihren Backend ziemlich kompliziert haben (Calendar, Realblog, Advancedform). Es ist aber eine Gesmacksache, wie sie organisiert haben mag. Falls das Aussehen von solchen Plugins nötig ist (eine 2-spaltige Gestaltung unpraktisch, unübersichtlich usw. wäre), können diese Plugins eigenen Stylesheet nutzen und "core CSS" ignorieren.
Ein Backenddesign dem Webpagetemplate anzupassen finde ich überflüssig, sogar verwirrend. Heutige elektronische Geräte nutzen zum Backenddesign die Umgebung sehr ähnlich einer Webseite. Alle Einstellungsbereiche sehen aber absolut ähnlich aus. Man orientiert sich sehr einfach, wenn alle gegebene Informationen, Anfragen, Befehle, Eintragfelder usw. in allen Subsystemen ähnlich aussehen.
Ich würde nun unterstützen Entfernung von jeden unnütigen ästhetischen "Pipapo" aus Pluginsbackend.
Was mein Ihr, würde es weitere Entwicklung von CMSimple_XH und Plugins nicht vereinfachen?
Es gibt ja Plugins, die ihren Backend ziemlich kompliziert haben (Calendar, Realblog, Advancedform). Es ist aber eine Gesmacksache, wie sie organisiert haben mag. Falls das Aussehen von solchen Plugins nötig ist (eine 2-spaltige Gestaltung unpraktisch, unübersichtlich usw. wäre), können diese Plugins eigenen Stylesheet nutzen und "core CSS" ignorieren.
Ein Backenddesign dem Webpagetemplate anzupassen finde ich überflüssig, sogar verwirrend. Heutige elektronische Geräte nutzen zum Backenddesign die Umgebung sehr ähnlich einer Webseite. Alle Einstellungsbereiche sehen aber absolut ähnlich aus. Man orientiert sich sehr einfach, wenn alle gegebene Informationen, Anfragen, Befehle, Eintragfelder usw. in allen Subsystemen ähnlich aussehen.
Ich würde nun unterstützen Entfernung von jeden unnütigen ästhetischen "Pipapo" aus Pluginsbackend.
Was mein Ihr, würde es weitere Entwicklung von CMSimple_XH und Plugins nicht vereinfachen?
CMSimple.sk
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
It's no shame to ask for an answer if all efforts failed.
But it's awful to ask without any effort to find the answer yourself.
Re: Schönere Gestaltung des klassischen Pluginmenüs
Zumindest ein Grund ist, dass CMSimple_XH ein unwissendes System ist. Beispiel: http://example.com/?foobarbaz. Soll diese Seite im normalen Template oder in einem Admintemplate angezeigt werden. Erst nachdem alle Plugins geladen wurden, weiß CMSimple_XH ob eines davon etwas in den Inhaltsbereich geschrieben hat. Falls ja, dann weiß CMSimple_XH aber nicht, ob das administrative Inhalte, oder ganz normale "Seiten"-Inhalte sind.frase wrote:Ich frage mich aber, warum die diversen Einstellungen auch noch unter dem Template-Layout und -Style bearbeitet werden sollen.
Eine saubere Lösung wäre eigentlich nur möglich, wenn sich Plugins an bestimmte Konventionen hielten. Okay, zumindest die meisten Plugins tun dies irgendwie, und man könnte daraus ermitteln, welches Template verwendet wird. Da das aber ein anderes Thema ist, bitte unter https://cmsimpleforum.com/viewtopic.php?f=16&t=13111 weiter diskutieren.
Zum Rest später mehr.
Christoph M. Becker – Plugins for CMSimple_XH