Neo Dashboard Core

# Neo Dashboard Core

Version: 3.74.0 Requires PHP: 8.1+
License: GPL-2.0-or-later

Ein zentrales Dashboard-Framework, das WordPress-Plugins nahtlos in eine einheitliche Benutzeroberfläche integriert. Entwickler können eigene Sidebar-Gruppen, Sections, Widgets und Notifications per Hook-API registrieren.

✨ Neue Features (3.0.3)

• 🔗 WP-Admin Integration: Link zu Neo Dashboard im WordPress Admin-Menü
• 📊 Neo Umfrage: Vollständige Statistik-Seite mit Feld-Analyse
• 🎨 Icon Buttons: Moderne Icon-basierte Aktionsbuttons
• 📱 Responsive Design: Optimiert für alle Bildschirmgrößen
• 🌓 Dark Theme Support: Vollständige Unterstützung für dunkle Themes
• 🔧 Domain Changer: Neues Plugin für einfache Domain-Verwaltung

📦 Installation

1. Upload
   Kopiere den Ordner neo-dashboard-core in dein Verzeichnis wp-content/plugins/.
2. Aktivieren
   Aktiviere das Plugin im WordPress‑Admin unter Plugins.
3. Seite anlegen
   Bei der ersten Aktivierung wird automatisch eine Seite mit dem Slug neo-dashboard erstellt und das Blank-Template zugewiesen.
4. Permalinks
   (Nur bei URL-Problemen) Gehe zu Einstellungen > Permalinks und klicke auf „Änderungen speichern“, um Rewrite-Rules zu flushen.

🚀 Schnellstart

1. Im Browser aufrufen:
   https://deine-domain.de/neo-dashboard/
2. Hooks nutzen:
   Registriere in deinem Plugin unter add_action('neo_dashboard_init', ...) eigene Komponenten.

use NeoDashboard\Core\Extension\Definition\NavigationItemDefinition;
use NeoDashboard\Core\Extension\Definition\SectionDefinition;

add_action('neo_dashboard_init', function() {
    // Sidebar-Gruppe
    do_action('neo_dashboard_register_sidebar_item', NavigationItemDefinition::fromArray([
        'slug' => 'my-plugin',
        'label_callback' => static fn(): string => 'My Plugin',
        'icon' => 'bi-puzzle',
        'url' => '/neo-dashboard/my-plugin',
        'position' => 20,
        'is_group' => true,
    ]));

    // Section unter Gruppe
    do_action('neo_dashboard_register_sidebar_item', NavigationItemDefinition::fromArray([
        'slug' => 'my-plugin-settings',
        'label_callback' => static fn(): string => 'Einstellungen',
        'icon' => 'bi-gear',
        'url' => '/neo-dashboard/my-plugin-settings',
        'position' => 21,
        'parent' => 'my-plugin',
    ]));

    // Section im Content-Bereich
    do_action('neo_dashboard_register_section', SectionDefinition::fromArray([
        'slug' => 'my-plugin-settings',
        'label_callback' => static fn(): string => 'Einstellungen',
        'callback' => static function (): void {
            require plugin_dir_path(__FILE__) . 'templates/settings.php';
        },
    ]));
});

🔌 Architektur & Extensibility

