12 KiB
4.9.0 (Unreleased)
Overview
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.
Core module versions
Module | Version |
---|---|
silverstripe/admin | 1.9.0 |
silverstripe/asset-admin | 1.9.0 |
silverstripe/assets | 1.9.0 |
silverstripe/campaign-admin | 1.9.0 |
silverstripe/cms | 4.9.0 |
silverstripe/config | 1.2.0 |
silverstripe/errorpage | 1.9.0 |
silverstripe/framework | 4.9.0 |
silverstripe/graphql | 3.6.0 |
silverstripe/login-forms | 4.5.0 |
silverstripe/mimevalidator | 2.2.0 |
silverstripe/reports | 4.9.0 |
silverstripe/session-manager | 1.1.0 |
silverstripe/siteconfig | 4.9.0 |
silverstripe/versioned | 1.9.0 |
silverstripe/versioned-admin | 1.9.0 |
Supported module versions
Module | Version |
---|---|
bringyourownideas/silverstripe-composer-update-checker | 2.0.3 |
bringyourownideas/silverstripe-maintenance | 2.3.1 |
cwp/agency-extensions | 2.5.0 |
cwp/cwp | 2.8.0 |
cwp/cwp-core | 2.8.0 |
cwp/cwp-pdfexport | 1.2.0 |
cwp/cwp-search | 1.5.0 |
cwp/starter-theme | 3.2.0 |
cwp/watea-theme | 3.1.0 |
dnadesign/silverstripe-elemental | 4.7.0 |
dnadesign/silverstripe-elemental-userforms | 3.0.0 |
silverstripe/akismet | 4.1.0 |
silverstripe/auditor | 2.3.0 |
silverstripe/blog | 3.8.0 |
silverstripe/ckan-registry | 1.3.0 |
silverstripe/comment-notifications | 2.1.0 |
silverstripe/comments | 3.6.0 |
silverstripe/content-widget | 2.2.0 |
silverstripe/contentreview | 4.3.0 |
silverstripe/controllerpolicy | 2.2.0 |
silverstripe/crontask | 2.3.0 |
silverstripe/documentconverter | 2.1.1 |
silverstripe/elemental-bannerblock | 2.3.0 |
silverstripe/elemental-fileblock | 2.2.0 |
silverstripe/environmentcheck | 2.3.0 |
silverstripe/externallinks | 2.1.1 |
silverstripe/fulltextsearch | 3.8.0 |
silverstripe/gridfieldqueuedexport | 2.5.0 |
silverstripe/html5 | 2.1.0 |
silverstripe/hybridsessions | 2.3.0 |
silverstripe/iframe | 2.1.0 |
silverstripe/ldap | 1.2.1 |
silverstripe/mfa | 4.4.0 |
silverstripe/realme | 4.1.1 |
silverstripe/registry | 2.3.0 |
silverstripe/restfulserver | 2.3.0 |
silverstripe/security-extensions | 4.1.0 |
silverstripe/securityreport | 2.3.0 |
silverstripe/segment-field | 2.4.0 |
silverstripe/sharedraftcontent | 2.5.0 |
silverstripe/sitewidecontent-report | 3.1.0 |
silverstripe/spamprotection | 3.1.0 |
silverstripe/spellcheck | 2.2.1 |
silverstripe/subsites | 2.4.0 |
silverstripe/tagfield | 2.7.0 |
silverstripe/taxonomy | 2.2.0 |
silverstripe/textextraction | 3.2.0 |
silverstripe/totp-authenticator | 4.2.0 |
silverstripe/userforms | 5.10.0 |
silverstripe/versionfeed | 2.1.0 |
silverstripe/webauthn-authenticator | 4.3.0 |
silverstripe/widgets | 2.1.1 |
symbiote/silverstripe-advancedworkflow | 5.5.0 |
symbiote/silverstripe-multivaluefield | 5.1.0 |
symbiote/silverstripe-queuedjobs | 4.8.0 |
tractorcow/silverstripe-fluent | 4.5.1 |
Upgrading to Recipe {{ version }} is recommended for all sites. This upgrade can be carried out by any development team familiar with Silverstripe.
- Security audit and regression test
- For development teams of Common Web Platform projects
- Dropping support for Internet Explorer 11
- Features and enhancements
- Bugfixes
Regression test and Security audit
This release has been comprehensively regression tested and passed to a third party for a security-focused audit.
While it is still advised that you perform your own due diligence when upgrading your project, this work is performed to ensure a safe and secure upgrade with each recipe release.
For development teams of Common Web Platform projects
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
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 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.
Features and enhancements
Image lazy loading
Most modern browsers support the ability to "lazy load" images. When an image is configured to be lazy loaded, browsers only request the image once it's about to be visible to the users. This reduces the initial rendering time for pages.
From v4.9, Silverstripe CMS lazy loads most images by default. You have the options to opt-out of this behaviour globally or on specific image instances.
This feature was implemented in partnership with Google.
Read Browser-level image lazy-loading for the web on web.dev more information.
How developers can interact with image lazy loading
Most images get the loading="lazy"
attribute added to them. This includes:
- images added via the HTML Editor's insert media button
- image DataObjects added to templates.
To disable lazy loading for an individual image in a template, use $MyImage.LazyLoad(false)
.
Image HTML tags (<img>
) added in templates are not lazy loaded by default. Developers
can manually lazy load these images by adding a loading="lazy"
attribute.
Read the Image Lazy Loading Silverstripe CMS developer documentation for more details and code examples.
Opting out of image lazy loading globally
There's some scenarios where you might not want to use the native Silverstripe CMS lazy loading. For example, you might already have a custom lazy loading implementation.
To opt out of lazy loading globally, use the following yml config:
SilverStripe\Assets\Image:
lazy_loading_enabled: false
How content authors can interact with image lazy loading
Content authors can disable lazy loading on images added via the HTML editor field in the Insert media dialog by setting the Loading field to Eager.
Consult the Insert images article in the Silverstripe CMS user help for detailed instructions.
Manage your CMS sessions across devices
The session manager module 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 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 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 for more details on logInAs()
and logOut()
.
Upgrade to Swiftmailer version 6
Silverstripe CMS provides an API over the top of the SwiftMailer PHP library which comes with an extensive list of "transports" for sending mail via different services. Silverstripe CMS 4.9.0 upgrades to Swiftmailer version 6 from version 5.
Moving away from Swift_MailTransport
Prior to 4.9.0, Silverstripe CMS 4 defaulted to using the built-in PHP mail()
command via a deprecated class Swift_MailTransport
. However, the Swiftmailer maintainers have decided to remove this class because of some inherent security flaw in the way the PHP mail function handles the from
header.
Read this GitHub comment by a SwiftMailer maintainer for a detailed explanation of the weakness of the PHP mail function.
We have included the deprecated Swift_MailTransport
class in the silverstripe/framework
codebase to ensure backward compatibility for project upgrading to Silverstripe Recipe CMS 4.9.0. However, using this layer is less secure and is strongly discouraged.
New Silverstripe CMS project created from silverstripe/installer
4.9.0 or greater will default to using the more secure class Swift_SendmailTransport
which uses a sendmail
binary.
It's highly recommended that existing Silverstripe CMS installation using Swift_MailTransport
upgrade to Swift_SendmailTransport
or another available transport, such as Swift_SmtpTransport
. Details on how to use these classes are available in the email section of the developer docs.
Other new features
- Dot notation support in form fields: Save directly into nested has_one relationships (see docs).
Bugfixes
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!