Release: QUIQQER 2.26
Zusammenfassung
QUIQQER 2.26 führt eine breite Wartungswoche in eine klarere Plattformrichtung. Bei 60 Paket-Updates konzentriert sich die relevante Arbeit vor allem auf die Modernisierung der Datenhaltung, aktuelle Laufzeitvoraussetzungen, verlässlichere Integrationsschnittstellen und ein genaueres Fehlerverhalten. Order, Permalinks, Purchasing und Rating setzen die Umstellung auf DBAL und UUID-basierte Daten fort; Memberships, OAuth Server, REST, Core und Log schärfen zugleich die Übergänge zwischen CMS, angebundenen Diensten und laufendem Betrieb.
Dieser Bericht basiert auf den verfügbaren Release-Informationen und dient Projektteams zur Orientierung. Ein Teil der Hinweise beschreibt Migrationen und interne Verträge statt sichtbarer Funktionen. Update-Entscheidungen sollten deshalb auf den im jeweiligen Projekt installierten Paketen, repräsentativen Daten und Tests in einer Staging-Umgebung beruhen.
Was sich geändert hat
Datenbankmodernisierung erreicht weitere Geschäftsdaten
Order 2.11.4 migriert die verbliebenen alten UUID-Spalten und die Spalte für Bestellreferenzen und repariert Ersteller-Spalten während der Einrichtung. Memberships 2.3.0 normalisiert Mitgliedschaftsbenutzer auf UUIDs und macht die Benutzersuche unabhängig von der Datenbank-Collation. Purchasing 2.5.1 und Rating 2.1.0 stellen ihre Persistenz auf DBAL um; Permalinks 2.0.0 führt eine DBAL-basierte Speicherung für Permalinks ein.
Diese Änderungen liegen überwiegend unterhalb der Redaktionsoberfläche, betreffen aber langlebige Projektdaten. Eine einheitlichere Datenbankschicht reduziert Sonderfälle in der künftigen Wartung. Migrationen von Bestellungen, Mitgliedschaften, Einkaufsdaten, Bewertungen und URLs sollten dennoch mit realistischen Daten und aktuellen Sicherungen geprüft werden.
Laufzeit und Paketverträge wechseln auf die aktuelle Plattformlinie
Mehrere Hauptversionen beenden ältere Kompatibilitätspfade. Permalinks und Rating zielen nun auf QUIQQER Core 2, Rating setzt PHP 8.2 voraus, und Payments Gateway 2.0.0 wechselt auf PHP 8.2, Core 2 und Payments 4. Purchasing erlaubt ebenfalls Payments 4; Memberships richtet sich an ERP 4 aus.
Damit entsteht eine konsistentere Abhängigkeitsbasis, die jedoch nicht für jede Installation ohne Prüfung übernommen werden sollte. Projekte mit eigenen Erweiterungen oder älteren Laufzeitumgebungen sollten Composer-Vorgaben und Integrationscode kontrollieren, bevor diese Pakete gemeinsam ausgerollt werden.
Integrationen erhalten klarere und portablere Schnittstellen
Memberships ergänzt einen MCP-Provider und verbessert Grid-Aktionen, die Ereignisbehandlung bei Bestellungen ohne Kunden, die Suche sowie den Erhalt von Zeitzonen am Ende eines Mitgliedschaftszyklus. OAuth Server 3.3.1 ergänzt portable Datenbankunterstützung und liefert Middleware-, Konfigurations-, Token-Datums- und Fehlerantworten konsistent als JSON. REST 3.2.1 stellt die Slim-Fehlermiddleware bereit und hält erzeugte OpenAPI-Dokumentation auf dem aktuellen Ursprung.
Für angebundene Werkzeuge sind dies nützliche Verbesserungen an den Systemgrenzen, kein neues Integrationsprodukt. Fehler lassen sich verlässlicher verarbeiten, Datenbankannahmen werden reduziert, und Automatisierungen erhalten einen eigenen Zugang zu Mitgliedschaftsdaten. Bestehende OAuth- und REST-Clients sollten trotzdem gegen ihr erwartetes Status- und Payload-Verhalten getestet werden.
Core und Logging machen Fehler berechenbarer
Core 2.26.0 behandelt PHP-Fehler, ohne jeden Fall in eine Exception umzuwandeln, vereinfacht die Ausgabe unbehandelter Exceptions, zeigt Terminalaktivität während laufender Werkzeuge und protokolliert veraltete user.xml-Tabs. Log 2.2.1 übernimmt die Fehler- und Exception-Handler aus Core, trennt Logdateien für DEV und DEBUG, ignoriert unterdrückte Fehler und behandelt fehlgeschlagene Logfilter robuster.
Zusammen sollen diese Änderungen Betriebsfehler leichter nachvollziehbar machen, ohne unnötiges Rauschen zu erzeugen. Teams sollten eigene Error-Handler und Monitoring-Regeln prüfen, besonders wenn Logdateinamen oder Exception-Ausgaben in automatisierte Abläufe eingebunden sind.
Was das für Projekte bedeutet
- Datenmigrationen sind das zentrale Betriebsthema. Einrichtung, Update und Rückweg sollten mit repräsentativen Bestell-, Mitgliedschafts-, Einkaufs-, Bewertungs- und Permalink-Daten getestet werden.
- PHP 8.2, Core 2, ERP 4 und Payments 4 bilden für mehrere aktualisierte Module die aktuelle Kompatibilitätslinie.
- MCP-, OAuth- und REST-Integrationen erhalten klarere Schnittstellen; angebundene Systeme sollten gegen das geänderte Fehler- und Payload-Verhalten geprüft werden.
- Die sichtbaren Änderungen für Redaktionen bleiben schrittweise: bessere Memberships-Aktionen und verlässlicheres Verhalten statt einer neu gestalteten Oberfläche.
Betriebshinweise
Vor Datenmigrationen sollte eine aktuelle Sicherung erstellt und die Composer-Auflösung in der Zielumgebung geprüft werden. Eigene Implementierungen müssen mit den neuen Hauptversionsvorgaben abgeglichen, OAuth- und REST-Clients durch Integrationstests geprüft und Mitgliedschaftsdaten über die im Projekt verwendeten Zeitzonen hinweg kontrolliert werden. Da mehrere Release-Hinweise knapp ausfallen, bleiben die Paket-Changelogs die maßgebliche Quelle für installationsspezifische Entscheidungen.
Ausblick
QUIQQER 2.26 ist vor allem ein Grundlagen-Release. Es reduziert ältere Datenbank- und Laufzeitannahmen, definiert das Verhalten von Integrationen eindeutiger und richtet die Fehlerbehandlung zwischen Core und Log aus. Damit entsteht eine einheitlichere Basis für den Betrieb von Live-Projekten und die Erweiterung der Plattform ohne unnötige Altpfade.