Please see below some frequently asked questions regarding migrating from CentOS 7 to Rocky/RHEL 9 operating system.

Is there a cost for this move?​

Jadu will undertake this server maintenance for all Jadu hosted customers with an active support agreement at no additional cost.

Why do we need to migrate away from CentOS 7?​

CentOS 7 has been set an official end of life date during 2024, after which time we can expect no security patches from the community maintaining this project.

What is Rocky 9? Will we notice any difference?​

Like CentOS 7, Rocky 9 is an open-source variant of the Red Hat family of operating systems. Being from the same family, the two are very similar in how they operate. There should be no noticeable difference when your site has been migrated over.

Why are you not moving to another version of CentOS?​

The CentOS project has, historically, been ‘downstream’ of Red Hat Enterprise Linux (RHEL). This means that any fixes are made available to CentOS after test and release in RHEL, usually within 24 hours.

CentOS 9 has moved to be ‘upstream’ of RHEL. In other words, it will receive fixes ahead of RHEL, more at the bleeding edge and therefore potentially less stable. Jadu does not consider this suitable for use in our PROD environments at this time.

We have selected Rocky as this maintains the stability of being ‘downstream’ of RHEL. It is seen as a spiritual successor to CentOS, having been created by the person originally responsible for CentOS.

When will our server(s) be moved?​

We will contact you over the coming weeks via Jadu Support with a plan for your specific infrastructure as part of a wider programme of work that Jadu is undertaking for all hosted customers.

Can you tell us what is involved in the process?​

We will implement the process on your UAT environment first to give you an opportunity to test and become familiar with the process before progressing to PROD.

At a high level, the plan for moving a server will be as follows:

• Jadu will prepare a new Rocky 9 server instance
• A content and end user registration freeze will be required (we recommend you putting up an announcement on the site for this)
• If you have Jadu Central Forms (XFP), forms and payments will need to be taken offline during this content freeze
• Jadu will synchronise data from the CentOS 7 server to the Rocky 9 server
• An infrastructure switch will redirect traffic to the new Rocky9 server
• The content freeze can be lifted and the CentOS 7 server decommissioned

Will there be any downtime during the move?​

Yes, when traffic is redirected in the latter stages of the switchover between servers, we expect a small (1-2 minute) period of downtime where Jadu are in control of your DNS already.

As noted in the above steps, depending on which modules you are actively using, there will be a period of content / end user registration freeze as well as online forms & payments being offline whilst migrating data over to the Rocky server before the servers are switched over.

We host with Jadu - do we need to do anything?​

We will contact you over the coming weeks via Jadu Support with a plan for your specific infrastructure and what steps your team will be required to undertake, but largely this will be around:

• Putting up advance notices for your end users and alerting staff of the plan
• Testing / familiarisation of the process with the UAT environment

We host ourselves - do we need to do anything?​

If you self-host on Windows Server, you are unaffected.

If you self-host on Linux, we’d recommend moving to a supported operating system. Jadu Central will be supported on RHEL 9 and Rocky 9, see more details on versions below. On both operating systems, we’ll still utilise MariaDB 10.5 (at the time of writing February 2024).

We’ll provide further guidance on the steps required to migrate data in due course should your internal team of systems administrators wish to undertake this process themselves. If you would prefer Jadu to manage this process under professional services, then please contact our Support team.

We’re currently running Jadu CMS x.x.x, do we need to upgrade first?​

This depends on the version of the Jadu software your server is currently running.

Rocky 9 supports a minimum MariaDB database version of 10.5. This was first supported in Jadu CMS 21 and XFP 8. Therefore, if your server is running CMS 21, XFP 8 or any version of Jadu Central, we will be able to move you to Rocky 9 as is.

If your server is running CMS 20, XFP 7 or anything prior to this, we will need to upgrade your software version before moving you to Rocky 9. This will be in line with the usual process for software upgrades and managed through the Jadu Support team.

We’re a Hyland Content Portal customer - what happens for us?​

Content Portal (CP) is a module on top of Jadu Central (formerly CMS & XFP). As such, any implementations hosted on CentOS 7 will need to be migrated. If you self-host, see ‘We host ourselves - do we need to do anything?’.

