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.

As announced at the Jadu Academy in Birmingham, there are a few changes that we’ll be introducing throughout the course of 2019, as part of our ongoing commitment to our supported customers in keeping your Jadu software current, compliant and secure.

The Critical Need To's​

1. Adhere with changes required by WCAG 2.1
2. Drop support for legacy IE browser versions
3. Use a newer Symfony PHP framework version
4. Move to CentOS 7 (for managed & self-managed Linux customers)

Some of these will require you to ensure that any custom developments that you or your teams may have developed can remain operational following these changes coming into effect.

Adherence with WCAG 2.1 & Control Center UX​

It’s a busy time in the CMS and XFP teams. The introduction of EN 301 549 ‘Accessibility requirements for ICT products and services’ brings with it a requirement to comply with Web Content Accessibility Guidelines (WCAG) 2.1 AA.

We’re taking this as a timely opportunity to reassess all our user interfaces to ensure that they are modern, consistent and compliant.

The final list of changes has yet to be finalised but it will include some degree of change to our interface CSS and mark up.

If you have created any custom Control Centre interfaces you should plan to review these for alignment with the WCAG 2.1 principles and also compatibility with our updated interface library.

Dropping support for legacy IE browser versions​

Microsoft dropped support for their browser, Internet Explorer (IE), versions 8, 9 and 10 some time ago. We’ve allowed a long grace period for our customers to follow this lead, however, the time has now come to officially withdraw support these browser versions. This will allow us to upgrade key javascript libraries (e.g. jQuery from version 1.12.4 to 3.x while also removing the previously utilised scriptaculous/prototype libraries) within our user interface framework to ensure that we maintain a secure and modern user interface for you.

Any custom Control Centre interfaces that may have been added to your systems therefore will need to be checked for any incompatible usage with the updated library.

Moving to a later Symfony PHP framework version​

The PHP framework Symfony is used by Jadu software, however, the community that manage this project have announced an end of life date for security fixes on the version we utilise (2.8) to be November 2019. We are currently in the process of moving over to support Symfony version 3.4 in the software, which will keep us using a supported version from the community until November 2021 or whenever we decide to move to a later version iteration, whichever comes first!

Any custom developments that have been built by your team to utilise Symfony directly will therefore need to be checked for any incompatible usage with the switch to version 3.4.

Moving to CentOS 7​

We’ve held off implementing PHP 7.x specific features until now. However, with the advent of XFP version 6.x and above, we need to utilise features that only PHP 7.x provides.

Support for PHP 7.1 and PHP 7.2 was added during June 2018. The PHP community has announced an End of Life date for PHP 7.1 of December 2019. We recommend customers move to PHP 7.2 ahead of the end of life date to ensure that you are able to receive security updates beyond then.

For Linux hosted customers, PHP 7.2 does require you to be running on the CentOS 7 operating system, where previously we have supported implementations on CentOS 6.

We’ll provide further guidance on each of these important changes in coming months, so do please lookout for these.

XForms Standard will no longer be available from August 2019.

We’re retiring the basic Jadu XForms Standard (Jadu XFS) module that longer standing customers may still find available within their Jadu CMS environment.

The module will be removed from all of our customers systems as part of a regular Continuum patch that will be released during August 2019 onwards.

We will communicate to you again within which release this is confirmed to be happening.

What is XForms Standard?​

XForms Standard is a very basic tool for building out simple web forms that doesn’t have the capabilities and security support that is provided by the XForms Pro module. XForms Standard was installed with the Jadu CMS alongside for example, the ‘Publishing’ and ‘Utilities’ modules for anyone without XForms Pro up until recently.

XForms Pro is the software that the majority of our customers are now using due to it being a fully functional forms management system, especially with the introduction of our now re-imagined ‘Form Builder’.

Why do customers use Jadu XFP?​

There are a number of reasons that customers would look to use Jadu XFP, such as:

• GDPR compliance
• Branching rules
• Extensible form components
• Payments integrations (through PayBridge adapters)
• Data Integration capabilities (such as File Output & Connectors)
• PDF output of form submissions

Our latest release Jadu XFP includes our re-imagined 'Form Builder' which also includes:

• Easy and simple to use drag-drop form designer
• In-page branching
• Powerful rules engine
• Shared form pages
• Page versioning with approval and rollback
• Page sections and repeatable questions

Why are we retiring XForms Standard?​

Longer standing customers will have had one of these two forms modules from Jadu installed, with Jadu XFP / XForms Professional increasingly becoming the de facto solution.

