-
Einstellung „Dashboard-Widgets ausblenden“ (
disableWidgets) auf der Plugin-Seite: das Plugin setzt seine Widgets nicht mehr aufs Dashboard und entfernt die bereits gesetzten bei jedem Benutzer beim nächsten CP-Aufruf — gilt für alle Benutzer -
Widgets merken sich, ob sie vom Plugin oder vom Benutzer hinzugefügt wurden (
addedByPlugin, viaAddedByPluginTrait) — selbst hinzugefügte diff.-Widgets bleiben beim Ausblenden erhalten. Widgets aus älteren Versionen (ohne Flag) gelten als vom Plugin gesetzt -
Eigene Widgets eines Benutzers werden beim Übernehmen des Dashboards durch das Plugin in den User-Preferences (
diffbaseWidgets) gesichert und beim Ausblenden der Plugin-Widgets wiederhergestellt -
„Feedback geben“-Button am rechten Rand aller CP-Seiten (nur Nicht-Admins): lädt Marker.io erst beim Klick und öffnet direkt die Erfassung. Danach ersetzt der Marker.io-Button den eigenen Button bis zum nächsten Seitenaufruf. E-Mail und voller Name des Craft-Benutzers werden als Reporter vorausgefüllt (
Marker.setReporter()) — ohne Namen wird der Systemname verwendet -
Einstellung „Feedback-Button ausblenden“ (
disableFeedback) auf der Plugin-Seite: blendet den Button für alle Benutzer aus, Marker.io wird dann nie geladen. Unabhängig von „Dashboard-Widgets ausblenden“ -
Server-Info der API enthält den Hosting-Benutzer (
hosting_user), ermittelt aus dem Webroot-Pfad/home/<USERNAME>/public_html/…—null, wenn der Pfad nicht passt -
Server-Info der API enthält den Craft-Root (
craft_root, Alias@root) und den Webroot (web_root, Alias@webroot) -
Server-Info der API enthält die Domain (
domain) der Primary-Site, ermittelt aus deren Base-URL -
Server-Info der API enthält den Domain-Handle (
domain_handle): Domain in Kleinbuchstaben ohnewww., TLD, Punkte und Bindestriche (z. B.gbk-law.ch→gbklaw) -
Endpoint
actions/diffbase/update/craft-update(API-Key viakey-Parameter oderX-API-Key-Header): führtphp craft update all --backup --migrate --with-expiredsynchron aus und antwortet mitsuccess,exit_codeund der Ausgabe (letzte 20 KB). Ein Lock verhindert parallele Updates auf demselben System (Antwort409), ein fehlgeschlagenes Update liefert500. Das zentrale Monitoring kann damit die Updates über seine Queue nacheinander anstoßen
- Das zentrale Monitoring läuft unter
smart.diff.chstattflow.diff.ch:Access-Control-Allow-Originder Update-Endpoints (composer-update,craft-update) und der Hinweis im README wurden angepasst - Marker.io wird nicht mehr bei jedem CP-Aufruf geladen, sondern erst beim Klick auf den „Feedback geben“-Button
- Speichern einer Einstellung auf der Plugin-Seite verwarf die übrigen Einstellungen (u. a. wurde dadurch ein neuer API-Key generiert) — es werden nun immer alle Einstellungen gespeichert
- Formulare auf der Plugin-Seite leiteten nach dem Speichern auf
/admin/_diffbase(404) statt auf/admin/diffbaseweiter - Composer-Update schlug mit „The HOME or COMPOSER_HOME environment variable must be set“ fehl, weil dem
Processfür dencomposer update-Aufruf keine Umgebungsvariablen übergeben wurden —HOME/COMPOSER_HOMEwerden nun (wie bereits bei der Binary-Suche) überposix_getpwuid()aufgelöst und an den Prozess weitergereicht
composerPathsetting (CP-Feld auf der Plugin-Settings-Seite) als manueller Override für den Composer-Update-Endpoint, falls die automatische Suche das Binary auf einem Host nicht findet
- Automatische Composer-Suche verwendete
getenv('HOME'), das unter PHP-FPM oft leer ist (anders als in einer SSH-Shell) — aufposix_getpwuid()umgestellt, das das Home-Verzeichnis zuverlässig direkt aus der OS-User-Datenbank liest /opt/cpanel/composer/bin/composer(cPanel Composer Manager) zur Standard-Suchliste hinzugefügt
- Update endpoint failed on hosts with
exec()disabled — switched toSymfony\Process(proc_open()) with automatic composer binary detection
/api/infoliefert jetzt einenusers-Block (total,admins,pending,suspended,locked,last_admin_login) — bewusst ohne Namen/E-Mail, da der Endpoint nur über einen statischen Key geschützt ist- Update-Endpoint (
UpdateController::actionComposerUpdate):Access-Control-Allow-Origin: https://flow.diff.chgesetzt, damit das zentrale Monitoring-Dashboard den Update-Trigger per AJAX auslösen und das Ergebnis direkt inline anzeigen kann, statt in einem neuen Tab zu landen MessageWidgetnow renders with a light orange background (#ffe9d7) to visually stand out on the dashboardNewsWidgetandTechWidgetsupport a configurableoffsetsetting to display different entries when multiple instances are used on the dashboard- Sites in API response now include
reachable(bool) andhttp_status(int) fields — a HEAD request is made to each site'sbase_urlto detect if the frontend is accessible independently of the plugin/backend NewsWidgetandTechWidgetnow display the entry title as the widget header (parsed from remote response)
getPluginsInfo(): 5 Felder (edition,has_cp_settings,license_key_status,is_trial,update_available) lieferten für jedes Plugin immernull/falsewegen einer nie definierten Variable$pluginInfo— entfernt (die Update-Info steht bereits korrekt unterupdates.plugins)mail.transport_settingswar immer leer, weil derswitchauf'smtp'/'gmail'/'sendmail'prüfte,transportTypeim Project Config aber der volle Klassenname ist (z.B.craft\mail\transportadapters\Sendmail) — Vergleich auf die tatsächlichen Klassennamen umgestelltphp-Block:memory_usage/peak_memoryentfernt (spiegelten nur den Verbrauch des kurzlebigen API-Requests selbst, kein aussagekräftiges Signal)- Update-Endpoint (
UpdateController::actionComposerUpdate): Ungültiger/fehlender API-Key lieferte HTTP 200 statt 401 —asJson()von Yii akzeptiert keinen zweiten Statuscode-Parameter, dieser wurde stillschweigend verworfen. Statuscode wird nun explizit überCraft::$app->getResponse()->setStatusCode(401)gesetzt - Update-Endpoint:
successwurde fälschlichtruegemeldet, wennshell_exec()deaktiviert war oder fehlschlug (null-Rückgabe führte dazu, dassstr_contains()falselieferte) — aufexec()mit echtem Exit-Code umgestellt,successbasiert nun auf$exitCode === 0 - Queue: Alle Job-Counts (
total_jobs,waiting_jobs,reserved_jobs,failed_jobs) lieferten immer0—method_exists()-Checks auf Queue-Methoden ersetzt durch direkteyii\db\Query-Abfragen auf{{%queue}}(analog zugetRecentFailedJobs) - Queue:
failed_jobslieferte immer0, weilcreateCommand()keine Query-Builder-Methoden hat — ersetzt durch die nativengetTotalFailed(),getTotalWaiting(),getTotalReserved(),getTotalJobs()API-Methoden voncraft\queue\Queue - Queue: Spaltenname
timeFailedkorrigiert zudateFailed(korrekter Craft-Spaltenname) ingetRecentFailedJobs() - Queue: Raw-SQL in
getRecentFailedJobs()aufyii\db\Queryumgestellt (stattCommand)
- Marker.io Bug-Reporting-Tool global im Control Panel registriert
- Tool ist auf allen Backend-Seiten verfügbar für schnelles Feedback und Bug-Reports
- File-Upload im SupportWidget funktioniert jetzt korrekt (
enctype="multipart/form-data"hinzugefügt) - Status-Meldungen (Erfolg/Fehler) werden im Widget korrekt angezeigt
- Korrekte Action-URL im Widget verwendet
- Redirect-Logik verbessert mit Fallback zum Dashboard
- File-Accept-Filter hinzugefügt für bessere UX
- Hilfetexte für Upload-Feld hinzugefügt
- Dateigrößen-Validierung (max. 10 MB)
- Ausführliches Logging für File-Upload und E-Mail-Versand
- Anhang-Informationen werden in der E-Mail angezeigt (Name, Typ, Größe)
- Automatisches Cleanup: Temporäre Dateien werden nach dem Versand gelöscht
- File-Upload verbessert mit besserer Fehlerbehandlung
- Sichere Dateinamen (Sanitization) um Sicherheitsprobleme zu vermeiden
- Temp-Verzeichnis wird automatisch erstellt, falls nicht vorhanden
- Korrekte Content-Type und Dateinamen für E-Mail-Anhänge
- Support-E-Mail-Funktion mit Dateianhang-Support
- Route für
diffbase/support/send-emailregistriert (nichtdiff-base!) - Test-Template unter
/support-testzum Testen des E-Mail-Versands - System-E-Mail-Absender aus ProjectConfig verwendet
- 404 Fehler bei Support-Controller behoben durch Registrierung der Route und erlaubtem anonymen Zugriff
- Korrekte Action-URL ist
{{ actionUrl('diffbase/support/send-email') }}, nichtdiff-base