The corresponding minimum CP version that can move to Rocky 9 is 6.0.0. If your server is running a version prior to this, you’ll need to upgrade first. See ‘We’re currently running Jadu CMS x.x.x, do we need to upgrade first?’ for more details.

We have another Non-Live site hosted with you - will this move too?​

Yes, we’ll communicate separately about moving non-production environments such as DEV/TRAINING etc outside of the traditional UAT/PROD set in due course.

We have a Disaster Recovery service - what will happen with this?​

Previously, our DR solution involved having a second site that was always running, and we synced data to this nightly. This meant that it was possible to switch over to a version of the site that was no less than 24 hours out of date at any time.

A limitation of this solution was that, for customers using Jadu Central Forms (XFP), it was necessary for forms to be disabled whilst the site was running from the DR server. This is because the DR site maintains its own copy of the database, so form submissions made between the last sync and a disaster occurring would not be present on the DR site when failed over. Similarly, form submissions during the disaster would not be present when the was once again served from the Live server.

As part of the Rocky 9 migration, customers on the above DR solution will be moved to our improved DR solution. This uses AWS technology to sync data in real time to a disk in a secondary AWS region, which can then be used to launch an instance of the site should a regional disaster occur. Because of the real time sync, the DR site would be much more up to date - never more than a few minutes behind, as opposed to up to 24 hours. This means that it is possible to keep forms online whilst running from the DR site.

For customers already using the real time DR, we will simply ensure that the replication is switched to the Rocky server once this is in place.

We have a PLATINUM resilient infrastructure setup - what will the move involve for us?​

Resilient infrastructure behaves slightly differently - it utilises a central database that is accessed by a number of worker servers. We will communicate any tangible differences specific to your infrastructure when we reach out to you, but this will likely simply lessen the content freeze period required compared to GOLD infrastructure setups.

We have a VPN or special networking, will this be affected?​

Yes - the VPN will point to your CentOS 7 server. This will either need re-pointing to the replacement Rocky 9 server or a new VPN created for you to use.

We will communicate specifics relating to your VPN when we reach your server in the migration.

We use Jadu Connect - do we need to do anything special for this?​

No, Jadu Connect is Multi-tenant SaaS and any maintenance required will be handled by Jadu as part of regular scheduled maintenance as communicated through https://cxm.statuspage.io/.

Installing a cookie consent banner has become mandatory for websites in many regions due to evolving privacy laws. However, with so many options out there, it can be tough to select one that truly delivers an accessible user experience.

Many cookie banners unfortunately miss the mark when it comes to accessibility for those relying on assistive devices. But designing an inclusive site means considering how consent managers integrate with screen readers and other technology used by visitors.

After evaluating numerous solutions, we've had consistently good results using Free Cookie Consent from FreePrivacyPolicy.

However, to help achieve accessibility, we recommend selecting "Headline dialog" for your banner style. This should make the banner display at the top of the page statically (will scroll with page content and not positioned over other content).

When you select "Simple dialog", the banner will be displayed at the bottom right of the page, and overlaps other elements. This can result in WCAG 2.4.11 "Focus Not Obscured (minimum)" AA failures, when a user keyboard tabs through the page and focuses an element behind the cookie banner.

If you have already copied a snippet from the site, this can also be achieved by changing the notice_banner_type option in the code snippet from simple to headline.

Jadu has merged our Jadu CMS, Jadu XFP and Jadu Content Portal products into a single product, Jadu Central.

What is the name of the merged product?

The merged product will be referred to as Jadu Central, and will contain all functionality of Jadu CMS, Jadu XFP and Jadu Content Portal.

Why is the merge happening?

We are merging Jadu CMS and Jadu XFP, as the vast majority of our customers already have both of these products, and reconsidering our distribution methods will allow us to make patch and installation processes smoother and snag-free.

Jadu Content Portal is built upon the Jadu CMS and Jadu XFP platform. As a result, the merger will again make maintenance and future development of the product a smoother experience for customers and partners.

When is the merge going to take place?

Q4 2022 and it will be available via a patch release which we will plan with you.

What are the main user interface changes in Jadu Central?

