Jahia 8.2.0: Overview

We are delighted to announce the upcoming release of Jahia 8.2.0, scheduled for the second quarter of 2024. This highly anticipated version brings various enhancements, including a new and more modern development experience, a new - optional - page-building interface, as well as upgraded frameworks and libraries. This page is meant to provide you with a clear understanding of the expected changes in Jahia 8.2.0. Please note that while we strive to provide accurate information, the final scope of the release is subject to potential adjustments. Our team is committed to keeping you informed and will promptly update this communication to reflect any changes.

What's new

Technical Updates

Drop of JDK 8 Support

Jahia 8.2 will not offer support for JDK 8, as we are updating some libraries to versions that are not compatible anymore with JDK 8.

Jahia 8.2 will remain compatible with JDK 11 and supports JDK 17 with Jahia 8.2.1.0 (more details can be found there).

We remain committed to providing a secure and forward-looking platform aligned with the latest industry standards.

Library updates

As part of our ongoing commitment to enhancing the security of our platform, we are preparing for a major release that involves upgrading several libraries and frameworks to more recent versions, thereby incorporating important security fixes.

Outlined below is the list of libraries we currently intend to upgrade. As of now, we anticipate that the impact on custom modules will be minimal. We expect that the required steps to ensure compatibility with version 8.2.0 will primarily involve updating the pom.xml file and recompiling the modules.

We will ensure to keep you informed through regular updates on this page. These updates will include the latest version used in the upgrades, as well as guidance on identifying the affected modules and instructions on the necessary steps to update them accordingly:

• Jackrabbit and Tika
• Karaf
• GraphQL
• jdom 2
• dom4j

We are also planning on upgrading the React framework, however this upgrade shall not require any adaptation on your side.

Content Editor 4 module to be merged into jContent

Jahia versions 8.0.x and 8.1.x include two modules: Content Editor and jContent. The Content Editor module offers a form interface for creating and editing content, while the jContent module provides the interface for managing content and media.

Starting from Jahia 8.2.0, these two modules will be merged into a single module called jContent 3.0. This new version of jContent will encompass the functionalities of the current jContent module, allowing users to manage contents and media. Additionally, it will include the new version of Page Composer and the functionalities of the Content Editor module.

Review of Content Editor JSON overrides

As part of this merge of Content Editor and jContent, we will be simplifying a bit the way one can customize Content Editor forms for a given nodetype, by relying on a single json override file only, instead of two (currently part of the override is done in META-INF/jahia-content-editor-forms/fieldsets, and part of the other is done in META-INF/jahia-content-editor-forms/forms ). This change is meant to simplify creation of json override files, and to provide more flexibility when moving fields and fieldset in the edition form.

We shall be able to keep compatibility with the previous JSON override files, to the exception of the target properties defined in META-INF/jahia-content-editor-forms/fieldsets to move fieldset and fields in different location of the form: such “move” will need to be done in META-INF/jahia-content-editor-forms/forms. 

Some jContent / Content Editor custom extensions may require a code update

As part of the work done in jContent and Content Editor, we will make some changes that may impact custom jContent and Content Editor extensions, which:

• Declare custom accordions in jContent, and custom accordions for the CE pickers (as documented in the “Create accordions” documentation) 
• Use the jContent content tables
• Or rely on the current path stored in redux

Customers who may have developed such custom extensions (for instance a custom property selector for Content Editor) will most likely have to adjust their code.

New server response codes when accessing protected resources

Jahia currently handles pages and files differently, when such resources are accessed by a user who does not have the read permission on them:

Behavior 1 - secure, no 401/403 - current files behavior

• resource exists : served, 200
• resource does not exist or is not accessible : 404

Behavior 2 - disclosing protected resources - current page behavior

• resource exists : served, 200
• resource exist, guest user, require authentication : 401
• resource exist, logged in, user not allowed : 403
• resource does not exist : 404

In Jahia 8.2.0, we’ll ensure the same behavior for pages and files. Customers will be able to choose which one of the two behaviors to use. By default, Jahia will use the first behavior, only serving 200 and 404 pages in live, as it is more secure and does not disclose the existence of protected resources.

If it’s not already the case, we encourage our customers to display a login form on the 404 error page, displayed when the user is unauthenticated. This will allow a user to sign in and access the resource, if allowed, right after signing in.

Bug fixes introducing breaking changes

Prevent creation of node with missing mandatory properties

In versions prior to Jahia 8.2.0, it is possible in some cases to create content nodes with missing mandatory properties, using the GraphQL API or through the usage of the “Copy to other languages” module.

