Status of Sulu CMS Bundles

Bundles are Symfony’s way of structuring projects to make code reusable. In comparison to classical plugin architecture that provides a standardized interface, bundles provide more power. Plugins might restrict what you can access, while the Symfony Bundle System and its services architecture make it possible to access much more. Symfony itself is built using the bundle system. It’s one of the reasons Symfony is so amazing.

Another great thing is that Symfony bundles collect together all the resources for a single feature, or entire modules, of the system in one place, which you install as a whole. It makes installation and management very easy. That’s why bundles are perfect for sharing code between applications.

And that’s how we use bundles.

We keep Sulu CMS core focused on the essential features of every installation. Almost everything in Sulu CMS is integrated as a bundle. The ContactBundle, PageBundle, SnippetBundle, etc. All of these bundles live in a so-called mono-repo for Sulu CMS. You can see the full list of Sulu 2.0 core bundles in our documentation.

However, we also have a few optional bundles that live in their own repositories, which are versioned separately. These optional non-core bundles are listed in the Sulu CMS Repository on GitHub. For example, the SuluArticleBundle and SuluCommentBundle are optional. Although it’s much more work to handle versioning for all of these bundles independently, developers can choose only what they need.

This also solves one of the issues with developing open-source software: dependencies. On the one hand, bundles with hard dependencies are optional. If you’re not configuring a content management system to manage a large number of articles (over 10,000) you don’t need the ArticleBundle, which depends on Elasticsearch. We don’t want to force that dependency on developers.

On the other hand, we can keep core updates moving quickly while not being held back by dependencies on other open-source projects. 

With Symfony’s bundle architecture, we can push forward with new capabilities without waiting for the next version of Sulu to come out. For example, we’re in the early stages of developing the SuluHeadlessBundle (GitHub) for Sulu 2.0, which provides a JSON API to get page data. Read more about Using Sulu CMS as a Headless CMS. This is an experimental bundle in use in some production environments. Part of it might be integrated into the core at some point, but this way we can collect feedback about people’s experiences with these experimental features. 

And this is how Bundle architecture speeds up development. It allows us to keep pace with advances in Symfony. If we had waited for all dependencies to be updated before releasing Sulu 2.0, we could have been waiting a while longer and that would have been frustrating. 

For all the great things about bundle architecture, we sometimes see developers running into trouble because they may have mismatched bundles to the incorrect version of Sulu. It can be confusing if you’re wondering what versions of non-core bundles to use, which we’ll clear up now. 

At the time of writing, all of our optional non-core bundles are compatible with Sulu 1.6. We’re updating the bundles for Sulu 2.x to have as much of the old functionality in the new UI as possible. We are focusing on removing Symfony deprecations and working with other open-source projects to get third-party dependencies updated. 

If you’re curious about the status of any Sulu bundle, you can install the bundle’s 2.0 compatible developer branch to try things out. But, be warned, we may introduce breaking changes before we have a stable release. 

Check out each repository to see the issues and progress. The 2.0 compatible branch is called “develop” in most cases. Here are some examples:

⭐ Star and watch our bundle repositories on GitHub to get notified of updates.

One of the questions we’re often asked is: “Considering the status of Sulu CMS bundles — should we build on 1.6 or on 2.0?” We’d recommend looking at it case-by-case right now. 

If you’re looking at bundles that don't fully support Sulu 2.0 yet, meaning they are not yet released in Sulu 2.0 compatible version, we’d say proceed with caution if you’re thinking of using them in production. There might still be breaking changes in the future, since this is in a development state. 

If you’re building your own application where you need Sulu 2.0 features and you also need some features in a 1.6 compatible bundle — for example, the FormBundle — that’s where it’s a tough call, and that’s why we say “it depends.” I’ve seen some cases where it’s less challenging to just use the SuluFormBundle developer version with Sulu 2.x. 

If you’re not sure what to do at this stage, contact us for some advice. 

Head into Sulu’s Slack community or contact us directly if you need consulting services. 

With Symfony, we have first-class support for bundle architecture that gives open-source projects many advantages. It means we can keep the pace of development moving forward. Bundles also mean we can be more creative with open-source collaboration. They help Symfony developers navigate the intertwingled nature of open-source dependencies. 

The trade off is that at certain points, things will seem to be out of step. We’ll keep you informed as we update the non-core bundles. 

Come say hello in Slack if you have any questions.