Silverstripe CMS 4.5.1 and 4.4.5 have just been released. These 2 patch releases include a high impact security fix for an XSS vulnerability. We recommend you upgrade as soon as possible.
Stable releases have been created for all supported versions of the core recipe: 4.4.5 and 4.5.1 These include a high impact security fix for an XSS vulnerability. We recommend you upgrade as soon as possible. Changelog: Silverstripe CMS 4.4.5 Silverstripe CMS 4.5.1Hide attachment content
@max set the channel topic: Release 4.5.1 is out. Changelog: https://docs.silverstripe.org/en/4/changelogs/4.5.1
@max has joined the channel
For people people with an interest in customising the front end of the CMS, we would like your feedback the possibility of introducing TypeScript to our front-end code. • I've just posted a forum explaining what we've been experimenting with https://forum.silverstripe.org/t/introducing-typescript-to-our-front-end-stack/2692 • We also have a Google Survey where we're trying to better understand how developers go about customising the Silverstripe CMS UI https://docs.google.com/forms/d/e/1FAIpQLSekp_jHNY1liHG1vFr8OFXUyPpMv_czOwnlfoHT8DuOL7M8qg/viewform
Hi Andy, running the FileMigrationTask should move the files around however your HTML Field will probably still reference the old URL. There's a TagToShortcodeTask that will rewrite existing HTML data to point to the new format:
That might be what's going on.
Hi everyone, we're thinking of changing the way we approach our release process. Here's an overview of what we're thinking of doing. Please let us know what you think.
The internal team at Silverstripe (aka CMS Squad)responsible for the development of Silverstripe CMS is currently in the process of rethinking how we approach our release process. Today, we’re going to share some of the changes we’re thinking about implementing and how this might impact the community. We’ll love to hear your feedback on what you’re thinking and how this might impact you. TL;DR We want to minimise the time we spend tagging minor releases and make it easier for the community to ...Hide attachment content
Not sure if it’s worthwhile outlining what differs from how it’s done currently? A lot of this stuff seems pretty inline with happens now to an outsider.
Right now, there's not really any formal process. We might do a beta, but we might not. So basically, we're going from having no process to actually having one.
The last time we did a beta, we had a week between the beta being tag and the RC being tag. For 4.5, we did an alpha and then an RC a few days later. The reason we might do a beta or an alpha have been mostly internal so far.
For example, the reason we did an 4.5.0-alpha1 was that our internal team had been reorganised in October and the module ownerships had shifted a bit.
Our hope is that if we can have regular sequence of events, the community we'll be in a better position to help us test the beta.
You can also define them in your bash session like this:
- export SS_DATABASE_NAME=mydb
- export SS_BASE_URL=http://mysite.com
You can pass as many env variable as you want.