• The text size has been increased in a number of places, especially buttons and labels, improving readability and clarity
• Interactive controls like form fields and buttons are physically larger, they're easier to see and their target areas are larger to meet current accessibility guidelines
• Links are more obvious and strongly defined, with higher contrast against regular text, and a consistent stronger underline
• Content landmark areas are now more clearly defined, visually, through the use of colour and contrast, but also defined with code using semantically appropriate section elements, the position of the main headings has also been changed to improve navigation with assistive technology and allow anyone who relies upon headings to navigate around a given page to be able to find what they're looking for
• Breadcrumbs have been tweaked to make them more useful, and those are now consistent across the software
• Homepage widgets can now be quick-searched, handy if you have a long list of custom widgets and you know you want to find the 'map' ones
• Some help text and labelling have been improved here and there, like when deleting a document, the option now clearly explains the scope of the action you're about to take instead of just 'delete'
• Modals are generally larger, given more space to breathe,
• The sign-in experiences — which differed between CXM compared to CMS and XFP have now been brought closer together visually, and you're still able to change the main colours in Jadu Connect to reflect your organisation's branding - they’ve also been prepared so that we can add additional authentication options such as SAML integration to the login screen
• We've been able to strip out a lot of older styles which catered for browsers which we no longer officially support, some components have been completely rewritten in the background to take advantage of newer design capabilities in CSS, we can do some things like more reliable responsive layouts with much less code these days, you might not see any visible differences, but fewer lines of code and fewer supported browsers makes it easier for us to test and release changes, which is a big win
• Textarea elements with character limits have a new accessible character counter, which also warns when you're getting close to the limit
• Date pickers have been replaced with a more accessible calendar
• Tooltips, which display additional information when you interact with an element, are now compatible with screen readers and other assistive technology, and also now work with touchscreen devices which don't have a 'hover' interaction.

Strategy​

Who will be the product manager for the merged products?

All products are managed in the same way by the product management team.

What will the roadmap for the combined products be?

The roadmaps for Jadu CMS and Jadu XFP will also be merged, to incorporate milestones from each. This includes previously communicated work such as the retirement of the old form builder.

Licenses, costs and pricing​

Will there be a change to GCloud listings?

Yes - Jadu Central will be listed initially with two components Content/Website( formerly CMS) and Forms (formerly XFP).

Which option do I need to choose on GCloud when it comes to renewal?

• If you currently have both Jadu CMS and Jadu XFP, Jadu Central
• If you currently only have Jadu CMS, Jadu Central Content only
• If you currently only have Jadu XFP, Jadu Central Forms only

Will there be a change to my support costs?

The merge of the products will not affect support costs if you have both Central Content and Central Forms. If you have just the Central Content, you can continue to pay support for this, however the Forms features set will be available in your Control Centre but not implemented.

If you wish to use Forms going forward there are two costs:

• Implementation of Forms Templates
• Annual support for the Forms product

Will my contract renewal cost change as a result of the merge?

The merge of the products will not affect current contract renewal prices for the support and software elements, however a small increase (between 1% and 3.5%) has been introduced in relation to the software subscription pricing to reflect rising hosting costs which we have had to pass on to our customers.

What impact will this have on my Jadu product perpetual licence?

This will have no impact on your Jadu product perpetual licences. Licences for Jadu CMS and Jadu XFP will continue to be honoured for Jadu Central.

Will my hosting change?

There will be no changes to your hosting environments.

Does this mean I will automatically get Forms included? What if I don’t want to use it as I have an existing forms product?

Jadu Central will be distributed with both Content and Forms components. Customers who do not currently have Jadu XFP will be able to access Jadu Central Forms management pages within the Control Center but will not be able to deploy forms.

If you wish to use Forms going forward there are two costs:

• Implementation of Forms Templates
• Annual support for the Forms product

No additional website template changes, or implementation professional services will be included in the roll out of Jadu Central. As a result, if your Jadu CMS website was implemented without Jadu XFP, your website will not be set up to be able to publish Jadu Central forms. Jadu can provide a quote for implementation and annual support if you decide to enable Central Forms.

Business continuity​

Will the same people who support the current products support and maintain the merged product?

Yes, the teams supporting Jadu Central will be the same teams who currently support Jadu CMS, Jadu XFP and Jadu Content Portal.

Will Jadu continue to support Jadu CMS, Jadu XFP and Jadu Content Portal as separate products?

