Release: QUIQQER 2.26
Executive summary
QUIQQER 2.26 brings a broad week of maintenance into a clearer platform direction. Across 60 package updates, the most relevant work centres on database modernization, current runtime requirements, more dependable integration surfaces, and stricter error handling. Order, Permalinks, Purchasing, and Rating continue the move toward DBAL and UUID-based data, while Memberships, OAuth Server, REST, Core, and Log refine the boundaries between the CMS, connected services, and day-to-day operations.
This report is based on the available release information and is intended as orientation for project teams. Some notes describe migrations and internal contracts rather than visible features. Update decisions should therefore be based on the packages installed in a project, representative data, and testing in a staging environment.
What changed
Database modernization reaches more business data
Order 2.11.4 migrates remaining legacy UUID columns and the order-reference column, and repairs creator columns during setup. Memberships 2.3.0 normalizes membership users to UUIDs and makes user searches safe across database collations. Purchasing 2.5.1 and Rating 2.1.0 move their persistence to DBAL, while Permalinks 2.0.0 introduces DBAL-backed permalink storage.
These changes are mostly below the editor surface, but they affect long-lived project data. A more consistent database layer reduces special cases for future maintenance; at the same time, migrations involving orders, memberships, purchasing records, ratings, and URLs should be tested with realistic data and current backups.
Runtime and package contracts move to the current platform line
Several major-version updates retire older compatibility paths. Permalinks and Rating now target QUIQQER Core 2, Rating requires PHP 8.2, and Payments Gateway 2.0.0 moves to PHP 8.2, Core 2, and Payments 4. Purchasing also allows Payments 4, while Memberships aligns with ERP 4.
The practical effect is a more coherent dependency base, but this is not a drop-in change for every installation. Projects with custom extensions or older runtime environments should review Composer constraints and integration code before rolling out these packages together.
Integrations receive clearer and more portable interfaces
Memberships adds an MCP provider and improves grid actions, event handling for orders without customers, search behavior, and preservation of membership-cycle time zones. OAuth Server 3.3.1 adds portable database support and makes middleware, configuration, token-date, and error responses consistently JSON-based. REST 3.2.1 exposes Slim error middleware and keeps generated OpenAPI documentation on the current origin.
For connected tools, these are useful boundary improvements rather than a new integration product. Errors become easier to process, database assumptions are reduced, and automation gains a dedicated route into membership data. Existing OAuth and REST consumers should still be checked against their expected status and payload handling.
Core and logging make failures more predictable
Core 2.26.0 handles PHP errors without converting every case into an exception, simplifies uncaught-exception output, reports terminal activity while tools run, and records use of deprecated user.xml tabs. Log 2.2.1 adopts the Core error and exception handlers, separates DEV and DEBUG files, ignores suppressed errors, and handles failing log filters more defensively.
Together, these changes aim to make operational failures easier to diagnose without adding unnecessary noise. Teams should review custom error handlers and monitoring rules, especially where log-file names or exception formatting are part of an automated workflow.
What this means for projects
- Database migrations are the central operational theme; test setup, upgrade, and rollback paths with representative order, membership, purchasing, rating, and permalink data.
- PHP 8.2, Core 2, ERP 4, and Payments 4 form the current compatibility line for several updated modules.
- MCP, OAuth, and REST integrations gain clearer interfaces, but consumers should be tested against the revised error and payload behavior.
- Most editor-facing change is incremental: improved membership actions and steadier behavior rather than a redesigned interface.
Operational notes
Take a current backup before applying data migrations and verify Composer resolution in the target environment. Check custom implementations against the new major-version constraints, run integration tests for OAuth and REST clients, and confirm membership dates across the time zones used by a project. Because several release notes are concise, the package-level changelogs remain the authoritative source for installation-specific decisions.
Looking ahead
QUIQQER 2.26 is primarily a foundation release. It reduces older database and runtime assumptions, gives integrations more explicit behavior, and aligns error handling across Core and Log. The result is a more uniform base for maintaining live projects and extending the platform without carrying as many legacy paths forward.