Squidex 7.22.0 and 7.23.0 brought a simpler way to make string fields searchable, resolvable comments with a dedicated view, HTTP requests from scripts, and an upgrade to .NET 10 and Angular 21. The follow-up release added SSRF protection for asset downloads and scripting HTTP clients.
Two releases went out this quarter: 7.22.0 with a large batch of backend, frontend and scripting changes, and 7.23.0 with security hardening and a serialization fix. Here are the parts that change how you work with Squidex day to day.
String fields can now be marked as search fields. A field that is added to full text search this way is matched with a simple contains search, which is useful when you want a field like a product code, an internal reference or a short title to be findable without going through the full text pipeline in the usual way.
The practical effect is that you decide per field what participates in search, instead of relying on a single global behaviour for all text content. If your editors keep asking why a certain value does not show up in the search box, this is the setting to look at.
Comments in the content editor can now be resolved. Once a comment has served its purpose, an editor marks it as resolved and it disappears from the working view, so the remaining comments are the ones that still need attention.
Resolved comments are not lost. A new view shows resolved comments as well, so the discussion history around a content item stays available for later review or for an audit trail.
Around this, the content editing UI received a set of layout changes: a new responsive menu for content fields, a button to increase the width of the left panel, and improved form rows across all forms. Fullscreen mode for content fields was fixed, and there were further fixes in the rich text editor.
Scripting gained a method to make particular HTTP requests, so a script can call an external endpoint as part of a content workflow instead of pushing that logic into a separate service. A new flag lets a script ignore HTTP errors, which is what you want when the call is best effort and a failing endpoint should not abort the operation.
Schemas also received User Info fields that contain API keys for authentication. These give scripts and integrations a place to store the credentials they need alongside the schema definition.
In 7.23.0, both of these paths were hardened. SSRF protection was added for scripting HTTP clients and for asset downloads, so a URL supplied by a script or by an asset import can no longer be used to reach internal network addresses through the Squidex instance. If you run Squidex inside a cluster or a private network with services that are reachable without authentication, this is the change to prioritise when planning your upgrade.
The backend was updated to .NET 10, and the frontend toolchain moved to Node and Angular v21. These are platform upgrades rather than feature work, but they matter for anyone building a custom deployment: your base images, build agents and any code that compiles against Squidex need to match the new runtime versions.
The frontend also received several accessibility fixes, mainly using buttons and anchors correctly so that keyboard navigation and assistive technology behave as expected. Screen readers announce interactive elements based on their markup, and mislabelled elements are a common reason for content editors being unable to work with a keyboard alone.
German was added as another language for the user interface, which you can select for your account like the other supported languages.
A new option lets you disable the full frontend UI. If you run Squidex purely as an API for a headless setup and do not want the management interface exposed on that instance, you can now turn it off rather than blocking it at the proxy level. Path bases are also resolved correctly now, which helps when Squidex is hosted under a sub path behind a reverse proxy.
A typical deployment that serves only the API and sits behind a proxy therefore has two settings to review:
services:
squidex:
image: squidex/squidex
environment:
- URLS__BASEURL=https://api.example.com/squidex
Check the configuration reference for the exact option names in your version before changing a running deployment.
Several fixes landed in the OpenAPI spec, which affects anyone generating a client from it. On the content side, zeros are now allowed as custom IDs, and the serialization of status fields for contents was fixed in 7.23.0. The frontend now encodes JSON query strings correctly, and the query system received several further fixes, so saved and shared queries behave more predictably in the content list.
If you are upgrading from an earlier version, read the changelog entries for 7.22.0 and 7.23.0 in the repository, and test the .NET 10 and Angular 21 upgrade against your own build pipeline before rolling it out. The Squidex documentation covers the scripting API and schema field settings in detail if you want to try the new search fields or HTTP requests in a local instance first.