Jadu CMS, Jadu XFP and Jadu Content Portal will be replaced by Jadu Central. You will no longer be able to purchase the products as separate entities.

All existing customers of Jadu CMS, Jadu XFP and Jadu Content Portal will see the branding of their system change to Jadu Central following the application of their next software patch.

Will my existing forms still be available?

Yes, there will be no changes to forms published using Jadu XFP.

Will my cases in CXM disappear?

The merge of Jadu CMS, Jadu XFP and Jadu Content Portal will have no effect on Jadu Connect, formerly Jadu CXM.

Training​

I paid for training in my support tier, will updated training be added or will I have to pay more?

Training videos will be updated to reflect the new branding, as will our user manuals. The underlying functionality of our products will not be affected by the merge, and there should be no need to retrain as a result.

Features and functionality​

Will I now be able to publish Jadu XFP forms on my website?

See above - this depends on your current support and licence arrangements.

Will there be any new features and functionality added?

New features and functionality will not be added as a direct result of the product merge. However we will continue to deliver our product roadmaps.

Will I be able to use the Perceptive ImageNow / Perceptive Content integration?

The Perceptive ImageNow / Perceptive Content integration is a premium integration, and a separate licence will be required to use this where not already implemented.

Will my existing integrations still be available?

All existing integrations will continue to be available, and will be unaffected by the merge.

Will I be able to use the Hyland OnBase integration?

The Hyland OnBase integration is a premium integration, and a separate licence will be required to use this where not already implemented.

Will Jadu XFP forms be available on Galaxies websites?

Jadu XFP forms will not be available on Galaxies websites as a result of the merge.

What changes will happen to my data if I previously used XForms standard?

Jadu XForms standard was retired due to the increased requirements of GDPR, and removed from Jadu CMS in version 20.0.0. Data from Jadu Xforms standard was removed at this point, and will not be affected by changes when the products are merged to form Jadu Central.

What will be the change to my Jadu CMS?

Existing customers of Jadu CMS will see the product name, user interface colour scheme, and associated imagery change.

What will change when I install Jadu Central compared to Jadu CMS, Jadu XFP, Jadu Content Portal?

When Jadu Central is installed, it is anticipated that this will be a one step process that will not require separate actions to enable Jadu XFP or Jadu Content Portal.

As a result we expect that customers and partners will have a much improved experience when installing our products.

Partner impact​

How will the change affect partners and resellers?

Partners and resellers will be expected to update their sales and promotion materials to reflect our new product brand, and reflect the change to a single product.

How will the change benefit partners?

Partners will benefit from a simpler patch and distribution process, which will be streamlined by the product merge.

Customer impact​

How will the change benefit customers?

Customers will benefit from a simpler patch and distribution process, which will be streamlined by the product merge.

Will releases still be as frequent?

There are no changes to the frequency of our release as a result of the product merge.

Jadu Connect Forms​

Does that mean XFP will be replaced by Connect Forms?

While Jadu Connect forms is in the early stages of development, we do not plan for Jadu Central forms (formerly Jadu XFP) to be replaced by Jadu Connect forms.

Jadu Central forms is an enterprise level, on premises form product with a focus on extensibility and deep integration with back office systems.

Jadu Connect forms will be a SaaS solution, aimed at creating lightweight forms to support case workflow and offline working.

Am I going to have to undertake a migration from XFP to Connect Forms? If so, will that be automated or manual?

We do not at this point anticipate customers migrating forms between the two products, as they are not envisioned to be like for like in their functionality.

Spell checking in Jadu CMS has historically used an application specific database table, which was difficult to maintain, and limited our ability to regionalise spellings for customers. The new spell checking technology is easier to maintain and install, and also has a far improved experience for US and Australian customers.

Who will receive the new spellchecker?​

New installs, existing customers can get it as well, but a system administrator may need to make changes to your environment to allow you to use the new spellchecker.

When will this change take place?​

The software changes required to support the new spell checker will occur in 21.0.0.

What is the new spellchecker technology?

Hunspell - http://hunspell.github.io/ - details of this project are available on GitHub - https://github.com/hunspell/hunspell

What are the benefits of the new technology?​

