WBCE CMS Forum

rinse

Developer

Ein Dashboard-Modul für WBCE – ich suche Feedback

Ein Dashboard-Modul für WBCE – ich suche Feedback, bevor ich es richtig entwickle

Ich habe einen funktionierenden Entwurf für ein Admin-Tool, den ich gerne weiterentwickeln möchte. Ich würde aber lieber jetzt hören, was ihr davon haltet, als erst dann, wenn ich mich bereits in eine Sackgasse manövriert habe.

Was es ist

Ein Admin-Tools-Bildschirm, der den Zustand einer Installation anzeigt: Was ist kaputt, was ist unsauber und welche grundlegenden Zahlen gibt es zur Website?

Das Tool selbst enthält keine eigenen Prüfungen – es ist ein Framework. Die Prüfungen sind Widgets, und ein Widget ist einfach ein Ordner:

modules/wbce_dashboard/widgets/addon_registry/widget.php
modules/wbce_dashboard/widgets/page_meta/widget.php
modules/wbce_dashboard/widgets/section_modules/widget.php

Kein info.php, kein Installer, kein Eintrag in der Add-ons-Tabelle. Den Ordner hineinlegen und es läuft; den Ordner entfernen und es ist wieder weg. Jeder kann ein eigenes Widget schreiben.

Die eine Idee, die daraus ein Framework macht

Widgets schreiben ihre Schleifen nicht selbst. Sie abonnieren eine Schleife, und das Framework durchläuft jede Sammlung genau einmal und übergibt jedes Element an alle entsprechenden Subscriber.

class WD_W_page_meta extends WD_BaseWidget implements WD_OnPage
{
    public function group() { return 'Pages and content'; }
    public function title() { return 'Pages without a description'; }
    public function loops() { return array(WD_Widget::LOOP_PAGES); }

    public function onPage($page, $ctx)
    {
        $ctx->ok();
        if (trim($page['description']) === '') { $this->missing[] = $page; }
    }

    public function after($ctx)
    {
        if ($this->missing) {
            $ctx->warning(
                count($this->missing) . ' pages have no meta description',
                'Search engines then compose their own snippet from the page text.',
                $this->firstFew(), 'pages:description'
            );
        }
    }
}

Wenn zehn Widgets alle jede Seite benötigen, gibt es einen Durchlauf über die Seiten und nicht zehn.

Bisher gibt es fünf Schleifen: addons, pages, sections, settings und media. Ein Widget kann aber auch ganz ohne Schleife arbeiten.

Alles, was ein Widget lesen darf, läuft über $ctx->site – ein gemeinsames, gecachtes Lesemodell. Dadurch bleibt auch der Unterschied zwischen 1.6 (mysqli) und 1.7 (PDO) an einer einzigen Stelle und muss nicht in jedem Widget behandelt werden.

Was es bewusst nicht macht
Die Prüfungen ändern niemals etwas. Ein Widget liest und meldet; es gibt keinen Weg vom Widget-Code zu einem Schreibzugriff. Keine „Reparieren“-Buttons. Ein Tool, das sowohl diagnostiziert als auch repariert, muss zweimal vertrauenswürdig sein.
Keine Gesundheitsbewertung. Oben auf der Seite werden Zähler angezeigt – 5 Fehler, 4 Warnungen, 51 geprüft –, weil man auf einen Zähler klicken kann, während sich ein Wert wie 83 nicht ohne Weiteres erklären lässt.
Eine Meldung pro Ursache, nicht pro Vorkommen. Zwanzig gelöschte Sprachdateien ergeben eine Zeile und nicht zwanzig. (Diesen Fehler hatte ich in meiner ersten Version gemacht, und dadurch wurde das eine wirklich wichtige Problem vom Bildschirm verdrängt.)
Jede Meldung enthält ihre Belege: Datei und Zeile, Tabellenzeile oder die Abfrage, die fehlschlägt. Eine Meldung ohne Beleg ist eine Meinung.

Meldungen, die man nicht sehen möchte, können ausgeblendet werden. Was ausgeblendet ist, wird oben angezeigt, zusammen mit einem „Wieder anzeigen“-Button.

Das Framework verwendet dafür eine kleine eigene Tabelle – ausschließlich für seine eigenen Einstellungen und für nichts anderes.

Was im Entwurf enthalten ist

Vier Beispiel-Widgets, drei davon für unterschiedliche Schleifen und eines, das die anderen Widgets selbst überprüft: unbekannte Schleifennamen, Handler, die von niemandem aufgerufen werden, und Code, der das Read-only-Versprechen verletzt.

Wenn wir andere dazu einladen, eigene Widgets zu schreiben, brauchen sie als Erstes etwas, das ihnen zeigt, was mit ihrem Widget nicht stimmt.

Getestet mit WBCE 1.6.8 und 1.7.0 mit derselben Datenbank: identische Ausgabe.

Dazu hätte ich gerne eure Meinung

1. Sind das die richtigen Schleifen?

Was würdet ihr zusätzlich durchlaufen wollen? Benutzer und Gruppen, Templates, Droplets, die Such-Tabelle?

2. Ordner oder echte Module?

Ein Widget als vollständiges WBCE-Modul hätte den Vorteil des Add-on-Installers, aber auch ein info.php, eine Versionsnummer an zwei Stellen und eine Funktionsspalte für jedes Widget.

Ich habe mich für Ordner entschieden. Überzeugt mich vom Gegenteil – oder auch davon, dass meine Entscheidung richtig ist.

3. Einstellungen: eigene Tabelle oder die Settings-Tabelle?

Ich habe eine kleine eigene Tabelle angelegt, damit bei einer Deinstallation nichts zurückbleibt.

4. Welche Prüfungen wollt ihr tatsächlich haben?

Hier ist die Community mir jedes Mal überlegen. Wonach habt ihr schon einmal einen ganzen Abend gesucht, obwohl ein Dashboard es euch innerhalb einer Sekunde hätte sagen können?

5. Wo sollte das Ganze angesiedelt sein?

Es ist momentan ein Eintrag unter Admin-Tools, weil das Hauptmenü im Core fest codiert ist.

Ist das gut genug, oder gehört so etwas auf die Startseite?

Nehmt ihn ruhig auseinander – die Schnittstelle zwischen Framework und Widget ist das Teuerste, was man später ändern kann. Deshalb ist jetzt der richtige Zeitpunkt dafür.

Um diese Diskussion ein wenig zu bündeln, möchte ich euch bitten, hier [  https://forum.wbce.org/viewtopic.php?id=5997 ] zu antworten.

florian

Administrator

Re: Ein Dashboard-Modul für WBCE – ich suche Feedback

Thema geschlossen, bitte hier Feedback dazu (english)
https://forum.wbce.org/viewtopic.php?id=5997

---

Wir Benötigen: Cents, Euros... jetzt spenden!