May 2026 Releases

Internal "Déjà Vu" object caching was retaining previous Component template settings.

When a Component template was initially applied or removed, this was not reflected in the CMS administration interface.

The Déjà Vu cache is now refreshed when Component templates are applied.

Changes to the component templates are now reflected immediately in the administration interface.

Losing the connection after the cache expired blocked session verification.

Keys for JWT signature verification are now stored, using earlier values if the key service is unavailable.

If Squiz DXP connectivity is lost, valid sessions remain active, so sites stay available.

Squiz Content Management did not have a facility to check if the submission log cron succeeded or failed to send an email report.

A log now records the submission log email status so users can check it.

Template changes moved content out of a newly locked template zone (an area where editing is restricted) and into an unlocked zone (where editing is allowed).

Content saved to the page went missing because it was not correctly matched to node(s) in the new zone by nodeId, nor did it appear in Unused Content. The editors couldn’t recover missing content.

The saved page content for any template-managed blocks that have been moved now correctly appear in the new location. Any blocks leftover in the newly locked zone will appear in unused content.

Improper handling of errors from the content service when canceling the safe edit status caused the status change to continue even when errors occurred. Squiz Content Management and the content service became out of sync, preventing the page from being edited.

The status change now fails or reverts if errors occur in the content service during draft updates. Squiz Content Management and content service now sync when canceling safe edit.

Fixed an issue where webhook microservice pods entered an Error state and restarted when a sample request was sent with the query parameter ?raw=true and the content type was set to multipart/form-data.

Fixed an issue where calling a flow’s webhook URL could still run a flow after the Webhook trigger had been replaced by a Polling trigger.

Fixed an issue where applying a storage container quota could fail when the quota limit was exceeded, and the container rollback process then set the recorded usage value to null.

Fixed an issue where deleting an active flow did not release container usage.

Fixed an issue where calling v2/flows/:id/run-now erroneously created an execution associated with the Webhook trigger.

Initial component release: copy workspace and flow actions.

Initial component release with these key features:

Improved logging for Axios, with updated dependencies:

When an SVG was added to a formatted text field that contains xlink:href tags, those <svg> elements failed to render because all HTML attributes that contained a colon character were stripped out.

The update now identifies xlink:href tags in the sanitization logic and converts them to href.

SVG files using xlink:href attributes now render correctly.

Read the May 2026 new features to learn more about this known issue affecting public user accounts.

The XML Data Source asset previously only allowed a URL as its data source. Some users pointed to this data source as a file:// URL for a file on the local file system; this option is not possible in a SaaS-hosted environment.

Squiz Content Management File assets also had to be live and publicly readable to be used through the URL mechanism, precluding the use of privately stored assets as a source.

The same reason precludes the use of File Store for this purpose.

The XML Data Source can now point to an appropriate Content Management asset. XML File assets, as well as Text File assets and their descendant types, can be used as the source as long as the XML is well-formed.

All keys were expected to have a specific prefix, but it was sometimes missing. This condition would cause some matching to fail, and the form option keys would be returned instead of values.

The fix ensures that both prefixes are now considered. The keyword values are printed as expected when this keyword is used in multiple-choice/select forms.

The backend system did not check if the Reply-To header was empty before sending any Workflow emails. Workflow emails with a blank Reply-To header were bounced by Amazon Simple Email Service (SES).

The fix ensures that the system uses a default email for Reply-To and drops Reply-To from the header if no email is set. Customers using a bot, or a user account type without email, will send Workflow emails using the default email address.

A user with write access to an asset could not clone the asset if it had a metadata schema that they did not have admin access to.

This would cause the clone operation to fail, even though they have write access to the asset.

The fix ensures that when checking link types during cloning, notice links are always allowed, preventing the cloning operation from prematurely erroring.

Cloning the asset you have write access to will clone; however, the metadata schema you do not have admin access to will not clone.

Asynchronous sessions allow requests to be handled without waiting for other requests to complete. Asynchronous sessions have been progressively rolled out by feature flag since November 2025 and are now considered stable.

The feature flag is now removed, and this feature is now the baseline state.

Asset Management API users were able to select a reference page that their token did not have access to (that is, not available under the root node to which the API was permitted to act upon).

Validation now fails if an API user tries to select a reference page for which their token does not have scoped permissions.