• Patchable dictionary
• Underlying technology is available free of additional charges
• Supports multiple languages
• Supports adding custom words to the dictionary
• Custom words can be made site specific
• Widely used by popular software projects such as Firefox

What are the associated costs?​

Hunspell itself carries no additional cost. If you are a current customer, a system administrator may need to make changes to your server environment to allow you to use the new spellchecker.

These professional service works may carry a cost.

Jadu CMS 20.1.1 fixes an issue introduced in Jadu CMS 20.0.0, where:

• when a directory record included a HTML field,
• if the HTML field was empty when the record was edited,
• and the HTML control wasn’t opened before saving the record,
• then the record would be saved with space characters associated with the HTML field.

As part of our fix for this issue, we wish to remove any broken data that may have been introduced to your database.

This will require us to run a database migration, Version20210601121027, that removes the space character records. This will affect records that match the “Data before” pattern in the following way:

Given the nature of this migration, we will not be able to detect places in your data where the space characters have been removed. In the case of the Jadu CMS 20.1.1 patch being rolled back, the space character data will not be reinserted into your database.

While we expect that there will be very limited data that matches this pattern, and that any data that matches this pattern will be as a result of the bug introduced in Jadu CMS 20.0.0, we want to make you aware of this action in advance of it being applied to your data.

From August 2021, Jadu CMS and Jadu XFP will support:

• PHP 7.4
• SQL Server 2019
• Windows Server 2019
• MariaDB 10.5

Support for older software versions, which no longer receive security updates, will be discontinued. As a result, Jadu CMS and Jadu XFP will deprecate support for:

• PHP 7.1
• SQL Server 2012 SP2
• Windows Server 2012 R2
• CentOS 6.x
• Redhat 6.x

Also, support for the mail transport protocol will be removed entirely in the next major CMS release (22.0.0), in favour of using SMTP.

Why the change?​

Software versions that no longer receive updates from their developers can be vulnerable to compromised security. We want to provide you with the highest level of security support, and therefore recommend you upgrade your system to utilise our updated platform.

What do I need to do?​

If you have any PHP code on your website that’s not provided by Jadu, you will need to ensure its compatibility prior to upgrading.

To upgrade, you don’t need to do anything if you’re hosted by Jadu Creative as you'll be upgraded as part of your platform management agreement; our team will be in touch in due course.

Otherwise:

• Ensure that you have upgraded to CMS 20.0.0+ and XFP 7.0.0+ before starting the upgrade process.
• Linux customers should ensure they upgrade to MariaDB 10.5 and PHP 7.4, and then apply CMS 21.0.0 and XFP 8.0.0 patches.
• Windows customers should upgrade to Windows Server 2019, SQL Server 2019 and PHP 7.4, and then apply CMS 21.0.0 and XFP 8.0.0 patches.
• Many customers already use SMTP to deliver emails from their Jadu CMS and XFP system. If you do not currently use SMTP, you should plan to move to SMTP in line with these updates.

## FAQs

PHP update​

Why do I have to upgrade the PHP version?​

PHP is the programming language used by Jadu products. Periodically new versions of PHP are released, which offer new features and other enhancements. Over time, support for older versions of PHP are dropped.

The version of PHP installed on the majority of our customers’ environments is PHP 7.2. As PHP 7.2 is no longer receiving security updates, we strongly recommend updating. Details on support for PHP versions is available on their website.

When can I upgrade to PHP 7.4?​

Support for PHP 7.4 has been released in CMS 21.0.0, and XFP 8.0.0. Self hosted customers will be able to start the PHP upgrade process from that point. Jadu hosted customers will be contacted when their system is due to be upgraded.

Can I run multiple versions of PHP concurrently?​

No, we require that only one version of PHP is run on your supported environments.

Who pays for the support for PHP 7.4 updates?​

Standardisation on SMTP​

Who does this affect?​

Customers using Windows will have been advised to use SMTP when their system was originally installed and we therefore do not expect them to be affected by this change, but please do your own due diligence.

Jadu hosted customers are not required to make any changes, Jadu will make these changes as part of our hosted service.

Self-hosted Linux platform customers will be required to make the required changes prior to Jadu CMS 22.0.0 being applied to their system.

What action is required?​

