SilverStripe 3.7.1 and 4.2.0 are out

We're proud to announce new minor releases for the SilverStripe 3.x and 4.x release lines. As usual, they follow Semantic Versioning, so are ready to be used by any SilverStripe-based project. In this particular release, there are a few performance and security related changes which developers should consider when upgrading.

Improved upgrade guide

We have rewritten the upgrade guide to a more consistent step-by-step upgrading guide, which gives you the choice between using our upgrader tool or doing the job manually for each step.

HTTP cache header changes

HTTP caching is an important part of making websites fast and reliable. This SilverStripe release aims to avoid mistakes in the process by providing more high level HTTP Caching APIs. The default system behaviour will also pick up more situations where caching needs to be disabled automatically, for example when previewing draft content.

Disable session-based stage setting

When viewing a versioned record (usually pages) in "draft" mode, SilverStripe used to record this mode in the session for further requests. This has the advantage of transparently working on XHR and API requests, as well as authenticated users navigating through other views. But since it can also cause issues with caching draft content and user confusion about states, we've decided to solely rely on the ?stage=Stage URL parameter starting with SilverStripe 4.2. If you manually generate your own links which don't add this parameter, consider opting out of this security feature.

Historical version consistency

Each save and publish operation in the CMS creates a new version of the record. In SilverStripe 4, this can often cascade into further nested records with their own versions. For example, content blocks contained in a page, images contained in these blocks, and so forth. In SilverStripe 4.2, we have ensured that viewing those historical versions is an accurate reflection of what was shown to your visitors at this time, by incorporating nested versions. This also accounts for edge cases like deletions in versioned many-many relationships, as well as applying to rollback and restore behaviour. Read the story card for more details.

App folder name

Starting with SilverStripe 4.2, we're recommending that you call your project code folder "app" rather than "mysite", following conventions in many other web frameworks. This isn't mandatory, but if you choose to change your project we have a handy upgrade tool to automate this process (instructions).

Changelog

For a full list of changes, please review the 3.7.1 changelog and 4.2.0 changelog.