This issue will be fixed with 8.2.0, meaning that it will not be possible anymore to create nodes with missing mandatory properties.

Removal of hard coded redirection in Appshell 3.0.0

Till app-shell 2.7.0, we were handling login with a hardcoded redirect to /cms/login. While this was giving an impression of expected behavior, the hardcoded redirect was not desirable. Starting with app-shell 3.0.0 (to be included in Jahia 8.2.0), this has been updated such that ErrorServlet is responsible for redirects to proper error/login pages.

With this change, when there is a 401 error and a LoginURLProvider, Jahia will always redirect to the URL returned by the provider.

See Jahia login redirects to custom login page

Deprecation and removal

Deprecation of Spring

With Jahia 8.2.0, we are deprecating the usage of the embedded Spring 3.x libraries for custom modules: OSGi is a much more flexible and dynamic framework than the Spring framework, and it is possible to replace most Spring usages with OSGi. 

Instead of using Spring, using OSGi will result in a much smoother process during Jahia upgrades. OSGi also provides much better services in terms of dynamic reloading, configuration, service sharing, library embedding, and security. 

If you use Spring libraries, especially in live Spring Web Flow applications such as forms, consider moving them to OSGi/GraphQL/React. New developments shall not rely on Spring 3.x, unless there are no alternatives for a critical capability: in such a case, please report it to the support team so we can plan to develop a replacement solution.

External Data Providers

The declaration of External Data Providers (EDP) currently relies solely on Spring. Jahia 8.2.0 will provide an OSGi alternative for EDP declaration, with a dedicated GraphQL API  to administrate mount points. The documentation will be updated to reflect this new way of declaring and managing EDP.
This new API will replace the two administration panels, Mount points and External providers,  which were developed using Spring Web Flow and which  will be moved to a dedicated community module.

Workflows

Historically, custom workflow deployments relied on Spring. The Workflow OSGi Extender module now allows custom workflows to be deployed using OSGi services and descriptors: the Scheduled Publication Workflow module is an example of implementation (store - github). The documentation is currently missing and will be provided for Jahia 8.2.0.

Page Composer

The configuration of Page Composer still relies on Spring, especially when modifications are needed in applicationcontext-*.xml files.

Deprecation of the j:fullpath property

The j:fullpath property, automatically set on versioned nodes, will be deprecated with Jahia 8.2.0. Customers relying on this property in their code shall consider a refactor, as the j:fullpath property may become inconsistent overtime.

Related Knowledge Base entry

Removal of Jahia Captcha

Current Jahia versions package an old library, Google Kaptcha 2.3, to manage captchas. This library will be removed in Jahia 8.2.0, and we advise customers relying on it to already look at newer alternatives, such as Google reCaptcha, which is more secure and provides a better experience.

Find out how to use reCaptcha with Jahia.

Removal of static libraries

In the past, Jahia has made certain libraries available externally for the convenience of our customers. However, this approach has proven to be challenging to sustain over time. The reason being that it becomes difficult to keep these libraries up-to-date, considering that Jahia and customer projects progress at different rates, each with unique needs and expectations concerning such libraries.

As we continue to work on this matter, the specific approach for handling these libraries is not yet finalized. However, there is a possibility that resources currently provided in the assets and jquery modules may be removed or no longer accessible for custom modules.

We strongly recommend that customers who rely on these libraries take ownership of managing the associated resources themselves. This allows you to have greater control over the lifecycle of these resources and reduces dependency on Jahia updates.

Furthermore, we are exploring the option of transitioning these modules from Jahia to community modules. This move could simplify the process of updating your modules in the short term.

We will keep you informed of any developments regarding this transition and provide guidance on the necessary actions to be taken.

Removal of the /findUsers* endpoints

The following 3 controllers will be removed in Jahia 8.2.0, as they can constitute a security vulnerability (see Security Patch - April, 2023), by exposing a list of users:

• /find
• /findUsersAndGroups
• /findUsersAndGroupsInAcl
   

Shiro classes won’t be exposed anymore

Jahia 8.2.0 will stop exposing Shiro classes, and will provide a new service instead. For instance, WebUtils.getAuthenticatedSubject(httpServletRequest) will be removed, and the following code:

Subject subject = WebUtils.getAuthenticatedSubject(httpServletRequest);
subject.hasRole(REQUIRED_ROLE) 

shall be replaced with something like:

WebUtils.hasRole(httpServletRequest, REQUIRED_ROLE);

 

Removal of the java.security.acl class

The java.security.acl class, which is not supported anymore by JDK 17, will be removed in Jahia 8.2.0.
Customers casting our JahiaGroup class into java.security.acl.Group, will need to refactor their code.
For instance, the following code:

