|
Some checks failed
CI / PHP Lint (push) Waiting to run
CI / PHP Lint-1 (push) Waiting to run
CI / Unit Tests & Static Analysis (push) Waiting to run
CI / PHP Lint (pull_request) Has been cancelled
CI / PHP Lint-1 (pull_request) Has been cancelled
CI / Unit Tests & Static Analysis (pull_request) Has been cancelled
Frontend, Login/Installer/Updater und der komplette Admin-Bereich nutzen jetzt ein einziges Stylesheet (assets/global.css) statt pro Seite dupliziertem Inline-CSS. Design-System - Tokens für Flächen, Text, Linien, Marke, Status, Radien, Schatten und Layout-Maße; Dark Mode ausschließlich über Tokens (keine !important- Overrides mehr) - Komponenten: Buttons, Formularfelder, Cards, Tabellen, Badges, Alerts, Tabs, Pagination, Modals, Toasts, Statistik-Kacheln, Empty States - Schrift Inter mit System-Fallback Oberfläche - Admin-Shell neu: durchgehende Sidebar mit Marke, gruppierter Navigation und Benutzerbereich; schlanke Topbar mit Breadcrumb - Dashboard: ruhige KPI-Kacheln mit Icon-Chips, Charts an Theme-Farben gekoppelt - Öffentliche Voucher-Seite: App-Topbar, klare Formularstruktur und Ticket-Darstellung des erstellten Codes inkl. QR-Code - Login/Passwort/2FA: zweispaltiges Auth-Layout bzw. Fokus-Karten - Updater und Wartungsmodus im gleichen Look (Wartungsseite bleibt bewusst eigenständig ohne externe Abhängigkeiten) - Emoji-Icons in der UI durch Font-Awesome-Icons ersetzt Nebenbei behoben - Falscher SRI-Hash blockierte qrcode.min.js – QR-Codes wurden auf der Voucher-Seite und bei der 2FA-Einrichtung nie gerendert - assets/global.css wurde in mehreren Admin-Seiten über einen falschen Pfad eingebunden ($adminBase = '' statt '../') - TinyMCE lädt ohne API-Key jetzt die GPL-Variante von cdnjs – kein "valid API key required"-Banner mehr im Einstellungs-Editor - Tabellen in Cards scrollen horizontal statt zu überlaufen Screenshots in docs/screenshots neu erstellt, README aktualisiert (neuer Abschnitt "Design-System", Version 2.5.0). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| migrations | ||
| storage | ||
| templates | ||
| AuditLogger.php | ||
| bootstrap.php | ||
| MigrationRunner.php | ||
| README.md | ||
| routes.php | ||
| UpdateController.php | ||
| UpdateManager.php | ||
| UpdaterFactory.php | ||
Updater (OpenVoucherTool)
Auto-Update-System nach dem OpenNIT-Modell: zieht Quellcode + DB-Migrationen aus einem zentralen Repository über einen HTTP-Update-Proxy nach.
[diese App] ←HTTPS→ [Update-Proxy] ←pull→ [Git-Repo]
- Versions-Identität: 40-stelliger Git-Commit-SHA in
updater/storage/.version - Channels:
stable→https://update.loheide.eu/openvouchertool,development→https://update.loheide.eu/openvouchertool-development - User-Agent:
OpenVoucherTool-Updater/1.0 - DB-Treiber: MySQL/MariaDB (Migrations-Tracking-Tabelle
_updater_migrations)
Aufruf
Admin-Oberfläche: /admin/update.php (nur für angemeldete Admins).
| Endpoint | Methode | Zweck |
|---|---|---|
admin/update.php |
GET | Admin-UI |
admin/update.php?action=check |
GET | Update-Prüfung (JSON) |
admin/update.php?action=progress |
GET | Fortschritt (JSON) |
admin/update.php?action=migrations |
GET | Migrations-Status (JSON) |
admin/update.php action=install |
POST | Update installieren (+csrf_token) |
admin/update.php action=set_channel |
POST | Channel wählen (+csrf_token) |
Optional: In der Admin-Navigation (
admin/index.php) einen Link zuupdate.phpergänzen, damit die Seite auffindbar ist. Das ist bewusst nicht automatisch geschehen (Isolations-Prinzip – siehe unten).
Isolation
Der Updater liegt vollständig in updater/ (eigener Namespace Updater\) plus
zwei dünne, klar markierte Anknüpfungen:
- Front-Controller-Hook in
index.php(Maintenance-Check, markiert mit// Updater maintenance hook). - Entry-Shim
admin/update.php(lädt nur Basis + Bootstrap, delegiert an den Controller).
Eigene Settings (updater/storage/updater-settings.json), eigener Autoloader
(updater/bootstrap.php), eigener AuditLogger (schreibt in die vorhandene
audit_log-Tabelle), eigenes Migrations-System (updater/migrations/ +
Tabelle _updater_migrations). Es werden keine Projekt-Klassen erweitert –
\Database und \Auth werden nur per Injection genutzt.
Geschützte Pfade (werden bei Updates nie überschrieben)
config.php, .htaccess, .env*, .git/, .gitignore, public/uploads/,
vendor/, composer.lock, updater/storage/.
Rückbau (restlos entfernen)
- In
index.phpden Block „Updater maintenance hook" (die Zeilen 2–8, beginnend mit$maintenanceFile = …bis zum schließenden}) entfernen. rm -r updater/rm admin/update.php- (optional) In der Datenbank:
DROP TABLE _updater_migrations; - (optional, falls vorhanden) Laufzeitdateien sind bereits in
updater/und damit mit Schritt 2 weg. Nichts liegt außerhalb.
Danach ist keine Spur des Updaters mehr im Bestandscode – der Beweis für die Isolation.
Smoke-Test
# 1) Syntax aller Updater-Dateien
php -l updater/UpdateManager.php
php -l updater/MigrationRunner.php
php -l updater/UpdateController.php
php -l updater/UpdaterFactory.php
php -l updater/AuditLogger.php
# 2) Admin-Seite aufrufen (eingeloggt als Admin):
# https://<host>/admin/update.php
# -> "Auf Updates prüfen" klicken. Erwartung: Proxy-Antwort oder klare
# Fehlermeldung (wenn Proxy/Channel nicht erreichbar).
# 3) Maintenance-Mode manuell testen:
touch updater/storage/.maintenance # index.php zeigt jetzt 503-Wartungsseite
rm updater/storage/.maintenance # wieder normal
Hinweis: Ein vollständiger Installations-Durchlauf (
action=install) setzt einen erreichbaren Update-Proxy unter den oben genannten URLs voraus.