A full list of module versions included in CMS Recipe {{ version }} is provided below. We recommend referencing recipes in your dependencies, rather than individual modules, to simplify version tracking. See [Recipes](/getting_started/).
This release has gone through a regression test suite to identify any possible instability between modules.
The release has also been audited by an independant security firm to identify possible security regressions.
Review the [security audit report](INSERT-LINK-TO-AUDIT).
## For development teams of Common Web Platform projects{#cwp-end}
This release marks the first release for Common Web Platform projects to eject out of managing projects in the CWP 2.x version line and to begin following the standard CMS 4.x version line, by adopting the CMS Recipe.
More information and guidance on how to manage your project composer.json file will be published as part of the CMS 4.9.0 stable release and supporting documentation.
## Dropping support for Internet Explorer 11{#ie11eol}
Silverstripe CMS 4.9.0 is the last release of Silverstripe CMS that supports Internet Explorer 11. Silverstripe CMS 4.10.0 will not support Internet Explorer 11.
[Microsoft has announced the end-of-life for Internet Explorer 11](https://blogs.windows.com/windowsexperience/2021/05/19/the-future-of-internet-explorer-on-windows-10-is-in-microsoft-edge/) on June 15, 2022. It has already dropped Internet Explorer support in many other products including Microsoft Teams and Microsoft 365. In this context, any development time dedicated to maintianing Internet Explorer support could be better use improving other areas of Silverstripe CMS.
While the Silverstripe CMS UI might not allow content authors to manage content in Internet Explorer, this does not preclude Silverstripe CMS project from outputting an a frontend site that is compatible with Internet Explorer.
Consult the [Insert images](https://userhelp.silverstripe.org/en/4/creating_pages_and_content/creating_and_editing_content/inserting_images/#lazy-loading)
article in the Silverstripe CMS user help for detailed instructions.
### Manage your CMS sessions across devices {#session-manager}
The [session manager module](https://github.com/silverstripe/silverstripe-session-manager) is a new security focused feature which allows a CMS user to view and manage their active sessions in the CMS within the "My profile" section of the CMS (/admin/myprofile). They can see the device details behind each session and have the ability to revoke these sessions. This new module has been added to `silverstripe/recipe-cms` which is the recommended method of managing Silverstripe CMS dependencies in a project.
Projects that have `silverstripe/recipe-cms` as a requirement in their `composer.json` will automatically get `silverstripe/session-manager` when you run `composer update`. If your project does not use `silverstripe/recipe-cms`, it's recommended that you require `silverstripe/session-manager` in your composer file as a security enhancement. The session manager module requires no configuration and works out-of-the-box.
If your site has the [symbiote/silverstripe-queuedjobs](https://github.com/symbiote/silverstripe-queuedjobs) module installed, then a job will automatically be created that will periodically remove old database records created by the session manager module.
CMS users can review the [Session Manager user help](https://userhelp.silverstripe.org/en/4/managing_your_website/session_manager/) for more information on managing their sessions.
#### FuntionalTest's should not use `Security::setCurrentUser($member)` when mocking an HTTP request
When writing an automated test using `FuntionalTest` the methods `$this->get()` and `$this->post()` are available to mock HTTP requests. Previously, developers could use the method `Security::setCurrentUser($member)` to define which member those mocked requests would run against.
Because `Security::setCurrentUser()` is *stateless*, its effect only last for the current request. When mocking an HTTP request, session-manager logs out the mocked user if it was defined with `Security::setCurrentUser()`.
Functional tests should use `$this->logInAs($member)` and `$this->logOut()` when mocking HTTP requests. It is still appropriate to use `Security::setCurrentUser()` when testing stateless logic. e.g.: Testing that a `DataObject`'s `canView()` method returns the correct value for the current user.
Review the [Functional Testing developer documentation](/developer_guides/testing/functional_testing/#loginas) for more details on `logInAs()` and `logOut()`.
### Default mail transport upgraded to sendmail {#sendmail}
Silverstripe CMS provides an API over the top of the [SwiftMailer](http://swiftmailer.org/) PHP library which comes with an extensive list of "transports" for sending mail via different services.
Prior to 4.9.0, Silverstripe CMS 4 defaulted to using the built-in PHP `mail()` command via a deprecated class `Swift_MailTransport`. However, using this layer is less secure and is strongly discouraged.
Installations of Silverstripe CMS setup using silverstripe/installer 4.9.0 or greater default to using the more secure class `Swift_SendmailTransport` which uses a `sendmail` binary.
It's highly recommended that existing Silverstripe CMS installation still using `Swift_MailTransport` upgrade to using `Swift_SendmailTransport` or another available transport, such as `Swift_SmtpTransport`. Details on how to use these classes are available in the [email section](https://docs.silverstripe.org/en/4/developer_guides/email/) of the developer docs.
### Support for silverstripe/graphql v4 {#graphqlv4}
The Silverstripe CMS 4.8.0 release added support for the experimental `silverstripe/graphql` v4 module. We made it easier for early adopters to run `silverstripe/graphql` v4 in this release:
- Upgrade to the Silverstripe CMS 4.9.0 release.
- Confirm your project `composer.json` file has a `"minimum-stability": "dev"` key.
- Explicitely require `silverstripe/graphql` v4 by running `composer require silverstripe/graphql:^4`
* [Dot notation support in form fields](https://github.com/silverstripe/silverstripe-framework/pull/9192): Save directly into nested has_one relationships (see [docs](/developer_guides/forms/how_tos/handle_nested_data)).
This release includes a number of bug fixes to improve a broad range of areas. Check the change logs for full details of these fixes split by module. Thank you to the community members that helped contribute these fixes as part of the release!