java.security.acl.Group group = groupManagerService.getGroup('users')

Can already be rewritten using:

JahiaGroup group = groupManagerService.getGroup('users')

or

Principal group = groupManagerService.getGroup('users')

Removal of YUI Compressor

The library historically used at Jahia for asset minification, YUI Compressor will be removed in Jahia 8.2.0. Please note that this library is not maintained anymore and has been deprecated in Jahia 7.3.1.0 (Released in April 2019) as it is not compatible with JDK 11: thus assets could not be minified when running Jahia on this JDK version.  

We strongly suggest customers to move to more modern ways to aggregate and minify assets as documented in the Assets management knowledge base entry.

Removal of rome-1.0

This library will be removed as it was packaged, but not used, by Jahia.

Removal of Hibernate

Jahia currently exposes its Hibernate library. Starting with Jahia 8.2, Hibernate will no longer be exposed and using it directly won’t be possible. If you need connect to databases, we recommend that you use your own JDBC driver and SQL, or embed your own framework. In future versions of Jahia, we’ll either provide a library fully compatible with OSGi or document how to use your own. If this is an issue for you, you can absolutely reach out to our support team who is working very closely with our product team.

End of support for Portlets

Portlets have been deprecated with Jahia 8.0.0, but portlets could still be deployed and used in Jahia 8.0 and 8.1. With Jahia 8.2.0, we intend to actually remove the code related to portlets: portlets will not work anymore after the upgrade to Jahia 8.2.0.

End of support for PostgreSQL 9

Starting with Jahia 8.2.0, we will be discontinuing support for PostgreSQL 9, which has already reached its end of life. Additionally, PostgreSQL 11 will transition to Tier-2 support, while maintaining support for PostgreSQL 12. Furthermore, we’ll be adding PostgreSQL 13 to our list of supported versions. We are also actively exploring the possibility of adding PostgreSQL 14 and 15, although their inclusion is not yet confirmed.

End of support for Oracle 11 and 12

Starting with Jahia 8.2.0, we will be discontinuing support for Oracle 11 and 12, as these versions have already reached their end of life. We are maintaining the support for Oracle 19.

Removal of the old Augmented Search entry point

The following jcr searches entry point of Augmented Search Removal, deprecated since Augmented Search 3.0.0 and which has not been updated since, will be removed in a future release of Augmented Search:

jcr {
        searches(siteKey: $siteKey, language: $language, workspace: $workspace) {
            search(q: $q, searchIn: $searchIn, filter: $filter, sortBy: $sortBy, limit: $limit, offset: $offset) {
                totalHits
                hits {
                    excerpt
                    keywords
                    tags
                    created
                    createdBy
                    lastModified
                    lastPublished
                    path
                    mimeType
                    link
                    score
                    displayableName
                    excerpt
                    node {
                        name
                        uuid
                        property(name: "jcr:createdBy") {
                            value
                        }
                    }
                }
            }
        }
    }

Customers relying on this entry point shall already move to the new one, described in the Academy: Writing a query and fetching results

Development best practices

CKEditor toolbar configuration

As part of our ongoing commitment to ensuring a secure and tailored experience for our users, we would like to inform you about upcoming changes regarding the CKEditor toolbar default configuration. The CKEditor toolbar is typically customized on a per-template set basis; however, we have identified certain features that may pose security risks or may not be suitable for all users. In order to address these concerns, we recommend that you review and modify your CKEditor toolbar configuration accordingly. Additionally, we will be updating the default configuration by removing the features that pose risks and eliminating unnecessary features. We believe that these changes will contribute to a safer and more efficient user experience.

We highly recommend to already:

• Remove the “Source” button for editors who shall not be able to update the html of rich texts, as it can be used as an attack vector (for instance if an editor copy/paste html code from untrusted sources)
• Remove the “Preview” button inside CKEditor, as it is of no use in Jahia, and as it is vulnerable to XSS attacks

Therefore, starting with Jahia 8.2.0, we will make some adjustments regarding the configuration of CKEditor toolbars:

• By default, the editor and translator roles will use the “Basic” toolbar. This change will be done by updating the Wysiwyg editor toolbar permission for these roles (available in “Permissions on current site > User interface Wysiwy editor toolbar)
• The default configuration for the Full and Basic configurations will be updated:
  • Full: removal of the New page and Preview buttons
  • Basic: removal of the New page, Source and Preview buttons

Here is the configuration that will be used by default in Jahia 8.2.0:

