tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity
f21515e0b1
silverstripe-framework/docs/en/04_Changelogs/4.7.0.md
Steve Boyd f21515e0b1 Merge branch '4.7' into 4
2020-11-12 15:13:46 +13:00

6.8 KiB
Raw Blame History

4.7.0 (Unreleased)

Overview

New features

Updated file usage table

CMS users can view where a file is used by accessing the Used on tab in the Files section. This feature allows them to identify what DataObjects depend on the file.

The following changes have been made to the Used on table:

  • Data is now sourced from has_one and many_many relations instead of the ownership API
  • This means more data relationships should be shown than before
  • Uses the new RelatedDataService API in the framework module which can also be used for other non-file use cases
  • Support for linking ancestor relationships in the same table row, for instance showing the Page a Content Block is on
  • Ability to click on a row and navigate to the most relevant CMSEditLink()
  • Removal of draft badges
  • Styling tweaks such as reduced padding

Your project specific DataObjects will automatically be displayed on this Used on tab. This may not always be desirable, especially when working with background DataObjects the user can not interact with directly. It is recommended you view the CMS Developer Guide for more information on this change, see the File Usage section.

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 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.

MySQL connection mode now configurable

In MySQL versions >=5.7.5, the ANSI sql_mode setting behaves differently and includes the ONLY_FULL_GROUP_BY setting. It is generally recommended to leave this setting as-is because it results in deterministic SQL. However, for some advanced cases, the sql_mode can now be configured on the database connection via the configuration API (see MySQLDatabase::$sql_mode for more details.)

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.

Improved Toast notifications

Toast notifications have been completely revamped

  • Toast notifications can now be triggered from React components using Redux actions
  • Actions can now be attached to the toast notifications
  • Accessibility has been improved (see the component documentation for caveats when using actions)

Asset-admin has been updated to use toast notifications instead of alerts. More modules will start using them in future releases.

Review the Toast story in the pattern library to learn how and when to use the toast notifications.

DataObject constructor support for hydration

Many developers wrongly assumed that the DataObject constructor could be used to "hydrate" a record by passing an array of value to it. While this worked in some cases, values would be run through setters and validation occasionally leading to inconsistencies.

Silverstripe CMS Recipe 4.7 introduces improvements to the DataObject constructor to provide proper support for hydration.