The existing handlebars version "4.7.7" had a critical vulnerability (https://nvd.nist.gov/vuln/detail/CVE-2026-33937).

The Handlebars version has been updated to "4.7.9," which resolves the vulnerability.

The SEO Auditor tool was configured to look up and evaluate metrics only using the exact URL specified in a page’s canonical tag, rather than the actual source URL processed by the indexer.

For content containing canonical URLs, the SEO Auditor failed to retrieve data for Total words, Unique words, and Fully-matching results, leaving these analytical metrics broken or empty.

The lookup logic within the SEO Auditor has been updated. The tool now attempts to match the data against both the canonical URL and the actual indexer URL.

SEO auditing metrics like word counts and matching results now accurately display and calculate for all indexed pages, regardless of whether a canonical URL is defined.

Accessibility auditor needs to support WCAG 2.2 specifications for HTML techniques.

Changes have been made so that technique 3.3.7 is now detected by the accessibility auditor.

The default page size of 25 was being used, and even though the date range exceeded it, the page size remained the same, leaving the chart empty. No data in the chart when the user selected a custom date range

The fix ensures the page-size calculating method is used with start and end dates selected by the user, which now correctly calculates days between the selected start and end dates. The chart behavior reflects the date-range selection and produces the correct output.

Not having a configuration to exclude empty/blank search results caused "" to appear in reporting alongside other searches. The reports showed blank or empty search stats at the top.

The fix ensures that files with reporting-stop-words.cfg prevent blank or empty search results from appearing in the report page.

The search 404 and system error pages (4xx/5xx) used generic Jetty HTML that did not meet accessibility standards. Additionally, image scaling error responses were leaking low-level server and connection details.

The 404 page was flagged as non-compliant by accessibility checkers, impacting users with disabilities and mobile device users. Furthermore, technical messages in the /s/scale parameters created a security risk by allowing potential probing of internal infrastructure.

The fix replaces generic error pages with Funnelback-styled HTML that meets WCAG 1.4.10 reflow requirements. Restricted image scaling error messages to generic text and separated container-level Jetty errors into a self-contained "web server error" page.

Error pages are now fully accessible and mobile-responsive. Security is improved by suppressing sensitive internal host information from public-facing responses.

During indexing, metadata values can be incorrectly applied to other metadata of similar names. As a consequence, metadata can contain more values than expected.

A fix was applied to padre-iw to ensure the correct metadata is applied. After reindexing a data source, the correct metadata is returned in the search results.

There were multiple issues with the Analytics and accessibility charts area. While scrolling through the Timeframe drop-down, the export button was activated and overlapped with the Timeframe drop-down. When the top keywords component on the Search analytics page had a long list of keywords, it was expanding through the charts below. The accessibility auditor landing page had issues with the export button expanding its menu and submenu when trying to click on tabs.

Multiple fixes were applied to make the Analytics and AA experience seamless.

The padre indexer has an optional feature that adds alternative spellings for non-English letters (e.g., turning ä into ae). A bug meant that on unusually long words, it could corrupt data while building that extra spelling. The fix ensures no corruption occurs. Files containing non-English-style letters are indexed correctly.

In metadata select field keyword options, null values were not being checked for when handling key-value options in metadata. In some cases this condition caused a fatal TypeError to occur.

The null values are now accounted for in the checking logic, and a safe default is applied where null values exist. Anything rendering metadata field options with null values no longer fatally errors in this way.

Fixed an access issue that existed under very specific conditions.

Fixed an access issue that existed under very specific conditions.

Custom input types (FormattedText, SquizImage, SquizLink) were hard to find because they sat alongside basic types without a clear structure in the Input types documentation. Readers also had very few signposts from manifest and tutorial content.

Improvements: * New Input types sidebar groups Basic types and Custom types have been introduced with distinct headings. * Introductory text on the Input types index calls out the split. * Cross-references now point to the custom type pages from Getting started (manifest.json), Components at Edge (manifest changes), and Create a component (component files).

Users will now see a standardized "TIP" admonition on all relevant documentation pages directing them feature comparisons and Squiz Academy eLearning resources to support their transition.

These content additions are designed to provide consistent, high-visibility guidance encouraging users to transition from legacy Standard Pages to the modern Content Page asset in Page Builder.

Read the May 2026 new features to learn more about serving 404s on unpublished pages.

Read the May 2026 new features to learn more about marking your favorite flows in the Integrations flows list.

Read the May 2026 new features to learn more about the trigger type indicator.

Read the May 2026 new features to learn more about placeholder text support.

Read the May 2026 new features to learn more about viewing Datastore importer logs in Squiz DXP Console.

Read the May 2026 new features to learn more about placeholder text support.

Teams could not rename or delete component sets in the Squiz DXP Console, which made it challenging to manage out-of-date or renamed sets and caused confusion when obsolete sets remained visible.

To address this feature gap, Component Service users can rename component sets and remove sets they no longer need.

The Managing component sets tutorial documents how to update name and description, confirm deletion, and what happens to existing site content after a set is deleted. Users can maintain component set metadata in the console and remove unused sets while existing pages that already use components or layouts from a deleted set continue to work.

Read Managing component sets in the Component Service documentation for more information.