Release Notes

GraalJS, the engine that will replace Nashorn, is available as a preview. It implements the current ECMAScript standard, where Nashorn stops at ES5.

Nashorn remains the default and the supported engine. The engine is chosen per application via the X-Script-Engine header in the bundle manifest, with the installation default set in system properties. A single app can be moved to GraalJS and back without affecting the others. The differences for application code - module state per context, disposer registration, executeFunction - are described in the dev kit documentation on JavaScript engines.

On both engines, main.ts now completes before anything else in the app runs on that node. Initialization code no longer needs guards against early requests.

Four changes make scheduled jobs more predictable in a cluster:

A task started by the scheduler can read the previous run’s task id from the schedule.lastTaskId context attribute, useful for incremental processing; see what a scheduled task receives. Jobs declared in the scheduler config file are now created by the node that runs the scheduler, and new entries are picked up without a restart. See the scheduler library.

A request-scoped CSP builder replaces hand-assembled header strings. One policy is shared for the whole request, so the page, its layouts, its parts and any response processor all contribute to a single header, nonce included. The header is composed when the response is flushed, so late contributions are not lost. A report-only companion lets you enforce one policy while trialling a stricter one. A Content-Security-Policy header set directly on the response is folded into the policy rather than sent as it is, so later contributions still apply. See csp() in the portal library.

Admin extensions get the same control over the tool page that hosts them. A new Java SPI lets an extension adjust the tool’s CSP and add page contributions. See extension response processors.

A new admin events hub lets an application define its own topics and publish to them. Admin tools and extensions receive live updates over one shared connection instead of each opening its own. See setTopic() in the admin library.

Two additions to query() in the node and content libraries:

In the Java API, NodeService gains list and enumerate methods for reading a subtree in path order. ListNodesResult and its recursive flag are removed; see the upgrade notes.

An export now reads each node at the version its scan observed. A subtree that changes while the export runs is written as it was seen, not as a mix of old and new. The batchSize parameter of exportNodes() is ignored as a result.

readThrough.cacheCapacity caps the local cache in front of a remote object store. See file blobstore configuration.

threadPool.virtualThreads moves request handling to virtual threads. A request waiting on I/O - a database round trip, an outbound HTTP call, a slow client - no longer occupies a platform thread while it waits, so I/O-bound traffic stops tying up the pool. CPU-bound requests gain nothing. Selectors and acceptors stay on platform threads. See Jetty configuration.

Still working, slated for removal. The upgrade notes show the replacement for each:

The XP 8 core runs on a refreshed stack, including but not limited to: Java 25, Jetty 12, and Hazelcast 5. This also includes use of virtual threads for tasks. The new stack provides better performance, stability, and security, and lays the foundation for future improvements.

XP 8 introduces a new admin UI built on the Enonic UI design system. The new UI is faster, more responsive, and provides a more consistent user experience across tools. The first tools to be migrated are the XP menu and the Dashboard. The remaining tools will be migrated in future releases.

Web APIs are now first-class citizens of Enonic XP. A uniform implementation pattern can be used to implement and expose APIs across the platform, including direct exposure via the brand new /api service endpoint.

Borrowing the manifest-and-mount pattern from Kubernetes, APIs are registered with a unique name and automatically integrated with the platform’s security and IAM. A matching set of libraries and tools makes it easy to build custom APIs and call them from any context.

APIs can be exposed on custom URLs and domains via virtual host configuration, but also contextually mounted within the admin and site services, allowing for flexible API design and organization.

YAML replaces XML for all CMS schemas and app descriptors. This means content types, application definitions, ID providers, etc., are now all defined in YAML. YAML is a widely adopted format that is easier to read and write than JSON, especially for complex configurations - and it supports comments. The new YAML-based descriptors are more concise and maintainable, making life easier for developers. For the full documentation, visit the schema system documentation.

Every schema is identified by the name of the app that ships it, as <app>:<name>, such as com.example.myapp:article, in the same way as APIs, tools and extensions. Platform-provided types use the reserved names base, portal and media.

The permission model is stripped back to essentials in XP 8:

The underlying Node and Content APIs follow the same model. See Permissions for the full picture.

The major Enonic apps have been refreshed alongside the platform and are ready for XP 8.

The Widget API has been replaced by the Extensions API, better reflecting the actual capabilities. Visible tools live in the XP menu, while extensions, you guessed it, extend them - ranging from visual widgets to API-level functionality. The new API is more flexible and powerful.

Additionally, popular extensions such as Content Studio widgets are now wrapped as web components, for complete isolation and flexibility.

Visit the Dev kit documentation for implementation details.

Years of incremental additions left overlap in the platform Content and Node APIs. XP 8 cleans them up:

Metrics are now exposed in the open OpenMetrics format - point your Prometheus, Grafana agent, or any compatible collector at the metrics endpoint to get first-class observability.

Vhost configuration files now support declaration of context values - project, branch, principal - co-locating routing decisions with the vhost they belong to. This may also be used to customize application behaviour on a per-vhost basis. See Virtual host context.

XP8 also implements support for Server Sent Events (SSE) across all web services, enabling real-time streaming of data to clients without using WebSockets. This is particularly useful for building APIs and applications that require live updates, such as dashboards or notifications, but do not require the full duplex communication provided by WebSocket.

Identity keys, content IDs, names, and descriptors now follow consistent, deterministic validation rules: lowercase-only IDs, explicit regex per key type, and length caps that match what the system actually supports. The intent is to eliminate the class of bugs that came from quietly accepting characters that broke serialization, URLs, or filesystem paths downstream. The full ruleset lives in the dev kit upgrade guide.

Repositories can now be exported in full or in part - by branch and path - and repositories may be dumped and loaded individually.

Exports and dumps are written directly to ZIP archives, replacing the previous folder-based structure. The plain-file format and dry-run mode have been retired.

A handful of smaller-but-pleasing improvements:

XP 8 renames or reframes several familiar XP 7 concepts. Use this map when reading XP 7-era documentation, examples, or AI-generated code — the old terms no longer apply, and in some cases have taken on new meanings:

The complete map, with migration details, lives in the dev kit upgrade guide.