• PSR‑4 Autoloader lädt alle Klassen im Namespace NeoDashboard\Core.
• Bootstrap: Schlanke Lebenszyklus-Fassade für Aktivierung und Deaktivierung. Laufzeitstart, Sprache, Dokumenttitel, Admin-Menü und WordPress-Ausgabebereinigung liegen in getrennten Adaptern.
• Dashboard-Laufzeit: DashboardRuntimePipeline steuert die explizite Startreihenfolge. DashboardManagerContainer erzeugt und verbindet die Manager nicht mehr selbst, sondern erhält sie von DashboardRuntimeCompositionRoot; der HookBus kapselt WordPress-Hooks.
• Registries: Getrennte Registries verwalten Navigation, Sections, Widgets und Notifications. DashboardRegistries bündelt ihre Instanzen pro Runtime und wird vom Composition Root explizit an alle Verbraucher übergeben; ein globaler Registry-Singleton existiert nicht mehr.
• Manager-Klassen: SidebarManager, SectionManager, WidgetManager, NotificationManager, AssetManager.
• Assets: AssetCatalog verwaltet Plugin- und Seiten-Assets sowie deren Kontextindex. CoreAssetManifest beschreibt die lokalen Core-Dateien; CoreAssetEnqueuer, PluginAssetEnqueuer und DashboardAssetPrinter kapseln Enqueueing, JavaScript-Lokalisierung und Standalone-Ausgabe. CoreAssetPlatform und DashboardClientEnvironment trennen WordPress- Enqueueing, Dateiprüfung, URLs, Nonces und Ãœbersetzungen von der testbaren Asset-Orchestrierung und dem Aufbau der Client-Konfiguration. Auch Plugin-Assets laufen über PluginAssetPlatform; vorhandene Lokalisierungsdaten werden generisch nach Script-Handle und Objektname erhalten, ohne plugin-spezifische Sonderfälle im Core. AssetManager bleibt die kompatible WordPress-Hook-Fassade.
• Sprachen: LanguageCatalog verwaltet verfügbare und Plugin-spezifische Sprachen. PluginLanguageSelector kapselt die Fallbackregel; LanguageManager übernimmt nur WordPress-Hooks, Benutzer-Metadaten und AJAX.
• Widget-AJAX: WidgetRenderService kapselt Auflösung, Zugriff, Cache und Rendering mit typisierten Ergebnissen. Provider, Zugriffsprüfung und Cache sind austauschbar. Der WordPress-unabhängige WidgetAjaxController arbeitet ausschließlich mit WidgetAjaxRequest und WidgetAjaxResponder; konkrete WordPress-Adapter übernehmen globale Eingaben, Nonce-Prüfung und kompatible JSON-Antworten. Die Composition Root übergibt den Controller direkt an den Runtime-Initializer.
• REST: RestRouteCollection hält typisierte Routendefinitionen; WordPressRestRouteRegistrar, WordPressRestPermissionChecker und RestEndpointResponder kapseln Registrierung, Berechtigungen und einheitliche Erfolgs- beziehungsweise Fehlerantworten. RestManager bleibt Fassade für die öffentliche Extension-API.
• Notifications: NotificationVisibilityFilter entscheidet unabhängig von WordPress über Ablauf, Rollen, Ausblendestatus und Priorität. WordPressNotificationUserState kapselt Benutzer-Metadaten; NotificationService und NotificationRestController bilden Anwendungsfall und REST-Transport ab. NotificationManager bleibt die Hook-Fassade.
• Navigation und Sections: NavigationTreeBuilder erzeugt sortierte, hierarchische Sichtdaten einschließlich Labels und Tooltips an einer einzigen Stelle. SidebarManager und SectionManager erhalten ihre Registries als Abhängigkeiten und bleiben schlanke WordPress-Hook-Fassaden. Section-Auflösung erfolgt direkt über den injizierten SectionResolver; Registry-Ergebnisse sind cache-stabil.
• Widget-Definitionen: WidgetDefinitionLoader kapselt den idempotenten Hook- und Ladezyklus; WidgetSorter erzeugt die priorisierte Sicht. WidgetManager erhält Registry, Loader und Sortierer als Abhängigkeiten und beschränkt sich auf die kompatible Registrierungsfassade.
• Zugriff und Seitentitel: RoleAccessPolicy entscheidet unabhängig von WordPress über rollenbasierte Sichtbarkeit und wird von Content- und Widget- Zugriff als explizite Abhängigkeit aus der Composition Root gemeinsam verwendet. DashboardPageTitleBuilder kapselt Dashboard-, Section- und 404-Titel. WordPressDashboardPageTitleProvider übernimmt WordPress-Abfragen, Section-Auflösung und anfrageweites Caching; DashboardDocumentTitle nutzt ihn direkt.
• Request-Zugriff: WordPressAccessController registriert die WordPress- Hooks für den injizierten WordPressAccessEnforcer; öffentliche Plugins melden exakte und Präfix-Pfade typisiert über neo_dashboard_register_public_routes an.
• Servergrenzen: Der Core verändert keine .htaccess-Datei und führt kein eigenes Login- oder IP-Protokoll. Direkter Dateizugriff wird durch die vorhandenen ABSPATH-Guards und die Serverkonfiguration begrenzt.
• Benutzermenü: UserMenuFormatter kapselt Unicode-sichere Initialen und Rollenbezeichnungen. UserRoleResolver bestimmt Rollen mit expliziter Priorität und versorgt Benutzermenü sowie Access-Denied-Ansicht. WordPressUserMenuRenderer erzeugt Avatar, Login-/ Logout-URLs und Markup einmal pro Rendering; beide Menütemplates erhalten das fertige Markup vom DashboardRenderer.
• Widget-Komponenten: WidgetComponentRenderer rendert ausschließlich bekannte Komponenten-Templates und bereinigt Output-Buffer auch bei Fehlern. WidgetValueColorPolicy kapselt KPI-Farbschwellen und Fachplugins erzeugen oder erhalten den zustandsarmen Renderer als normale Objektabhängigkeit; ein globaler Renderer-Kontext ist nicht erforderlich.
• Request- und Section-Auflösung: CurrentRequestTypeProvider übernimmt den typisierten Request-Kontext einschließlich ADMIN. Der Provider wird pro Anfrage zwischengespeichert und vom Composition Root gemeinsam an Runtime-Initializer und Router übergeben. Interne Dienste erhalten den Provider explizit; punktuelle statische Logger- und Template-Grenzen erzeugen den zustandsarmen Provider lokal.
• Presentation: DashboardViewModelFactory erstellt zugriffsgefilterte Sichtdaten; DashboardResponseHandler setzt den HTTP-Status und DashboardRenderer rendert das Layout.
• DashboardRouter: WordPress-Adapter für URL-Registrierung, Template-Auswahl und Body-Klassen steuert. Das Blank-Template besitzt das vollständige HTML-Dokument; ein Output-Buffer oder Regex-Filtering wird nicht mehr verwendet.
• Templates: Blank-Template (dashboard-blank.php) und Layout-Template (dashboard-layout.php) basierend auf Bootstrap 5.