We found that the majority of our customers who still had the basic CMS forms module available to them did not make use of it due to its basic nature, using alternative forms packages instead.

Some of the issues with the standard CMS XForms Standard module that have lead to its de-support and now removal include:

• Insecure storage of personal data (non-compliant with GDPR)
• Data is retained indefinitely with no automatic data retention / removal capabilities
• Minimal Role Based Access Controls

What happens when XForms Standard is retired?​

We will put out a release of the CMS (number to be defined and communicated closer to the time) which once patched onto your system will take the following course of action:

The XForms Standard module will be removed from the Jadu CMS Control Centre for all of your Administrators. From this point, you will not have any access to previous form submission or form definitions from this point on therefore. Previously submitted form data will be removed from the systems database if you haven’t upgraded XFS to XFP. Existing front end form URL’s will no longer be available for citizens or staff (a 404 will be thrown)

What’s next if you use XForms Standard?​

If you don’t currently use XForms Professional, then we would recommend that you speak to your Account Manager to find out more details about the retirement and the option of upgrading to Jadu XFP in advance of August 2019.

We’re making the power of PHP 7.1+ available to all of our customers.

From December 2018, PHP versions 5.6 and 7.0 will no longer receive security updates from the PHP Group. We want to ensure that you always receive the highest level of security support, therefore PHP 7.1+ or higher will need to be installed on servers running the Jadu software by this time.

From July 2018, Jadu Continuum will support PHP 7.1, so you have plenty of time to install it if you host your website yourself or use a third party hosting provider. We’ll support you to ensure the needed actions are applied before the end of December so you’re able to receive patches for security issues.

The following actions will need to be taken:​

(note: these differ depending on the server you’re currently using)

• Customers hosted by Spacecraft will be upgraded as part of your platform management agreement. You don’t need to do anything and the team will be in touch.
• Linux customers on Centos 6 should upgrade to PHP 7.1.
• Windows customers on Windows Server 2012 should upgrade to PHP 7.2.
• If you have any PHP code on your website not provided by Jadu or Spacecraft, you will need to ensure it is PHP 7.1/7.2 compatible prior to upgrading.

Some of the benefits of upgrading include:​

• A more modern and secure option for your hosting environment
• Longer term, ongoing security support
• Faster performance
• Estimated more than 30% memory consumption improvement
• Better concurrency - up to 3x as many requests can be served per second

You will also need to ensure that you have patched your Continuum software with the compatible release. You can do this by raising a support ticket, or downloading the relevant patch from the support portal.

When you’re ready to go, either follow our easy upgrade instructions (coming soon) if you self-host, or reach out to Support.

If you have any questions in the meantime see our FAQs below, or get in touch.

FAQs​

Q1. Why do we have to upgrade PHP version?

PHP is the programming language used by Jadu Continuum products. Periodically new versions of PHP are released that 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 5.6. PHP 5.6 is approaching the end of its life, and security support for this version will end 31st December 2018.

In line with our security policy and the tenets set out by GDPR, we are upgrading our software to support a version of PHP that will receive longer term security updates, PHP 7.1 and PHP 7.2.

Q2. When can I upgrade to a PHP 7.1 or PHP 7.2 environment?

Support for PHP 7.1 and PHP 7.2 is due to be release by the Continuum CMS team on Friday 8th June 2018. Support for PHP 7.1 and PHP 7.2 is due to be released by the Continuum XFP team on Friday 29th June 2018.

Customers will be able to commence the PHP upgrade process after the relevant point dependant on the Jadu software that you are running.

Q3. Who pays for the support for PHP 7.1 & PHP 7.2 updates?

Q4. What are the benefits of PHP 7.1 and PHP 7.2?

PHP 7 is much speedier than PHP 5.
Upgrading to PHP 7 is estimated to bring about a >30% improvement in memory consumption
More concurrent users can be served, up to 3 times as many requests per second
Long term support and lower technical debt with ongoing support of bug fixes, security patches and maintenance updates.

Q5. Can I run multiple versions of PHP concurrently?

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

Q6. Where can I find PHP 7.1 and PHP 7.2 documentation?

