Symfony components and the full stack framework in CMS ecosystems
In addition to content management CMSes actually do quite a bit of other things, which set them apart from pure Content API solutions. Layout management, scheduling and permissions are amont the key functionalities people have come to expect from their tools.
This is where a gap still exists between CMSes and Frameworks. PHP frameworks like Code Igniter, Zend and Symfony itself have very little to provide when it comes to user interfaces.
Decoupling's not just about browser vs. server
There are extreme examples of coupling both the front end and back end to a true full stack framework with JavaScript. One such framework, Meteor itself has since changed course and realised that one size does not fit all:
First of all, adopting Meteor requires switching out both your front-end and back-end. You’re either all-in, or you don’t use it at all. This creates a bigger barrier to entry compared to front-end frameworks like React and Angular, or server languages like Go or Elixir.
- The State Of Meteor Part 1: Growing Pains
Such extreme coupling is not even feasible in the PHP realm, but there has plenty of buzz around decoupling from your CMS from your front end. There are obvious challenges here as there is plenty more to content management than managing content.
There is no universal standard for REST APIs (not for content and even less so for managing layouts) and you'll end up coupling to the specific flavour of REST that your system happens to serve. GraphQL, Falcor or other solutions might make switching between backends easier in the future.
In addition to decoupling on the server vs. browse, there's also the aspect of coupling on a monolithic CMS and a database structure versus separating your Content Repository, Web Framework and Web Editing Tools:
Standardising on a Framework or Adopting components?
The Code Igniter project was eventually handed over to BCIT for development and maintenance, it remains a good example of how valuable a framework for building a CMS essentially is. Before and after CI and EE there have been a lot of CMS product started from scratch.
But since Composer and a number of PSRs from the PHP-FIG, it's now very common place for PHP developers to share code across projects. Now a large number of CMS products written have adopted bits from elsewhere, rather than reinventing everything for themselves. In this bunch, there are two main approaches:
- Standardising on a framework
- Adopting components
Standardising a CMS on a Framework
Standardising on a framework brings a lot to the table. Frameworks like Symfony SE or Zend obviously come with a lot of opinions and conventions. This restricts development and sets a clear baseline standard. Obviously in some cases these standards are not the best kind and can lead to major rewrites, like that of Angular JS.
On the positive side, when standardising on a framework you get a pool of developers who are already familiar with your base conventions. They'll obviously need to learn the problem domain of content management, but the basics like routing, translations and forms are already in place and used by thousands of developers.
When standardising on a framework you also gain a skillset that is fully transferrable to working with both CMS driven sites as well as custom applications or other developer platforms built on the same platform.
Adopting components to your CMS
Adopting PHP components to your CMS gives you lots of ready made bits and pieces to work with. These will help accelerate development by solving common task like reading configuration, managing database connections and more. This is also an unopinionated way of using these components as you can continue on the path you've set before.
When components is that you are likely still solving a lot of problems that already have valid solutions them. What is the value that our own database connection implementation or translation system gives you? Is your HTTP caching mechanism better than that of a framework? Drupal for example is often sold as a new framework for Symfony developers should learn.
When building a CMS it is increasingly likely that what you are actually building is a framework that is tightly coupled to your specific content management centric data model and specific conventions. Developer skillset is also not directly transferrable between any other applications.
So many Symfony CMSes...
Nowadays it's hard to attend discussions on LAMP CMSes which does not mention Symfony. But there's really nothing unique to Symfony. It's more like the Pepsi vs. Coke battle, in some places Pepsi just happens to be more popular. Both being essentially Distinguishable from each other.
The popularity of Symfony over some other high quality PHP projects is largely due to a combination of the timing of the Symfony2 framework launch, principles and readiness of the PHP ecosystem.
These lead to Symfony being the most common framework and set of components widely deployed among different Content Management Systems, the single most common type of web applications on the internet.
Some CMSes that have taken the framework approach:
- Bolt CMS (On Silex micro framework, not Symfony full stack)
- Concerto CMS
- eZ Platform
- Jarves
- Kunstmaan
- Sulu
Some CMSes that have taken the path of adopting components:
Regardless of which approach you take, you'll be sharing more code than you would have with the approach that WordPress, for example has continued on - partly due to necessity and conservative backwards compatibility, partly due to NIH syndrome.