Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.


SilverStripe 4.4 has landed! Improved file URLs, upgraded themes, and more

The latest minor release of SilverStripe 4 has arrived and we’re so excited to be able to share it with you. SilverStripe 4.4 boasts a number of improvements to the Developer experience and new features for Content Editors—all of which aim to deliver higher-performing websites.

Read post

The latest minor release of SilverStripe 4 has arrived and we’re so excited to be able to share it with you. SilverStripe 4.4 boasts a number of improvements to the Developer experience and new features for Content Editors—all of which aim to deliver higher-performing websites. 

SilverStripe follows semantic versioning, so this 4.4 release can be used in any current SilverStripe project right now, without any code refactoring. View the changelogs here.

What’s new in SilverStripe 4.4?

On the design side, there are a number of improvements and bugfixes in this release that make the CMS more stable and usable. The biggest changes you’re likely to notice are an improved user experience for GridField buttons and a new library of icons for the site tree.

Meanwhile, Developers will have their hands full with new APIs, enhancements, and security fixes, including:

  • Public files now have permanent URLs
  • Migration of legacy thumbnails
  • File migration is faster and more robust
  • Flush on deploy
  • New GraphQL features

Better Buttons has landed

Ranking in the top five most installed modules for SilverStripe 3, Uncle Cheese’s betterbuttons module will soon see the end of its seven-year reign, as the module has now been ported into the core.

Better buttons

Adapted to fit the new CMS design patterns, this set of features drastically improves user experience, saving an untold number of clicks and page reloads by adding more functionality to the detail view of grid fields. Users can now add new records and paginate between records from within this view, resulting in less reliance on the back button.

Porting this module over had been in discussion for a long time. While our general principle at SilverStripe is to let community modules solve problems where appropriate, this module wasn’t an add-on so much as a sledgehammer for a lacking user experience that the product delivered by default. For that reason, it was a natural course of action for us to take.

But what about the rest of better buttons? The old betterbuttons module offered a number of experimental yet highly-used APIs that did not make the cut for the initial port to SilverStripe 4, including custom actions, “save and close” behaviours, and more. These may be merged in a later release or simply spun off into a separate module.

For more information about how we navigated this decision, check out the Github thread.

New SiteTree icons

The icons we’ve been using to distinguish different page types were a ragtag gang of relics from a bygone design paradigm—so, we’re moving on.

With a nudge from community member Petar Simac, our design team was inspired to dig into this and replace the old rasterised clip art with a library of slick font icons. Developers can target these icons declaratively with a definition of the $icon variable on a SiteTree class.

Sitetree icons

Public files now have permanent URLs

SilverStripe 4.0 introduced an abstraction of the assets layer meaning that Developers could configure their SilverStripe installation to store files in any number of ways, including remote storage like Amazon S3. In order to achieve this, files had to be stored with a “hash” in their path, for example: assets/[content-hash]/myfile.pdf.

Because the hash was based on file contents, replacing file contents would break existing incoming links, for example, from external websites or bookmarks. There have been a number of improvements over the last few minor releases to mitigate this problem with redirects, but ultimately, the only long-term solution is to afford Developers a way to store these files in a path without the hash.

The new format now applies to all new files automatically and existing files will be migrated over the moment they’re saved and published. We’ve included a migration task that allows Developers to opt-in to the new format proactively, eliminating the need for redirects.

Migration of legacy thumbnails

SilverStripe 4.0 regenerated thumbnails in a different format, without removing thumbnails in the old format, which would lead to an increase in storage over time and duplicated effort. In 4.4, you can now purge the old thumbnail formats.

File migration is faster and more robust

We’ve made several improvements to the migration task, including:

  • It’s now faster and less memory intensive
  • It's been updated to handle multiple edge cases that would previously have caused failure
  • The output has been improved to provide clearer information about the actions performed by the task
  • The task is now more modular, allowing Developers to run specific sub tasks individually

Migration preview