• Please remember that customer code written by you or a third-party is outside of your Spacecraft support agreement.
• We do not provide technical services to help customers become compatible with PHP 7.1 and PHP 7.2.
• Check that any code you manage is PHP 7.2 compatible, you can use the open source PHPCompatibility library to help identify any issues.
• Raise a Spacecraft support ticket to initiate the PHP 7.2 compatibility check of any code Spacecraft manage.
• If you are self hosted, download the upgrade documentation and instructions (coming soon) to initiate your PHP 7.2 upgrade process.
• If you are Spacecraft hosted, or use code that Spacecraft manage, reach out to support to initiate the PHP 7.2 upgrade process.

Release​

How can I get the new form builder?

The new form builder was released in Continuum XFP #75 on the 13th March 2018 as part of the fortnightly release package issued by the XFP team. In order to use the new form builder you will need to request a patch of your site via Jadu Support for this version or above on or after 13th March 2018.

If Jadu/Creative deploy patches for you, the patch will be scheduled in with the deployment team via the usual deployment process. If you patch yourself, a package will be provided to you.

Once Continuum XFP #75 or above has been deployed to your site, Jadu will need to update your sites configuration to enable the new form builder before it becomes available to use (is disabled for existing customers by default).

When can I get it from / what release number?

The new form builder was released in Continuum XFP #75 (semantic version 4.0.0).

What are the system requirements for the new form builder?

There are no new system requirements introduced for the new form builder, your existing infrastructure and configurations (assuming that you have XFP already installed) should be sufficient. Some installations of PHP do not have the FileInfo module installed, you can check if you have this module installed or not by logging into your control centre and changing the url to jadu/maintenance/phpinfo.php and searching for FileInfo. If you do not have this PHP module installed you will need to install it.

We do however recommend that you install OPcache if it’s not already installed.

I have the latest patch but I can’t see the new form builder, why not?

The new form builder is not enabled by default, Jadu will need to enable the new form builder in your site configuration before it is accessible. This is to allow a phased approach for roll out across all of Jadu’s XFP customers. If you would like to have the new form builder enabled please let us know via Jadu Support where we will advise on the steps required to enable the new form builder for you and any costs associated.

Will I / Creative need to implement new templates for me?

You won’t need a full re-implementation of templates, but the new form builder templates will need to be developed and implemented which can be done through our professional services team.

Will forms built in the new form builder look the same as they do now?

Forms built in the new form builder will use Jadu’s Photon templating engine, so they will look broadly similar, but you can expect some minor differences, as all implementations have historically been handcrafted, so it’s important that you test your implementation once updated to check that you understand how things now display and behave.

Can we implement it just in UAT first to have a play / test / train?

Yes absolutely, the new form builder is disabled by default and can be turned on in UAT and remain off in production until you are ready to use it on your production site.

Can I implement the new form builder upon our local environment myself?

Yes, if you would like to do this then just get in contact with us and we can discuss how you would go about doing this.

Are there different templates for each of the form builder interfaces?

Yes, the legacy form templates have not been changed for the new form builder. The new form builder uses the Jadu Photon templating engine to render the form user interface.

Training​

Will you be providing training?

Jadu recommend face to face training to go over the new features in form builder, this can be arranged at £1000 per day plus VAT and expenses (maximum 8 delegates per day).

The user manual has also been updated and is available online at https://www.jadu.net/support/manuals/xfp/ and provides a good source of information on the new form builder.

What supporting materials will be provided?

The user manual has been updated and covers all of the new features. We’ll also be providing training videos that cover all the functionality of the new form builder.

Will the way we approach custom developments internally need to change?

Yes, we’ve tried to make developing custom form components and actions easier for developers. There is now a new framework for plugging into the new form builder. The rules engine and components are no longer based within the database, giving you more flexibility and making these easily shareable.

Developer documentation is available on request.

Are there new developer extensions that I can do in the new that I couldn’t do in the old?

Yes, it’s now possible to build your own form components. In the legacy form builder, developers could build custom Integrated Components but the markup generated by these components wasn’t customisable and relied on the from builder to join the elements together. Now in the new form builder, developers can design their own components controlling all aspects of the component down to the HTML markup that is used to display the component.

It’s also now possible to add your own form variables to the standard set as a new extension capability.

Existing customers​

Is there any cost for the new form builder?

There is no cost for the new form builder, as part of Continuum XFP you will get the new form builder when you update your site to our latest release version as part of your existing support contract.

There will be a professional services cost to provide additional styling specific to your templates for the new form elements that do not exist in the legacy form builder.

There may also be a separate cost in changing any existing custom developments that you may have to be suitable for the new form builder. The cost for updating the custom developments will need to be quoted on a case by case basis.

Can I opt out of the new form builder?

No it is not possible to opt out of the new form builder.

