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.

 

Where is 5.x, or how to innovate on a monolith

With CMS 4.x supported until at least 2023, we're taking the time to incrementally innovate on the Silverstripe CMS ecosystem rather than prioritising a monolithic CMS 5.x release. Change should be a choice, and we hope to make it an easy one by continuing our work on APIs, Decoupled, and a modern CMS UI architecture.

Read post

At Silverstripe Ltd, we've been mapping out how we can help developers innovate around Silverstripe CMS. Coordinating with the Silverstripe CMS Core Committers, we wanted to bring you an update on Silverstripe CMS and its future. We see the CMS as a platform for innovation with a lean and modular core, leaving opportunities for the ecosystem to thrive on those foundations while keeping CMS 4.x projects sustainable long-term. This year, we're not working towards a CMS 5.x release.

Four years of 4.x

The CMS 4.x release in late 2017 was a major milestone and a solid foundation for building modern websites and apps. New core features such as draft and protected files, campaigns, and nested publishing enabled more powerful content authoring and a rich ecosystem around content blocks. Developer features like namespacing, a new configuration layer, and composer modules made it easier to write modular and clean code. Over a thousand modules are compatible with CMS 4.x now.

But it also took a lot of collective effort to upgrade existing sites, which is still ongoing for some of them. We’ve had a few years to reflect on the lessons from this transition, with feedback from the wider community as well as Silverstripe Ltd’s own clients. It became clear that continuity is valuable to many businesses using the CMS. Change and innovation should wherever possible, be a choice rather than an obligation.

Innovation abhors a monolith

A key benefit of Silverstripe CMS is that it provides a straightforward “batteries included” recipe for putting together websites. However, this also makes it difficult to innovate without bringing the entire monolith forward. Inevitably, this means:

  • It takes too long to roll out changes and often leads to missed expectations because of the long feedback cycles
  • We ‘bet the farm’ on our (multi-year) predictions, and can’t adjust easily once they’re in a stable release

Under this model, innovation is too expensive, too risky, and too hard. We need to be able to shift more of the innovation to the edges rather than the core. Any new ‘batteries included’ recipe updates come after innovation on specific modules has been proven.

Change as a choice

The Silverstripe CMS ecosystem will continue to innovate, but the change in its core will be guided by the following principles:

  • Validate before stable: We’ll focus on getting the foundations right in Silverstripe CMS Core, through modular architecture, empowering others to contribute to smaller parts rather than the whole monolith. However, we will be relying on the wider community to validate those foundations before they can be considered stable. Early adoption should be possible on a module-by-module basis, rather than forcing an upgrade of the whole project codebase.
  • Retain stability: We are committed to Semantic Versioning of our public API and have a clear deprecation policy. These commitments notably exclude the CMS UI frontend components until we can stabilise a React-based approach. We’ll continue to use deprecations in favour of new APIs to guide best practice and enable future-proofing in the module ecosystem, but limit this to enabling further modularity rather than “cleanup” efforts.
  • Tie API changes to tangible outcomes: The core of CMS 4.x is not where we see the biggest opportunities for innovation. Our focus will be on delivering the most value with the least amount of disruption. Any changes to core APIs need to be justified against tangible outcomes for decision-makers. As an example, we’re not ruling out a refactoring of the ORM, but it won’t be the contribution of Silverstripe Ltd in the near term.
  • Maintain secure dependencies: We only control the deprecation of our own APIs. Everyone using Silverstripe CMS is by proxy reliant on dependencies of it. Symfony 3 will become unsupported in Nov 2021. The core team has already ensured compatibility with Symfony 4. This shift will likely only affect direct users of Symfony libraries.
  • Enable Decoupled use case: We’re excited about a Decoupled and Headless CMS approach and are continuing our investment into GraphQL. There are some encouraging API-driven websites and apps with Silverstripe and GraphQL out in the wild. Static publishing engines like Gatsby and NextJS offer a different publishing architecture and developer workflow, with tooling and hosting options improving rapidly. We’re building on the existing GraphQL investment to support these use cases within the existing CMS 4.x release line (see Gatsby PoCs and NextJS PoCs).
  • Make the CMS UI maintainable: Using a more modern CMS UI with React and GraphQL is progressing slower than expected, in part because it’s a bit like changing the wheels while driving a car. It has generated some healthy discussion on GitHub! With a component-oriented frontend architecture through React, we’re seeing early-stage payoffs in maintaining the stability and visual consistency of this complex app. Deeper refactoring such as switching GridField, ModelAdmin, or the main Pages section to React will likely happen in new modules to enable early adoption, without breaking changes to existing modules. We’re hoping to gather feedback this way without locking down APIs or forcing unwanted change.

The road ahead

After nine years in operation and extended support, CMS 3.x is slated to go End of Life (EOL) in September this year. No end of support for CMS 4.x has been announced, it is supported for the foreseeable future, until at least the end of 2023. Silverstripe Ltd won’t focus on a CMS 5.x release in 2021, but rather encourage incremental and modular change. Silverstripe CMS is bigger than one company, and we hope to collaborate with new Core Committers emerging from the community. The vast majority of modules available for Silverstripe CMS have been developed by the broader community. By focusing on a leaner, more modular approach for CMS 5.x, this might be a chance to make CMS 5.x a more community-powered release.

Maintaining multiple release lines in a modular architecture is hard work. We can only stay true to this vision with active participation from the wider community. Let’s work together!

About the author
Ingo Schommer

Ingo joined SilverStripe with its 2.0 release, and has since become an integral member of the development team. He's from Germany, but admits that New Zealand beer is often quite tasty as well.

At SilverStripe, Ingo enjoys coming up with robust solutions for real business needs. He builds modern web applications, making sure they work well in browsers and mobile devices, not just on paper. As a core developer on SilverStripe's open source framework, he facilitates community involvement, and helps architect and implement core functionality. Ingo authored the first book about SilverStripe, and is still keen on keeping the documentation fresh.

Ingo graduated as Bachelor of Arts (Hons) in Media Production and has several years experience as a freelance PHP and Flash developer.

Away from the keyboard, Ingo is an avid gardener, debugging water flow and performance optimizing root growth instead of PHP.

Post your comment

Comments

No one has commented on this page yet.

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