Alternatives Admin-Menü

[frase]

Vielleicht sogar Konfigurierbar - immer sichtbar / ausgeklappt - ja / Nein

Heeee, nun werdet mal nicht übermütig

Denn wenn ich mich einlogge will ich auch etwas tun, und dazu brauche ich "meistens" da Admin Menu ...

Kann man sehen, wie man will.
"Normal" ist, dass man sich zum Seiten-Bearbeiten einloggt (End-Anwender).
Am System rumschrauben macht man wohl eher selten.

Damussschnochmalnachdengn.

[cmb]

Ich hatte aus lauter Unwissen bei der nächsten Konfiguration genommen:

Code: Select all

if ($myconfig != '') { 

Das funktioniert gut. Ist es auch sauber?

Ja, das ist in diesem Fall sauber.

<technobabble>
Genau genommen kommt es halt immer darauf an, welche Datentypen man erwartet. Konfigurations- und Sprachvariablen sind immer Strings, und da kann man folgendes verwenden, was etwas effizienter ist:

Code: Select all

if ($myconfig !== '') {

</technobabble>

Letztlich kann man aber eigentlich davon ausgehen, dass eine Sprachvariable immer vorhanden ist (okay, ein eifriger Webmaster könnte die Zeile löschen, aber genauso gut könnte er auch eine beliebige andere Zeile PHP-Code löschen, woraus alles mögliche resultieren könnte). Daher kannst Du vereinfachen:

Code: Select all

function fhs_admButtonLabel()
{
    global $plugin_cf;

    return $plugin_cf['fhs_adminmenu']['button_Label'];
}

<technobabble>

War aber in isometrics Code so drin.

Ah, jetzt verstehe ich! Bernd programmiert an zwei Plugins, bei denen Variablen vom Benutzer definiert werden können; da kann es schon passieren, dass in bestimmten Fällen eine Variable gar nicht gesetzt ist. Da ist es wichtig diesen Fall abzufangen und ggf. einen Default-Wert bereit zu stellen, also eben:

Code: Select all

$value = isset($var) ? $var : 'default'; 

Ab PHP 7 kann man das kürzer schreiben (vorfreu!):

Code: Select all

$value = $var ?? 'default'; 

</technobabble>

[frase]

[url]Neue Version 06[/url]
Edit: Link nicht mehr verfügbar. Bitte letzte Version in diesem Thread verwenden.

- alles konfigurierbar

für mich (z.Z.) unlösbare Probleme:
- Updatecheck
- Debug-Meldung
- Icon vor "Vorschau":
Da habe ich mir beinahe die Finger gebrochen, damit es einigermaßen funktioniert.
Klappt aber nicht vollständig. Beispiel:
- Klick auf "Vorschau"
- danach Klick auf "Plugins"
- danach Menü öffnen: -> ein "Auge" befindet sich an der falschen Stelle

Wen man das noch lösen könnte, hätten wir eine 1.0 Version - oder?

Sinn oder Unsinn, den Menü-Button nach unten zu legen???

[lck]

- Icon vor "Vorschau":
Da habe ich mir beinahe die Finger gebrochen, damit es einigermaßen funktioniert.
Klappt aber nicht vollständig. Beispiel:
- Klick auf "Vorschau"
- danach Klick auf "Plugins"
- danach Menü öffnen: -> ein "Auge" befindet sich an der falschen Stelle

Eventuell so:

Code: Select all

if ((test == 2 && edit == true) || (test == 1)) {
    // $("#fhs_adminmenu a[href*='&normal']").first().prepend('<i class="fa fa-eye"></i> ');
    $("#fhs_adminmenu > ul > li > a[href*='&normal']:not(a[href*='?&normal&'])").prepend('<i class="fa fa-eye"></i> ');
}

EDIT:
Aufgefallen ist mir auch noch, dass die Plugins nicht mehr alphabetisch sortiert sind.

[frase]

Eventuell so: ...

Super, das löst schon mal ein Problem.
Es gibt aber noch ein anderes (vorher wie nachher):
- Bearbeitungsmodus
- Einstellungen -> irgendeinen Punkt anklicken
- Menü öffenen:
Es fehlt das Auge vor "Vorschau"

Aufgefallen ist mir auch noch, dass die Plugins nicht mehr alphabetisch sortiert sind.

Das kann ich leider nicht bestätigen. Bei mir sind sie sortiert.
Benutzt du ein anderes Alfabet

Ein weiteres Problem, das ich aber nicht so dramatisch finde und was auch kaum lösbar ist:
Wenn Plugins "nicht-Standard-"Menüpunkte verwenden, gibt es auch kein Icon.
Beispiel: Realblog - Datenaustausch
Für solche Fälle kann man nicht vorsorgen. Es sei denn, man nimmt ein"allgemeines" Icon für nicht definierte Fälle - aber welches?

[Tata]

Mir ist eine Kleinigkeit aufgerfallen.
Das meistens benutzte Punkt des ADminmenu ist wohl Edit/Preview. Wäre es sinnloss diese Ikone gleich neben "ADMINMENU" stellen. So müsste man nicht das ganze Adminmenu ausrollen. Ode besser noch eine Taastenkombination dafür einzubauen.

[frase]

Wäre es sinnloss diese Ikone gleich neben "ADMINMENU" stellen.

Ja, darüber haben wir schon am Anfang dieses Threads nachgedacht.
Im Moment funktioniert das Plugin ohne jegliche Core-Änderung. Es nutz sogar das originale Adminmenü - nur mit anderen Namen.
Um einzelne Buttons (LInks) da "herauszuholen", müsste ich das das originale Menü nehmen, es verändern und dann ausgeben.
Das wollte ich vermeiden. Man weiß ja auch nicht, was die Zukunft noch so bringt. Bei Änderungen würde es nicht mehr funktionieren.

[cmb]

Uff, ich komm kaum hinterher. Auf die Schnelle mein Senf nur mal zu ein paar Punkten.

Aufgefallen ist mir auch noch, dass die Plugins nicht mehr alphabetisch sortiert sind.

Das kann ich leider nicht bestätigen. Bei mir sind sie sortiert.

Das liegt daran, dass bei vielen Plugins normalerweise ein mehrspaltiges Menü erzeugt wird, und zwar in N-Ordnung (also erst wird die erste Spalte befüllt, dann die zweite). Wird das Menü wie hier geflattet, dann wird tatsächlich nicht wirklich alphabetisch sortiert.

Wäre es sinnloss diese Ikone gleich neben "ADMINMENU" stellen.

Ja, darüber haben wir schon am Anfang dieses Threads nachgedacht.
Im Moment funktioniert das Plugin ohne jegliche Core-Änderung. Es nutz sogar das originale Adminmenü - nur mit anderen Namen.
Um einzelne Buttons (LInks) da "herauszuholen", müsste ich das das originale Menü nehmen, es verändern und dann ausgeben.
Das wollte ich vermeiden. Man weiß ja auch nicht, was die Zukunft noch so bringt. Bei Änderungen würde es nicht mehr funktionieren.

Na ja, das kann man so oder anders sehen. Letztlich kann es auch leicht passieren, dass das alternative Adminmenü nicht mehr funktioniert, wenn XH_adminMenu() geändert wird. Jedenfalls könnte das vom Core erzeugte Adminmenü auch noch weiter per JS manipuliert werden. Irgendwo kommt halt der Punkt, wo diese JS-Anpassungen so aufwendig werden, dass man vielleicht doch besser ein eigenes Adminmenü erzeugen sollte. Und es besteht natürlich auch die Möglichkeit, fhs_adminmenu zum Standard zu machen, und das bisherige Adminmenü als Plugin auszuliefern.

[frase]

Und es besteht natürlich auch die Möglichkeit, fhs_adminmenu zum Standard zu machen, und das bisherige Adminmenü als Plugin auszuliefern.

Schön wär's ja.
Aber ich denke, da muss vorher noch einiges passieren.
Vor allem müsste mal ein Profi-Programmierer ran und die ganzen Code-Krücken reparieren.
Und dann testen, testen, testen ...

Das liegt daran, dass bei vielen Plugins normalerweise ein mehrspaltiges Menü erzeugt wird, und zwar in N-Ordnung (also erst wird die erste Spalte befüllt, dann die zweite). Wird das Menü wie hier geflattet, dann wird tatsächlich nicht wirklich alphabetisch sortiert.

Kann man was dagegen tun? Oder ist es nicht ganz so schlimm?

Irgendwo kommt halt der Punkt, wo diese JS-Anpassungen so aufwendig werden, dass man vielleicht doch besser ein eigenes Adminmenü erzeugen sollte.

Stimmt. Ist jetzt schon grenzwertig.

[lck]

Aufgefallen ist mir auch noch, dass die Plugins nicht mehr alphabetisch sortiert sind.

Das kann ich leider nicht bestätigen. Bei mir sind sie sortiert.
Benutzt du ein anderes Alfabet

Ja sorry, ich hatte Sächisch eingestell. Mit Bairisch klappt's wieder

Spaß beiseite. Christoph hat es ja bereits beschrieben, warum dies so ist. Bis 12 Plugins ist die alphabetische Sortierung in Ordnung, ab dem 13. Plugin gibt's eben eine unsortierte Liste der Plugins. Ich kann damit leben.