Jadu will only be supporting the legacy form builder until at least the end of 2020. No new features, apart from those required for GDPR compliance, will be developed for the legacy form builder and only security issues will be fixed in the legacy form builder after March 2018.

We hope that you will want to use the new form builder, if you have any concerns please speak to us about those.

When do I have to migrate my old forms by?

The legacy form builder will remain supported within XFP until at least the 31st December 2020. You should have all your forms that are in the legacy form builder migrated into the new form builder before that date.

Jadu have updated the reporting tools in XFP to provide a report for how many forms you have and in which version of the form builder they exists so as to help you plan the migration of your forms.

Will the old ‘Classic’ forms continue to function?

Existing forms will continue to function until XFP 11.0.0 is released and patched to your environment. XFP 11.0.0 is expected Spring 2022 will be the version from which the classic form builder and classic forms will be removed from the product. Until we ship XFP 11.0.0, we will continue to review and consider issues raised concerning the classic form builder through the interim period, on a case-by-case basis. We are likely to limit the resolution of issues to P1 and P2 issues

What help will Jadu provide to migrate my old forms?

Jadu will not be providing a migration tool to assist in migration of forms.

Due to the differences between legacy forms and new forms to perform a complete like for like migration. For example the Table component in the legacy form builder has been replaced by the Matrix page element and repeatable question types in the new form builder and you may wish to review how these differ in your own form designs.

Jadu will be on hand to offer advice for migrating your forms and using the new features to streamline your existing forms.

Can I use my old forms and new forms simultaneously?

Yes, the new form builder is installed alongside the legacy form builder and uses a separate code base and front end scripts. Your old forms will continue to function as they have before the new form builder release.

I have existing custom developments will they still work?

The nature of the custom developments mean it’s hard to be certain but we’ve tried to keep as much backward compatibility as possible.

• Integrated Components: All custom Integrated components will be available in the new form builder under the ‘Integrated’ page element.
• Form actions: Form actions will need to be updated to support the new form builder template and rules engine. Advice for developers will be provided for updating custom actions to support the new form builder.
• Predefined calculations: Custom predefined calculations will be available under the Logic tab within the new forms builder.
• Front end scripts: Any front end changes that you have applied will not be compatible with the new form builder. The new form builder uses Photon templating, to re-apply any front end script changes you will need to extend the templates.

Advice on how to do that can be provided on request.

How long will you support the old form builder for?

The legacy form builder will remain usable within core XFP until at least 31st December 2020, after which it will be removed from the core product.

From April 2018 no new features, apart from those required for GDPR compliance, will be developed for the legacy form builder and only security issues will be fixed.

I have outstanding support tickets relating to the old form builder, will they be fixed?

We do not anticipate resolving any further issues apart from those that relate to the security or integrity of your data. If your issue is a security issue then this will be prioritised and fixed as per any other security issue. No new features (apart from those required for GDPR compliance) will be developed for the legacy form builder after March 2018.

If your issue is not reproducible in the new form builder, then you should consider taking this opportunity to revisit your form within the new form builder instead.

I have PayBridge, will my payments work with new forms?

Yes payments are supported in the new form builder and can be used on both legacy and new forms.

Will my form URLs need to change in the new form builder?

Legacy forms will continue to be served from /forms/form/{id}/{lang}/{title} urls.

Forms built in the new form builder will be served from /xfp/form/{id} urls.

I have made changes to my front end scripts, how do I re-apply these changes?

Any front end changes that you have made will not be compatible with the new form builder. The new form builder uses Photon templating, to re-apply any front end script changes you will need to extend the templates. Advice on how to do that can be provided on request.

I have custom developments in progress, do I need to pay for these to be changed to the new form builder?

Possibly, we would advise you to check your quote to see if allowance for the new form builder version has specified. If your quote specifically states the form builder version that the integration will be developed for there maybe an additional cost to update the integration to support the new form builder.

What will happen once I build new forms, then turn off the new form builder? Will my new forms disappear?

No the form definitions will remain in the database until the new form builder is turned back on.

When I migrate old forms to the new forms builder, what will happen to existing submitted form data?

The submitted form data will remain accessible via the legacy form builder until data retention policies remove the data. Tools such as Data Export can continue to be used to export the data as required.

Features​

I used to use this feature, why isn’t it in the new form builder?

Some features have been retired in the new form builder, in the majority of cases there is now a better, easier way to perform the same function. For example you’ll notice that there is no longer a Table component. This has been replaced by two page elements; a matrix page element that displays a structured table and repeatable questions, that provide a more mobile friendly way of populating tabular data.