CKEDITOR.editorConfig = function (config) {
    config.toolbar_Full = [
	    ['Source', '-', 'Templates'],
		['Cut', 'Copy', 'Paste', 'PasteText', 'PasteFromWord', '-', 'Undo', 'Redo'],
		['Find', 'Replace', '-', 'SelectAll'],
		'/',
		['Bold', 'Italic', 'Underline', 'Strike', 'Subscript', 'Superscript', 'RemoveFormat'],
        ['NumberedList', 'BulletedList', '-', 'Outdent', 'Indent', 'Blockquote', 'CreateDiv'],
		['JustifyLeft', 'JustifyCenter', 'JustifyRight', 'JustifyBlock'],
		['Link', 'Unlink', 'Anchor'],
		'/',
		['Image', 'Table', 'HorizontalRule', 'Smiley', 'SpecialChar'],
		'/',
		['Macros', 'Styles', 'Format', 'Font', 'FontSize', 'TextColor', 'BGColor'],
		['Maximize', 'ShowBlocks']
    ];

    config.toolbar_Basic = [
        ['Templates'],
		['Cut', 'Copy', 'Paste', 'PasteText', 'PasteFromWord', '-', 'Undo', 'Redo'],
		['Find', 'Replace', '-', 'SelectAll'],
		'/',
		['Bold', 'Italic', 'Underline', 'Strike', 'Subscript', 'Superscript', 'RemoveFormat'],
		['NumberedList', 'BulletedList'],
		['JustifyLeft', 'JustifyCenter', 'JustifyRight', 'JustifyBlock'],
		['Link', 'Unlink', 'Anchor'],
		['Image', 'Table', 'HorizontalRule', 'Smiley', 'SpecialChar'],
		'/',
		['Maximize', 'ShowBlocks']
    ];

    config.toolbar_Light = [
        ['Bold', 'Italic', 'Underline', 'Strike', 'RemoveFormat', '-', 'NumberedList', 'BulletedList']
    ];
} 

Please note that configurations set at template set or property level have priority over the default configuration. In other words, if you have defined custom configuration in your template sets, updating the default configuration will have no effect.

You can already apply these changes in your current version, without waiting for Jahia 8.2.0, either:

• In the CKEditor configuration specified in your template set, set in javascript/ckeditor_config.js
• In the configurations used for specific rich text properties,

  ​​​​​​​text (string, richtext[ckeditor.toolbar='Basic',ckeditor.customConfig='$context/modules/javascript/javascript/config.js'])

• And you can update the default configuration of your platform, used when no configuration is defined at template set or property level, by copy-pasting it in the CKEditor Custom Configuration tools entry (/modules/tools/ckeditorConfig.jsp )

Learn more about custom CKEditor toolbar configuration

XSS best practices

In the last couple of releases, we have introduced various fixes in order to make Jahia more robust against XSS attacks, mostly on the backoffice side, when rendering resource titles.

However, custom views may be vulnerable to XSS attacks, if certain precautions are not taken: Every text property editable by an editor shall be properly escaped in the component view. We cannot generalize this change on Jahia's side, as it could break many customer implementations with legitimate cases where content shall not be escaped.

For instance, in your jsp, you can use ${fn:escapeXml(contentProperty)} instead of just ${contentProperty} 

See XSS vulnerabilities

CKEditor 4 End of life

We are taking the opportunity of this 8.2.0 communication to inform you that CKEditor 4, our current rich text editor, has reached the end of its public and open-source maintenance on June 30th, 2023. The version integrated into Jahia has been slightly modified to better align with our features and interface. Please be assured that we will continue to provide solutions for any security issues that may arise until a suitable replacement is implemented.

Earlier this year, we conducted an evaluation of alternative editors and selected CKEditor 5 as the chosen replacement. However, we have made the decision to postpone the migration to a later date, after 2023. This will allow us to allocate resources to areas that will have a more significant impact on user experience and the modernization of Jahia. Rest assured, the migration to CKEditor 5 remains a priority for 2024.

For customers who are currently using CKEditor 4 in live contribution forms (provided through the  <uiComponents:ckeditor> tag in JSPs), we recommend exploring alternative text editors to ensure you have a publicly supported version. We encourage you to begin using CKEditor 5, available under a GPL license, as the default rich text editor for such live contribution forms. This will align with the future direction of Jahia.

As part of our commitment to transparency and collaboration, we have made our CKEditor 5 repository public. This repository allows for external contributions and provides visibility into the associated issues. You can access the repository and review the issues at https://github.com/orgs/Jahia/projects/7/views/1. If you are interested in contributing, please reach out to us through your support space on support.jahia.com.

We truly value your support and understand the importance of a seamless transition. If you have any questions or require assistance, our dedicated support team is here to help.