🛠️ Hook-API Übersicht

Registrierung erfolgt typisiert (Beispiel Sidebar-Item):

NavigationItemDefinition::fromArray([
  'slug' => 'key',
  'label_callback' => static fn(): string => 'Titel',
  'icon' => 'bi-icon',
  'url' => '/neo-dashboard/key',
  'position' => 10,
  'roles' => ['administrator'],
  'parent' => 'group-slug',
  'is_group' => false,
]);

📚 Beispiele

Sidebar-Gruppierung

use NeoDashboard\Core\Extension\Definition\NavigationItemDefinition;

add_action('neo_dashboard_init', function() {
    // Gruppe definieren
    do_action('neo_dashboard_register_sidebar_item', NavigationItemDefinition::fromArray([
        'slug' => 'weather-plugin',
        'label_callback' => static fn(): string => 'Wetter-Plugin',
        'icon' => 'bi-cloud',
        'url' => '/neo-dashboard/weather-plugin',
        'position' => 10,
        'is_group' => true,
    ]));

    // Unterpunkte
    foreach (['3days','7days'] as $type) {
        do_action('neo_dashboard_register_sidebar_item', NavigationItemDefinition::fromArray([
            'slug' => 'weather-'.$type,
            'label_callback' => static fn(): string => ($type==='3days'?'3-Tage':'7-Tage').'-Wetter',
            'icon' => 'bi-calendar',
            'url' => '/neo-dashboard/weather-'.$type,
            'position' => ($type==='3days'?11:12),
            'parent' => 'weather-plugin',
        ]));
    }
});

Wetter-Widget & Notification

use NeoDashboard\Core\Extension\Definition\NotificationDefinition;
use NeoDashboard\Core\Extension\Definition\WidgetDefinition;

add_action('neo_dashboard_init', function() {
    // Aktuelles Wetter-Widget
    do_action('neo_dashboard_register_widget', WidgetDefinition::fromArray([
        'id' => 'current-weather',
        'label' => 'Aktuelles Wetter',
        'icon' => 'bi-thermometer-half',
        'priority' => 5,
        'callback' => function(){ /* Anzeige-Code */ },
    ]));

    // Unwetter-Warnung
    if ( $will_storm ) {
        do_action('neo_dashboard_register_notification', NotificationDefinition::fromArray([
            'id' => 'storm-alert',
            'message' => '<strong>⚠️ Gewitter erwartet!</strong>',
            'priority' => 1,
            'dismissible' => true,
        ]));
    }
});

🔔 Toast Notifications (Plugins)

NeoDash.toast('info', 'Kurze Info');
NeoDash.toastSuccess('Erfolg gespeichert!');
NeoDash.toastError('Fehler beim Speichern');
NeoDash.toastWarning('Achtung: prüfen Sie die Eingaben');
NeoDash.toastInfo('Hinweis für den Nutzer');

Optionen:

NeoDash.toast('info', 'Nachricht', {
  duration: 8000,   // ms (0 = dauerhaft)
  title: 'Hinweis', // optionaler Titel
  autohide: true
});

Globale Defaults (optional):

window.NeoDash = window.NeoDash || {};
window.NeoDash.toastDefaults = {
  duration: 5000,
  containerClass: 'position-fixed top-0 end-0 p-3',
  containerZIndex: 9999
};

A11y‑Hinweis:
Erfolg/Info verwenden role="status" + aria-live="polite", Fehler/Warnung role="alert" + aria-live="assertive".