The new form builder does not include the password component or PHP calculations. These have been retired for security reasons.

If you used to use a feature that you can’t find anymore or just not sure if an alternative exists within the new form builder, then please do get in touch with us to discuss.

When is feature X coming to the new form builder?

If the feature was part of the legacy form builder, for example embedded forms, these features will be added to the new form builder over the coming releases and well before the legacy form builder is removed at the end of 2020.

To see what we have coming up and what features we are working on, take a look at the XFP roadmap. If the feature isn’t there yet, raise a feature request so that we can consider it.

What are the benefits of the new form builder?

Have a look at the form builder feature comparison matrix that we’ve put together.

What can I do now that I couldn’t do before?

Have a look at the form builder feature comparison matrix that we’ve put together for you.

Is there a feature comparison matrix so I can see what features differ between the form builders?

Yes, it can be viewed here.

There used to be workflow on received forms, where has that gone?

Received form data workflow has not been added into the new form builder. We found that many customers did not use the workflow in received forms and would often request that forms be marked as ‘Completed - Approved’ immediately on submission. The decision was made to not add this in to the new version therefore. If you have received data workflow needs then we suggest that you look at the Jadu CXM service that allows you to build and manage cases through a fully configurable workflow.

I currently have integrations configured, will these still work with the new form builder?

All core integrations via the IntegrationsHub such as Bartec Collective, Office 365, SinglePoint address lookup etc… are enabled in the new form builder and you do not need to make changes to the current integration.

Some form actions (Perceptive content and AssureSign electronic signature) have not been enabled in the new form builder just yet, but when they are, there will not be a need to update the integration settings.

Are the forms still accessible?

Yes forms are still accessible.

Do the features of the new form builder help me to be GDPR compliant?

Not initially, GDPR features will however be introduced during April 2018.

Are the forms still mobile responsive designed?

Yes they are.

Can I use images in my form for choice options (e.g. recycling boxes/coloured bins)?

No we don’t have a page element for that at the moment, this feature is on the XFP roadmap and will be added in a future XFP release.

Page elements are now much easier to develop and this could be achieved via a custom development if you so wished.

Can I now create multiple pdfs from a form now?

Yes, this is now possible in the new form builder.

If I change a page template does it now update all forms where that template has been used?

Yes. Pages can now be used on one or more forms, if you edit a page that is shared with more than one form you (or a higher level administrator) will be asked to approve the changes before they are reflected on the forms that use that page.

And of course if you later decide to revert the change, you can rollback to the previous version of that page.

Misc​

Are the forms available in the Jadu Library compatible with the new form builder?

Some forms on the library will not be compatible with the new form builder, but they can still be downloaded and imported into the legacy form builder.

Forms compatible with the new form builder will end in a .zip extension whereas forms compatible with the legacy form builder will end with .tar extension. XFP’s import page will detect the type of file and use the appropriate import routine to import the form.

What security testing have you done?

Jadu uses Checkmarx to perform static code analysis of the Continuum code base, configured for OWASP Top 10 vulnerabilities. Code analysis takes place before every release and issues discovered are resolved before the release goes ahead.

Do you need Photon for the new front-end templates?

No, although forms built with the new form builder will use Photon behind the scenes to render the front end view, you do not need a Photon implementation to use the new forms.

The General Data Protection Regulation (GDPR) has applied in the UK from 25th May 2018. Here's some important information to help you understand what we're working on in order to be GDPR compliant as well as some tips and checklists.

What is GDPR?​

The General Data Protection Regulation (GDPR) is an important piece of legislation that has applied in the UK from the 25th May 2018. The government has confirmed that the UK’s decision to leave the EU will not affect the commencement of the GDPR. The GDPR is in place to strengthen and unify data protection laws for individuals within the European Union and it's important that both we and you comply. See our reading list for more information.

Jadu Continuum Product Updates​

In preparation of meeting the requirements of GDPR, Jadu are undertaking work in our CXM, XFP and CMS products. We are working in partnership with a number of our existing customers to define the related features or enhancements required to provide GDPR compliance.

As of 31st December 2016, Jadu will no longer be testing our products and their regular Continuum releases against PHP version 5.3 in favour of a PHP 5.6 baseline testing regime.

So what version of PHP is now supported?​

PHP 5.6 has been tested and supported by Jadu since April 2015.

