Skip to main content

Upgrading to Jadu CMS 20.0.0

List of changes​

Dependency changes​

Minimum PHP version changed to 7.1​

Change​

The minimum php version constraint, specified in composer.json, has been updated to 7.1 (from 5.6). This has been applied across the CMS repositories.

Action​

Environments using this version onwards must be on PHP 7.1 as a minimum, and customer packages specific to minimum PHP versions lower than 7.1 will need to be updated.

Guzzle V3 removed​

Change​

Guzzle 3, guzzle/guzzle, has been removed from composer.json, due to conflicting with the new Symfony version as well as this being an abandoned package.

Action​

Any CMS provided services that were relying on Guzzle 3, have been updated to use 6.

Any custom code interacting with such services, or directly interacting with guzzle, will need to be updated.

Docs for Guzzle 6 can be found here: http://docs.guzzlephp.org/en/stable/

Symfony version changed to 3.4​

Change​

The version of Symfony, specified in composer.json, has been changed from 2.8 to 3.4.

Action​

The CMS codebase has been updated to be compatible with Symfony 3.4, with the aim of minimising backward compatible breaks, where possible. Important changes are listed in this document, for both information and to aid with any customer specific upgrades.

Any custom code interacting directly with Symfony will need to be verified against the newer version.

Symfony’s official upgrade notes can be found here:

https://github.com/symfony/symfony/blob/v3.0.0-BETA1/UPGRADE-3.0.md https://github.com/symfony/symfony/blob/3.4/UPGRADE-3.1.md https://github.com/symfony/symfony/blob/3.4/UPGRADE-3.2.md https://github.com/symfony/symfony/blob/3.4/UPGRADE-3.3.md https://github.com/symfony/symfony/blob/3.4/UPGRADE-3.4.md

Service definition changes​

Change​

Symfony 3.3 introduced some changes to dependency injection. Whilst these are optional, we’ve updated the CMS Symfony service definitions to use class names as opposed to machine names.

Action​

All CMS provided Symfony services will remain accessible as they did with 2.8, we’ve added machine name aliases to the new class name definitions, so any code relying on these services will still have access in the same way as they did beforehand.

As mentioned above, the changes we’ve made here are optional, and the same process doesn’t have to be performed on any of your own services, however it does allow you to use some new features such as automatic service loading.

More information on this can be found here: https://symfony.com/doc/current/service_container/3.3-di-changes.html

Removal of commands.xml​

Change​

We’ve removed usage of the configuration file for adding custom cli console commands, commands.xml. The CMS now makes exclusive use of Symfony services for registering console commands.

Action​

Any custom commands you’ve previously registered with the CMS via the usage of commands.xml will have to be defined as a symfony service. This can be done via adding these to a custom symfony Control Center bundle (recommended) or to register these via your project Control Center configuration (detailed below).

Example (project configuration approach)​

In this example, we have a project that we’ll be upgrading with the following config/commands.xml:

<?xml version="1.0" encoding="utf-8"?>
<system xmlns:config="http://www.jadu.co.uk/schema/config">
    <commands config:type="array">
        <item key="project.hello">Project\Command\HelloWorldCommand</item>
    </commands>
</system>

To begin with, we’d want to create a new folder in which we’ll register the above commands as symfony services, config/cc.

Within this folder we’ll add a new file config/cc/commands.yml in which we’ll be defining our command services:

services:
   Project\Command\HelloWorldCommand:
       tags:
           - { name: console.command }

Finally, we’ll need to register the above file with the application. The application looks for two configuration files depending on the environment, development and production. This allows us to have commands (or any other symfony service) which are only present in dev, production, or both. In this example, we’re going to be using this command in both so we’ll link our two environment configuration files via a common config.yml file. So we’ll add the following 3 files:

The development environment configuration file: config/cc/config_dev.yml:

imports:
   - { resource: config.yml }

The production environment configuration file: config/cc/config_prod.yml:

imports:
   - { resource: config.yml }

The common configuration file config/cc/config.yml:

imports:
   - { resource: commands.yml }

That’s it, our existing commands are now registered as symfony services and we can remove the old config/commands.xml file.

Tools​

PHPUnit bridge​

A set of utilities to find usage of deprecated code report when running PHPUnit https://symfony.com/doc/current/components/phpunit_bridge.html

SensioLabs DeprecationDetector​

A static analysis tool for finding deprecated code within source code https://github.com/sensiolabs-de/deprecation-detector