silverstripe-framework/docs/en/04_Changelogs/4.7.0.md

# 4.7.0 (Unreleased)

## Overview

- [Experimental support for PHP 8](#experimental-support-for-php-8)
- [Support for Symfony 4 Components](#support-for-symfony-4-components)
- [Default MySQL collation updated](#default-mysql-collation-updated)
- [Flysystem dependency shifted](#flysystem-dependency-shifted)

## New features

### Experimental support for PHP 8

You can now run Silverstripe CMS on PHP 8, which is due for release in November 2020. PHP 8 includes
many exciting new features like named parameters, attributes, and union types. There are a few
important caveats to keep in mind if you plan to adopt PHP 8 at release.

Upgrading to PHP 8 on projects using `SapphireTest` for unit testing requires adoption of the
[`sminnee/phpunit`](https://packagist.org/packages/sminnee/phpunit) fork, and Prophecy is not
currently supported. Prophecy tests can be fairly trivially ported to PHPUnit Mock Objects.  We hope
to give you better support for choosing your own testing tools, including newer versions of PHPUnit,
in a future release.

Support for PHP 8 does not yet extend to non-core modules, and PHP 8 itself is not yet stable, so
compatibility issues could arise in future PHP builds. This extends to dependencies of core, many of
which have not yet declared support for PHP 8, so you will need to run Composer with the
`--ignore-platform-reqs` flag for the time being.

Finally, support for the new JIT functionality has not yet been tested.

We encourage early adopters to report any issues running CMS Recipe 4.7.0 against PHP 8 on the
relevant GitHub repository.

### Support for Symfony 4 Components

Symfony 3 will become unsupported early next year, so Silverstripe CMS is now forwards-compatible
with Symfony 4 components. This is a largely transparent upgrade, but you may encounter errors
related to strings starting with `%` in YML files, which can be easily rectified by wrapping all
affected strings in quotes.

If you'd rather retain the previous YAML parser for the time being, you can run
`composer require symfony/yaml:^3` on your project to prevent the update to version 4.

### Default MySQL collation updated

New projects based on `silverstripe/installer` will default to the `utf8mb4_unicode_ci` collation.
This change will not affect existing projects, but developers are encouraged to adopt this collation
as it provides better support for multi-byte characters such as emojis.

Depending on the version of MySQL you are running, you may encounter issues with `Varchar` fields
exceeding the maximum indexable size:

- MySQL 5.5 and lower cannot support indexes larger than 768 bytes (192 characters)
- MySQL 5.6 supports larger indexes (3072 bytes) if the `innodb_large_prefix` setting is enabled (not by default)
- MySQL 5.7 and newer have `innodb_large_prefix` enabled by default
- MariaDB ~10.1 matches MySQL 5.6's behaviour, >10.2 matches 5.7's.

You can rectify this by upgrading MySQL, enabling the `innodb_large_prefix` setting if present, or
reducing the size of affected fields. If none of these solutions are currently suitable, you can
remove the new collation configuration to default back to the previous default collation.

### Flysystem dependency shifted

Previously the Flysystem package was pulled in via the `silverstripe/framework` module, but only
used in the `silverstripe/assets` module. To make this dependency clearer, it has been added to
the `silverstripe/assets` module and removed from `silverstripe/framework`. Most developers should
not notice any issues, but if you depend on Flysystem in your own project code, you should ensure
that you have it specified in your `composer.json`.

An edgecase exists where a project can update to `silverstripe/framework 4.7.0` but remain on
`silverstripe/assets 1.6.x`, and lose the Flysystem dependency entirely. The best way to avoid this
is by ensuring you update all core modules to the new minor release at once, ideally through a core
recipe like `silverstripe/recipe-core`.