Will Jadu software still work with PHP 5.3?​

Jadu initially deprecated PHP 5.3 in CMS release #26. We have consciously not yet started to develop with features of the PHP language that only exist within later versions because we want to give our customers enough time to plan and implement any necessary changes whilst we strive to continue to ship new features and fixes regularly. We cannot however continue to test against and therefore officially support PHP 5.3 based implementations from 31st December 2016 onwards.

Why have we done this / what are the benefits that we (the customer) will realise?​

A whole host of reasons really, those of particular note include...

• Security; more secure with the removal of register globals settings etc.
• Performance; internal language optimizations as well as vastly reduced memory usage.
• PHP community support; PHP 5.3 is no longer maintained - this therefore impacts such as your PSN compliance returns for example.
• 3rd party library support; Releases Jadu, our partners and customers from older versions of libraries that have/become inactive maintainance wise (we'll be changing our compatibility requirement in composer, which will no longer enforce 3rd party compatibility with PHP 5.3).
• PHP enhancements; New and more consistent PHP language features for your developers to utilise.
• Operating architecture support; support for more modern underlying OS’s & architectures such as 64-bit support.

How long will PHP 5.6 be supported for?​

PHP 5.3 security support ended mid-2014, so it’s imperative that we progress anyone still running PHP 5.3 forwards to a maintained version.

The PHP community have announced that the current scheduled end of security fixes for PHP 5.6 will be around 31st Dec 2018. Before this time comes, Jadu will have moved our products forwards to support PHP version 7.x (or later) within our software. We expect to be able to begin to support PHP version 7.x implementations early 2017.

What is the level of effort and what is involved in this process?​

This will depend on a number of factors including:

• How many environments you have that will require the PHP version upgrading on
• Who hosts / manages these environments on a day-to-day basis for you
• Scale of any custom developments / modules that you might have and whether these are supported by Jadu or developed internally within your organisation. Any internally developed solutions should be checked / tested / changed to work under PHP 5.6 accordingly.

How do I find out if this impacts me?​

We have analysed the current customer base (both those in active projects and those already live) and will be raising a support ticket in your account if we have determined that action is required in your specific case. This ticket will give you more details about planned next steps. If you have not received a support ticket and wish to discuss this with us, then please contact the support team.

We have a support contract with Jadu/Spacecraft, what does this cover in relation to this upgrade?​

We will assist in this effort for customers with an active support agreement for the supported environment and for those environments that we host & manage for you. The upgrade of any supplemental environments not covered by an active support agreement or hosted by us, will need to be managed by the relevant team / organisation that manages these on your behalf.

We host with Jadu/Spacecraft, what does this mean for me?​

We will be undertaking a programme of work to move any customers that require any effort between now and 31st December 2016. After the initial support ticket is raised, we will continue to communicate with relevant personnel within your organisation ahead of time regarding any planned maintenance work to move you towards a supportable environment.

We host internally or with a 3rd party provider, what will we need to do?​

If you host your own Jadu software internally or via a 3rd party hosting provider, then upgrades of these environments will need to be planned by the relevant team / organisation. We can supply guidance as to the steps we will be undertaking for environments that we manage, but these may need to be adjusted / adapted for anything specific to your own specific hosting arrangements.

## We have custom written code that we’ve added ourselves, what can we do to check it will work?

You will only need to check PHP code that you have authored or changed and not the core Jadu software. This might include for example:

• Custom widgets that you’ve uploaded
• Frontend website templates added or changed
• Custom snippets that you’ve added
• Custom actions / connectors / extensions to extensible modules such as XFP
• Custom Control Centre modules / module pages that you’ve added

When beginning the process of checking any of your customised code for PHP 5.6 support, we utilised open source tools such as PHP Code sniffer and PHPCompatibility that can be used to scan a codebase and report upon the use of features of the language that may no longer exist within the 5.6 version of the PHP language for instance. Various tutorials exist for developers to follow along with when using tools such as this, a couple of examples of which are provided below:

http://enzolutions.com/articles/2015/06/07/how-to-check-php-compatibility/
https://blog.nerdery.com/2013/11/code-compatible-php-5-4-5-5/ (update to check against 5.6 respectively)

I have other questions not answered in this page, who can I speak to about these?​

If you have any initial follow on questions then please raise those in response to the support tickets that we raise on your behalf in your accounts so that we can get you and any other customers that might have the same questions all the information you need in good time to plan your upgrades during this calendar year. We will update this document with any common questions & answers as hey come through to us.