If you are currently sending email via mail transport in Jadu CMS or Jadu XFP, you will need to move to an SMTP service before Jadu CMS 22.0.0 or later updates are applied to your system.

Jadu CMS has included SMTP support for many years, and as such, you should be free to complete any required change prior to the patch.

Will there be any disruption to my service?​

There should be no disruption to your service. Jadu CMS has supported SMTP for some time, and so the required changes can be made any time before your patch with Jadu CMS 22.0.0.

We announced in 2018 that we would support the Classic Form Builder until at least the end of December 2020.

However, we understand that online forms are a key aspect of your service delivery, particularly at the moment. Therefore, we will continue to support the Classic Form Builder until the 1st January 2022, providing you with another year of extra time to upgrade and migrate your forms over to the Modern Form Builder.

Why make the move?​

• Forms are much easier to create, using the drag and drop functionality
• Create simple or complex in-page branching logic to guide your users to the right place
• The powerful rules engine enables you to automate actions, saving you time
• Comply to the WCAG 2.1. Accessibility Guidelines with accessibility built into the forms
• 70% of our customers are using the Modern Form Builder. We saw a big increase in the use of the Jadu Library during the pandemic in particular. Customers were able to adopt forms with a few clicks including Business Grant Forms, Volunteer Forms etc during the pandemic.
• New features are only released into the Modern Jadu XFP Form Builder, including our latest accessibility updates.

Beta testing provides you with an early insight into releases. It also enables you to have your say in helping shape the products you use. We do this by letting existing users trial new features/releases whilst feeding back to us any findings. This experience benefits both Jadu and you as the user, as you get the chance to tell us what you think the pros and cons of the latest updates are.

How are beta tests set up on our (customer) system?​

In order to take advantage of beta releases, you should have an existing environment available (or be able to set one up), this ensures there isn’t any business impact should any issues be found during the beta test period. We recommend that you use a DEV or Local environment where possible.

Can we preview the beta version of a release on a Jadu server first?​

In relation to the XFP 7.0 beta, when it is available we will update one of our Sandbox environments for those customers without an internal DEV environment to be able to see the changes that have been made to the software’s user interface. You will only be able to access the Control Centre, however, and it will not give you the relevant file system access that would be required to test any of your own customisations / local developments that you might have on your own environments.

One of the main advantages of beta testing beta in advance of the full release is to test the compatibility of any of your own bespoke developments with the updated frameworks that are included within this release.

If a beta release is deployed to our UAT or live server, are we able to roll back, for example if there are bugs and issues?​

The beta test would not be deployed to your live server. Only a final release should go into production (live to site) once these are made available. As mentioned before, we recommend that a non-critical DEV or Local environment is used to test the beta release.

As part of the beta test, as with any patch, you'll be able to do this via the Deployer user interface should you be using your own environment for conducting the beta testing on.

Is there anything else we need to be aware of to help us decide whether beta testing is for us?​

If you don’t have access to Deployer, we will need to grant you access to be able to apply the beta test by our team. Only members of staff with Jadu Support accounts can currently be set up to access Deployer.

Deployer use is currently limited to LAMP (Linux Apache MySQL PHP) architecture customers, and if you host yourselves internally then the server must be able to connect to the Deployer API directly (i.e. without going through a proxy). Note: All Jadu hosted customers would be LAMP and not utilise a proxy.

Once you opt-in, you will need an initial patch to the relevant environment to meet the minimum version for Deployer support so that the beta release can then be deployed to your environment. There are a few steps that our team will need to assist with on your client repository setup to make this happen, but all straightforward and quick activities.

From Jadu CMS version 20.0.0, we’re retiring the Content Pack feature. Unfortunately, this functionality is no longer compatible with how we deploy changes to our software as we strive to improve quality in our releases.

In the following FAQs, we answer some important questions. If you need any further information, please don’t hesitate to contact us.

## I’m not sure if I use Content Packs, what are they?

A site deployed using the Jadu Galaxies Module can be saved as a Content Pack. When saved, this creates a dataset containing the site navigation structure and / or content that can then be imported into another Galaxies site when it is created.

Why is Jadu retiring Content Packs?​

