Symfony 3,4 Upgrade guidance

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 centre bundle (recommended) or to register these via your project control centre 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

results matching ""

    No results matching ""