Release: QUIQQER 2.29
Executive summary
QUIQQER 2.29 is a broad maintenance release with a clear operational theme: make established projects easier to update, make connected systems more predictable, and defer more frontend work until it is actually needed. Core 2.29.2 adds migration and mail-placeholder groundwork, Cache 3.2.11 revises JavaScript bundle delivery, and Order 2.13.1 strengthens order histories and separates basket initialization from the first page render.
Security and data quality also receive focused work. Frontend Request Signing now honours configured token lifetimes and handles invalid or unusual responses more defensively. Controls improves JSON-LD generation, while Products Feed tightens machine-readable prices and subscription values. This report is based on the available release notes and is intended as orientation; the packages installed in a project and its custom integrations remain decisive for rollout planning.
What changed
Core prepares cleaner migrations and integration services
Core 2.29.2 runs the user-address migration during setup and migrates the legacy address column. It also adds mail-placeholder services for users and groups and extends MCP handling for protected system information and project settings. A filled-or-empty mode for settings dependencies gives configuration screens a more precise way to express when a field should be available.
For maintained installations, the practical benefit is less manual cleanup around older user data and clearer service boundaries for mail and trusted automation. Because the address work runs during setup, teams with long-lived databases should still test the migration against representative records before production deployment.
Cache restores asynchronous delivery with safer fallbacks
Cache 3.2.11 keeps AMD modules in reusable package bundles, defers generated JavaScript bundles, and restores asynchronous loading. It also handles failed command-availability checks in the optimizer.
The aim is to reduce avoidable work during the initial page load without losing reusable module bundles. Projects with custom frontend modules or strict performance budgets should compare rendered pages and browser-console output before and after the update, especially on routes with many deferred components.
Commerce workflows are separated and recorded more explicitly
Order 2.13.1 decouples the frontend basket from orders, defers basket initialization and footer scripts, and passes checkout query data through the site interface. Order status history is now persisted, while additional coverage hardens checkout and order workflows. Customer 2.7.0 complements this with more robust handling of nullable order customers, modernized customer search and open items, and predictable demo-data numbering.
These changes should make commerce pages less dependent on eager frontend initialization and give operational teams a clearer record of status changes. Custom checkout, basket, ERP, and reporting integrations should be tested together because the improvements cross module boundaries.
Request signing handles token and response edge cases
Frontend Request Signing 1.1.1 respects the configured token lifetime, reads JWT headers case-insensitively, preserves the session when a token is invalid, and ignores AJAX responses that are not objects. The package also raises its quality baseline to PHP 8.2 and hardens request interception.
This narrows several assumptions that can cause difficult integration failures: header casing, token expiry, unexpected response types, and invalid-token recovery. Applications using custom AJAX endpoints should include these cases in staging tests rather than validating only the successful request path.
Structured data, feeds, and editing receive focused improvements
Controls 2.4.3 introduces a reusable JSON-LD utility, decodes nested HTML entities before encoding, and omits empty article authors. Products Feed 2.1.4 formats prices and Google subscription amounts for machines and guards serialization and field values. Together, these changes reduce malformed or ambiguous output consumed by search engines and external catalogues.
Bricks 2.32.0 adds a native single-button brick and configurable data-* attributes, preserves button styling on cache hits, and clarifies conditional popup settings. Template Presentation 6.11.0 adds a section-radius design token and guided landing-page creation support. These are smaller editor-facing changes, but they make reusable components easier to configure without weakening cached presentation.
What this means for projects
- Long-lived installations should test the Core user-address migration with a recent database copy.
- Frontend-heavy sites should verify deferred JavaScript, AMD modules, and custom controls across cached and uncached pages.
- Commerce projects should test basket startup, checkout queries, status histories, ERP connections, and nullable customer records as one workflow.
- Signed frontend integrations should test token expiry, header casing, invalid-token recovery, and non-object AJAX responses.
- Sites publishing structured data or product feeds should validate generated JSON-LD and machine-readable prices with their usual external tools.
Operational notes
Take a current backup before running setup migrations. Apply the update in staging with representative user records, cached frontend routes, signed requests, and commerce transactions. Where release notes are brief, package-level changelogs and project-specific tests remain the authoritative basis for deployment decisions.
Looking ahead
QUIQQER 2.29 does not revolve around one headline feature. Its value lies in coordinated groundwork: migrations become more explicit, frontend work is deferred more deliberately, integrations handle edge cases more carefully, and editors gain more precise reusable controls. For established projects, that combination is more relevant than the number of packages released in the same window.