Release Notes

The engine that will replace Nashorn is here to try. GraalJS implements the current ECMAScript standard, well past Nashorn’s ES5.

Not for production: Nashorn remains the default and the supported engine. The choice is made per application, from its bundle manifest, so a single app can move across and back without disturbing the rest. What changes for application code - per-context module state, unconditional strict mode, disposer registration, executeFunction - is covered in the dev kit runtime documentation.

Two long-standing rough edges were settled on the way. main.ts now runs to completion before anything else in the app on that node, on either engine, which greatly simplifies initialization code. And the global namespace was brought closer to what browsers and Node expose, so more npm modules run unmodified.

Three changes make scheduled jobs predictable in a cluster:

Jobs can also be declared in the scheduler config file, and the scheduler’s list response now reports each job’s run state. See the scheduler library.

A request-scoped CSP builder replaces hand-assembled header strings. One policy is shared for the whole request, so a page, its layouts, its parts and any response processor all contribute to the single emitted header, nonce included - and the header is composed when the response is flushed, so late contributions still land. A report-only companion runs alongside it, letting you enforce a settled policy while trialling a stricter one.

An admin events hub lets an application define its own topics and push to them, so admin tools and extensions receive live updates over a shared connection instead of each opening its own. See the admin library.

The returns parameter has each hit carry named index fields, so a listing that needs a name and a path no longer costs a read per hit. The values come from the search index, so they are as fresh as the index - where the exact value matters, read the node.

parent restricts a query to the direct children of a node, and descendant widens it to the whole subtree beneath it. Available on the node and content libraries.

An export reads each node at the exact version its scan observed, so a subtree that changes while the export runs is written as it was seen rather than as a mixture.

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

threadPool.virtualThreads hands request handling to virtual threads. A request waiting on I/O — a database round trip, an outbound HTTP call, a slow client — parks its virtual thread and gives the platform worker back until the wait ends, so I/O-bound traffic stops tying up the pool. A request that computes rather than waits gains nothing. Selectors and acceptors stay on platform threads. Treat it as an experiment — not for production. See Jetty configuration.

Still working, slated for removal:

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.

Schemas are also now organized into namespaces. Every schema is identified as <namespace>:<name>. When shipping schemas with an app, the app name is still the default namespace - but the namespace concept decouples schemas from apps, paving the way for schemas to be authored and managed independently.

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.