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