August 2026 Releases

The read-only logic used for masking the value was incorrect. This meant masking could occur even when you had locks or editing values in a trigger action, resulting in the mask being saved to the database.

The fix ensures that the read-only logic shows the real values when you are editing. The Request Header field on a REST Resource inside a trigger (using the 'Call REST Resource' action) now contains the correct value when editing.

When editing role permissions in the Admin UI, entering edit mode on a resource table (for example, Collections) refreshed the logged-in user’s details. If the current user was a member of the role being edited, the UI incorrectly replaced the role being edited with the logged-in user. Subsequent grant/revoke API calls were sent against the user ID instead of the role ID. Administrators who were members of a custom role (for example, a ~resources role) received an "Access denied" (HTTP 403) error when trying to assign collections or other resources to that role. The issue did not occur when editing a role the user was not a member of. Updated the shared resource table logic so that targetUser is only refreshed when editing your own user account (currentUser.id = targetUser.id). When editing a role, the role ID is preserved for grant/revoke API calls while flattened permission data continues to refresh for display. Users with permission to edit custom roles can now assign collections and other resources to roles they belong to, without receiving a permissions error.

The suggest and cache endpoints did not validate the profile request parameter against the collection’s configured profiles. Invalid values, including excessively long profile names, could be passed to downstream native search components. Requests to /suggest.json or /cache with an invalid profile could cause JNI failures and restart the Jetty search service, resulting in temporary search downtime. Added ProfilePicker validation to SuggestController and CacheController so invalid profile values are replaced with the default profile (_default) before processing. Suggest and cache requests with invalid profile values now fall back to the default profile instead of crashing the search service.

When a backend user was joined to the System Administrators group for the current session (for example via the Assign user to groups trigger action), session privilege flags were not updated. Navigation history could also fail when sq_nav_history had not been set.

The asset tree could fail to load or behave incorrectly after the user was assigned to the System Administrators group.

The fix updates session privilege flags for session-only group links and ensures navigation history session data defaults safely when it has not been set. The asset tree continues to work when a backend user is granted System Administrator access for the current session.

On PHP 8.1, viewing the trigger details screen for a trigger that uses the Set future status action could display PHP deprecation warnings.

Warnings appeared when trigger configuration stored a null or legacy value for the When condition, or when date values were empty.

The fix adds null-safe handling for When conditions and date parsing on the trigger details screen. Trigger details for Set future status actions no longer show PHP 8.1 deprecation warnings.

When the Public User account was not linked to any user groups, Matrix Accelerated Cache (MAC) emitted a public_user permission instead of default for anonymous requests.

Cloudflare could not serve the cached response to users without a session, so public content was not cached correctly.

The fix ensures the default permission is emitted when the Public User has read access to an asset, even when the Public User is not a member of any groups. Public content is now cached correctly for anonymous visitors when MAC is enabled.

This resolves the known issue documented in the May 2026 release notes.

Matrix asset type icons have been refreshed to match the latest Squiz design. Updated icons appear throughout the admin interface, including the asset tree, asset listings, and the Create Asset screen.

Asset types without a dedicated icon continue to inherit an icon from a parent type. No functional behaviour of asset types has changed.

Asset Management API and Content Delivery API token values were previously displayed in full in the Matrix admin interface after creation. Users with access to a token asset could view and copy tokens created by other users.

Token values are now shown in cleartext only once, on the same request where the token is generated or regenerated on the token Details screen. A Copy button is available at that time. After you save, only the last three characters of the token are shown. The API Manager overview lists masked token values instead of full values. You can regenerate a token from the Details screen if you need a new value.

Existing tokens continue to work. After upgrading, open a token Details screen to view the masked value, or regenerate the token to obtain a new value. Regeneration invalidates the previous token immediately.

The Current section on the asset Roles screen was too narrow to show two asset pickers and the Global? checkbox in full. Controls could overlap or be clipped, making role assignment difficult to use.

The fix widens the asset picker layout on the Roles screen so pickers, the asset tree selection button, and the Global? checkbox display correctly when editing role assignments. The Roles screen is usable when configuring role assignments on an asset.

The JavaScript API expected asset IDs to be passed as a string or a number. Requests that sent asset IDs in another format (such as an array of values) previously resulted in a server error. They now receive a clearer error message, including a "badRequest" error code in the JSON response.

A recent improvement to the reference report (on the Linking screen) to track default metadata caused a regression. If an asset’s metadata contained a related asset metadata field that was no longer part of a metadata schema (eg. in the trash), the reference report would incorrectly always return zero references. The database query that caused the issue has been corrected to permit all other references to appear.

Assets using an appropriately-crafted keyword, that would be valid to get the contents of a related asset metadata field (eg. %asset_metadata_fieldname_url%, where fieldname is a metadata field name), was causing an error in certain circumstances when the metadata field in question was not a related asset field. Also, the field name could be matched at incorrect parts of the keyword. The logic is now guarded by a strict check to ensure it is only executed on related asset metadata fields, and that field names will only match directly following the "asset_metadata_" part of the keyword.

Read the August 2026 Enablement features to learn more about the new FAQ resources.