The content packs feature was created prior to the introduction of continuous releases within our platform. Occasionally, our releases include database changes to support new features or fix bugs. These database changes are made by database migrations that change the schema, or data, for each site on the system.

Unfortunately, the changes made by database migrations aren’t compatible with sites that have been saved as Content Packs and when a site is made using a Content Pack (point in time representations of the database schema), features can be broken or work unexpectedly, and patches to your environments can fail as a result.

There’s no easy way to prevent this from happening using the current Content Pack technology, so we’re retiring the current implementation.

When will the retirement of Content Packs take place?​

The changes will be made when Jadu CMS 20.0.0 or later is applied to your system. The changes will apply to both Photon and Classic Jadu CMS implementations.

How will my Galaxies sites be affected by this change?​

You will experience no changes to your existing live Galaxies sites - all content on the current site will remain available. In future, when creating a new Galaxies site, the Con- tent Pack feature will no longer be available and you won’t be able to select a Content Pack to use when creating a new site. All other features will be unaffected.

What will happen to my Content Pack data?​

Any content packs that you have previously created will remain on your system untouched. Your data will not be deleted when Jadu CMS 20.0.0 or later is applied to your system.

Will a replacement for Content Packs be available?​

We are currently focused on addressing changes required for security and regulatory compliance across our platform. Therefore, due to high priorities, a date hasn’t been confirmed for a Content Pack replacement.

If you have any feedback regarding using this feature, concerns of its retirement or have ideas around how you could use a fea- ture similar to this moving forward, please get in touch.

As of version 80, Google Chrome has changed how it handles cookies without a SameSite flag in the cookie header. Previously the behaviour was to allow cookies on all domains when SameSite was not set. The new behaviour is to only process the cookie when SameSite=None and the Secure flag is set.

This will cause an issue anywhere a session (or other) cookie is loaded in a browser window where the domain in the address bar does not match the source of the cookie. The main example of this within the Jadu platform is where an XFP form is embedded onto another website. The form relies on the session cookie, but this originates from the domain of the embedded form (e.g. mainxfpsite.com) and not the site the form is being displayed on (e.g. galaxysite.com). XFP detects this and displays a “technical error” message.

Further information is available in the Chromium blog

Instructions for rollout on Linux systems​

1. Create a new file in <install_path>/config/apache/custom.d/same-site-cookie.conf (path may differ depending on installation location - e.g. /etc/httpd/conf/)

2. Content of the file should be:

<ifmodule mod_headers.c>
    Header always edit Set-Cookie ^(.*)$ "$1; HttpOnly;SameSite=None; Secure"
</ifmodule>

3. Restart apache

This will change the main site to always set the SameSite=None and Secure flags on all cookies.

The change cannot reliably be applied only to XFP embedded forms as:

1. In Photon implementations, all requests are handled by the same app.php file and so the embedded forms URL cannot be distinguished at the Apache level
2. The cookie may be initially set on another page - we would need to confirm the behaviour of the browser if a page then attempts to set a different SameSite value on an existing cookie

Instruction for rollout on Windows systems​

1. Edit the public_html/Web.config to include:

        <rewrite>
            <outboundRules>
                <rule name="Add Samesite cookies" >
                    <match serverVariable="RESPONSE_Set-Cookie" pattern="^(.*)(PHPSESSID)(=.*)$" />
                    <action type="Rewrite" value="{R:0}; SameSite=None" />
                </rule>
            </outboundRules>
        </rewrite>

2. Restart IIS

This will change the main site to always set the SameSite=None. This will not affect the cookies set by Galaxies sites.

FAQs​

FAQ: I’ve refreshed the page, but I’m still experiencing the problem :(​

If you visited the page before the change was applied, you may already have a session cookie set. You will need to clear this cookie before the change will take effect. Instructions on how to do this for Google Chrome are available here - https://www.allaboutcookies.org/manage-cookies/google-chrome.html. Other browsers will require cookies are managed using their respective settings pages.

FAQ: “Use my current location” does not work on a with Google Map control of an embedded form​

Enabling 'Force_Secure' in constants should resolve this.

FAQ: I can see an error in my console:​

A cookie associated with a cross-site resource at http://www.google.com/ was set without the SameSite attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with SameSite=None and Secure. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

This message relates to Google functionality, not Jadu XFP or CMS.