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

4.4.0 (Unreleased)

Overview

• Security patch for SS-2018-022
• Correct PHP types are now returned from database queries
• Server Requirements have been refined: MySQL 5.5 end of life reached in December 2018, thus SilverStripe 4.4 requires MySQL 5.6+.
  SilverStripe 4.3 and prior still support MySQL 5.5 for their own lifetime.
• The name of the directory where vendor module resources are exposed can now be configured by defining a extra.resources-dir key in your composer.json file. If the key is not set, it will automatically default to resources. New projects will be preset to _resources. This will avoid potential conflict with SiteTree URL Segments.
• dev/build is now non-destructive for all Enums, not just ClassNames. This means your data won't be lost if you're switching between versions, but watch out for code that breaks when it sees an unrecognised value!

DevelopmentAdmin controllers

On Live environment all browser based HTTP requests to /dev/* urls get redirected to a confirmation form. See more details below in the Upgrading section.

DevelopmentAdmin cli-only mode

DevelopmentAdmin now has CLI-only mode (off by default). The mode makes all dev/* controllers to be only accessible from CLI (e.g. sake). To turn it on you may add the following configuration to your project configs:

SilverStripe\Dev\DevelopmentAdmin:
  deny_non_cli: true

Upgrading

Adopting to new _resources directory

1. Update your .gitignore file to ignore the new _resources directory. This file is typically located in the root of your project or in the public folder.
2. Add a new extra.resources-dir key to your composer file.

{
    // ...
    "extra": {
        // ...
        "resources-dir": "_resources"
    }
}

3. Expose your vendor assets by running composer vendor-expose.
4. Remove the old resources folder. This folder will be located in the public folder if you have adopted the public web root, or in the root of your project if you haven't.

You may also need to update your server configuration if you have applied special conditions to the resources path.

DevelopmentAdmin controllers

The security fix for SS-2018-022 introduces a new Confirmation component and ConfirmationMiddleware that prevents CSRF based attacks on the urls placed under dev/* path.

If you use dev/ endpoints, you may need to consider the following changes:

• /dev/confirm url now holds the confirmation form, where users will have to manually approve their actions
• on live environments all non-cli (browser based) HTTP requests to dev/* urls get redirected to the confirmation form
• ajax requests to /dev/* urls will be redirected as well (as such may stop working until configuration is added)
• GET and POST requests are handled gracefully, but other HTTP methods will be transformed to GET by the confirmation form
• you may add custom configuration for the confirmation middleware to prevent redirection for some requests or URLs

CLI based requests (e.g. sake) are not affected by the confirmation middleware and keep working as is.

If you are a 3rd party module developer and you extend DevelopmentAdmin adding new routes under the dev/ path, you may need to add custom rules for the confirmation middleware in your module configuration. Otherwise, people navigating those through browsers will have to confirm every single action, which may impair user experience significantly.

You may find a configuration example in the framework _config/requestprocessors.yml file, named dev_urls-confirmation-exceptions.

ErrorControlChainMiddleware is deactivated

ErrorControlChainMiddleware has been deactivated and deprecated. It is going to be removed in SilverStripe 5.0. That means uncaught exceptions and fatal errors will no longer trigger flush on live environments.

The main historic purpose of ErrorControlChainMiddleware was to detect the application state in which manifest cache is incompatible with the source code, which might lead to fatal errors or unexpected exceptions. The only way this can happen is when manifest cache has been generated and application source code files change afterwards. The only reasonable cause for that on live environments would be application deployment.

Ideally, you should avoid reusing manifest cache between different application deploys, so that every newly deployed version generates its own manifest cache. However, if that's not the case, you may want to consider using SS_FLUSH_ON_DEPLOY setting, which automatically triggers flush on every deploy by comparing filesystem modification time with cache generation timestamp. This effectively eliminates the possibility for the manifest cache to be incompatible with the deployed app.

WARNING! If you do not deploy your application as a whole, but rather update its files in place with `rsync`, `ssh` or `FTP`, you should consider triggering CLI based `flush` manually on every such deploy (e.g. with sake). Otherwise, you may end up with your application cache to be incompatible with its source code, which would make things broken. There is a tiny possibility that you wouldn't even be able to flush through browser in that case.
In that case you may consider using `SS_FLUSH_ON_DEPLOY`. Depending on your deployment tooling you may point it to a filesystem resource that gets modified on every deploy update so that the framework will automatically perform `flush` for you.
The best practice is not to reuse the application manifest cache between deploys.

Changes to internal APIs

• PDOQuery::__construct() now has a 2nd argument. If you have subclassed PDOQuery and overridden __construct() you may see an E_STRICT error
• The name of the directory where vendor module resources are exposed can now be configured by adding a extra.resources-dir key to your composer file. The new default in silverstripe/installer has been changed to _resources rather than resources. This allows you to use resources as a URL segment or a route.
• SilverStripe\Control\HTTPApplication now uses FlushDiscoverer implementers to check for flush
• SilverStripe\Control\Middleware\ConfirmationMiddleware component implemented
• SilverStripe\Control\Middleware\URLSpecialsMiddleware component implemented
• SilverStripe\Control\Director::isManifestFlushed static function implemented
• SilverStripe\Core\CoreKernel::isFlushed function keeps boolean whether manifest cache has been flushed
• SilverStripe\Core\Environment::isCli method is now responsible for low level CLI detection (on before the kernel boot stage). Director::is_cli is still to be used on the application level.
• SilverStripe\Core\Startup\ErrorControlChainMiddleware::__construct has a 2nd argument which activates its legacy behaviour
• SilverStripe\Core\Startup\FlushDiscoverer interface and a number of its implementations in the same namespace
• SilverStripe\Dev\DevConfirmationController implements the confirmation form for the /dev/confirm endpoint
• SilverStripe\Dev\DevelopmentAdmin now has deny_non_cli configuration parameter
• SilverStripe\Security\Confirmation component implemented

Deprecations

• SilverStripe\Control\Director::isManifestFlushed
• SilverStripe\Core\CoreKernel::getEnvironment
• SilverStripe\Core\CoreKernel::sessionEnvironment
• SilverStripe\Core\Startup\AbstractConfirmationToken
• SilverStripe\Core\Startup\ConfirmationTokenChain
• SilverStripe\Core\Startup\ErrorControlChain
• SilverStripe\Core\Startup\ErrorControlChainMiddleware
• SilverStripe\Core\Startup\ErrorDirector
• SilverStripe\Core\Startup\ParameterConfirmationToken
• SilverStripe\Core\Startup\URLConfirmationToken