It is now the end of September 2018. It’s been almost exactly a year since we’ve heard the first official signs that our beloved Silex would be sunset, after the release of Symfony 4. As you might know, Bolt was built on Silex, so this literally meant our foundation would no longer be maintained. Bolt 3 was (and is) is ticking along nicely, so we weren’t in a rush to do drastic things, but we did realise we’d need to make a tough choice going forward: Would we keep using Silex? Even take on maintenance ourselves? Or move on, and build Bolt 4 on top of Symfony 4? If so, should we incrementally refactor all our code to make it work, or should we start fresh, and do a total refactor?


Over the last few years, we’ve made a huge mistake and we lost sight of some of our core goals. Our manifesto states:

Our slogan is "Simple, sophisticated and straightforward". This embodies everything we strive to do with Bolt: It is as simple as possible, but not simpler. It uses sophisticated technology to achieve this, and use of the system should be straightforward and evident.

In recent years, the source code of Bolt became much, much too complex and convoluted. However, it is common knowledge that you’re strongly discouraged to do a total refactor of an existing codebase. In this case, we deem it necessary, for a number of reasons. One of them is that Silex is no longer maintained, and replacing Silex for Symfony 4 isn’t exactly a drop-in replacement.

the crystal of truth

Two other factors are:

  • We’ve been re-inventing wheels, instead of using off-the-shelf components and libraries.
  • Our codebase has become quite complex, which is notable in the decline of external contributions, due to the high ‘barrier of entrance’.

We need to go back to our roots, and make sure we do not make these same mistakes again. We need to adhere to the “standing on the shoulders of giants”-principle, and make better use of the wealth of proven, high quality libraries and components that are available. This will allow us to get rid of a ton of code where we’ve been reinventing the wheel: Sessions, our i18n layer, user management, thumbnailing and jQuery-ing the entire User Interface, to name a few.

Bolt 4, a fresh start

This means that we’ll be rebuilding Bolt 4 from the ground up, as a proper Symfony 4 application, using Symfony Best Practices. We will be using components/libraries like Doctrine, Symfony Security and API-platform.


At the same time, we’re going to do a major overhaul of the Bolt Backend, using Webpack and Vue, with the following goals:

  • It should look and feel both solid and professional
  • It should be well built (UX, design, HTML, CSS and JS alike)
  • It should be (slightly) theme-able
  • It should be maintainable

The Process

This process will take a while to complete. One of the reasons for that is that we’ll need to maintain a working system in the meantime: Bolt 3.x is used by a lot of people, and we’ll keep maintaining it for the foreseeable future.

By taking the time we need to do this, we’ll ensure we can build a project that will be truly state of the art. My personal goal is to get to the point where the name “Bolt” is the first thing that comes to mind when people think about “Open Source Symfony CMS”.

The first step is a new prototype i'm working on, based on the Symfony 4 skeleton. In a week or two I hope to be able to make it public, so everybody can see where we're planning to go with this. Over the next few weeks, i'll be posting updates with progress and for how we're doing considerations about our approach.

If you’re done reading this article and wish to help in building this vision, you're more than welcome! We're open to fresh ideas, and can always use extra helping hands. Please join us on our Slack, in the #development channel.

comments powered by Disqus