The file migration task documentation has been updated to provide clearer guidance when upgrading project with a large number of files. A new optional task allows migration of file and image references in content created through SilverStripe 3.x. The new shortcode format will retain those references even if the files are moved.

Planning on migrating files from SilverStripe 3.x? You’ll want to use the 4.4.1 release if you’re migrating files from SilverStripe 3.x to 4.4, as this concurrent patch release contains critical bug fixes and optimisations for file migrations.

Flush on deploy

Depending on how you deploy your projects, you may consider using the new FLUSH_ON_DEPLOY environment variable which implements automatic flush (but not dev/build) right after you deploy changes to your project.

This new feature is recommended if your deployment process implies mere in place replacement of files with the following dev/build?flush. On the other hand, it may not be needed if you already fully control cache invalidation on deploy by any other means, such as creating a fresh new container for every deploy, or renaming the application folder and switching symlinks.

New GraphQL features

One of the major limitations with scaffolding a “read” query in GraphQL was that it returned an all-inclusive list and there was no way to filter it to a subset of records. In SilverStripe 4.4, these read queries now have a configurable “search” option.

You can now also store pre-baked GraphQL queries by ID on your GraphQL server, allowing consumers of your API to access them by reference rather than by a fully expressed query. This is useful for trimming the overhead of a request, and also improves security for websites that offer an API, but want to put boundaries around what can be queried.

Read more in the GraphQL README.

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 (for example, sake). To turn it on, add the following configuration to your project configs:

   deny_non_cli: true

Security fixes

SilverStripe 4.4 contains a handful of security fixes, the details of which you can read on our Security Releases page. One of them, explained below may affect your workflow.

Flush and development URL tools now require form submission (CVE-2019-12246)

If a user logged in as an administrator was tricked or forced into visiting a URL like dev/build on the production server, this could be exploited to form a Denial-of-Service attack. In practice, of course, one should be extremely judicious about running dev/build on production in the first place, if ever at all.

Nonetheless, this leaves open a significant security hole. dev/build and its cousins ?flush and ?isDev now require form submissions to execute in order to prevent spurious requests from executing these expensive tasks. 

Keen to get your upgrade underway?

Talk to your Digital Agency or Developer about upgrading 

Haven’t got a Developer or Agency? No problem! Browse the SilverStripe Developer & Partner Directory and filter by location to find a SilverStripe Developer near you.   

Developers, check out our documentation

Head to our Developer Docs to view the changelogs and the Upgrade Guide.

Are you an agency selling SilverStripe?

We’d love to hear about your customer experiences with upgrading to SilverStripe 4. Your answers will help focus our efforts in facilitating upgrades. Take the 5 minute survey here.

About the author
Aaron Carlino

Aaron Carlino, better known by his whimsical pseudonym Uncle Cheese has been an active member of the SilverStripe community since 2007, and has never looked back. In that time, he has established himself as a support resource, mentor, and contributor of some of the framework's most popular open source modules.

Post your comment


  • SilverStripe <3
    Keep up the good work!

    Posted by Conan, 21/06/2019 7:39pm (5 years ago)

  • Thanks for the clarification @Guy Marriot - good to hear!

    Posted by Eric, 13/06/2019 10:35am (5 years ago)

  • Hi Eric. The change you are seeing has been automatically flagged as an API change by the system that generates our changelogs. Normally it would be a breaking change (a major by SemVer) but it's actually just removing a method that was added in a prior commit before the release. As a result we're not actually removing any stable API, and isn't classified as a API change.

    Posted by Guy Marriott, 13/06/2019 10:28am (5 years ago)

  • "SilverStripe follows semantic versioning, so this 4.4 release can be used in any current SilverStripe project right now, without any code refactoring. View the changelogs here."

    Literally the first commit under "API changes" ( removes a public method.

    Posted by Eric, 12/06/2019 3:08pm (5 years ago)

RSS feed for comments on this page | RSS feed for all comments