# 4.4.0 (Unreleased) ## Overview {#overview} - Security patch for [SS-2018-022](https://www.silverstripe.org/download/security-releases/ss-2018-022) - [Correct PHP types are now returned from database queries](/developer_guides/model/sql_select#data-types) - [Server Requirements](/getting_started/server_requirements/#web-server-software-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: ```yml SilverStripe\Dev\DevelopmentAdmin: deny_non_cli: true ``` ## Upgrading {#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. ```js { // ... "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](https://www.silverstripe.org/download/security-releases/ss-2018-022) introduces a new [Confirmation](api:SilverStripe\Security\Confirmation) component and [ConfirmationMiddleware](api:SilverStripe\Control\Middleware\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`