How to build your own CMS, and why you shouldn't
For a while now we've been looking for a competent alternative to compete with Drupal. When a client requests a Content Management System (CMS), our go-to-technology has always been Drupal, which is also the reason why 65% of our developers are Drupal developers. Lately, however, we've had a growing need for a custom CMS solution.
How we started out
We've built up some experience with Bolt CMS and Wordpress but none of those provided an adequate, customisable CMS. After briefly looking into a few CMS possibilities built on top of Symfony, we decided none of these would fit our needs. We were afraid we would spend most of our time writing hacks to make their code work the way we wanted.
So, quite foolishly, we decided to build our own CMS. As most developers experience at some time or other over the course of their careers, we were convinced our idea was great and we would build a revolutionairy new CMS from the ground up.
Our first rewrite
Oh how wrong we were to think that, here's what happened: for a few days of development things were getting along just nicely. However, soon enough it was time to tackle our first challenging feature: Translations and Versions of a page object. There are many ways to deal with this problem and all of them have their own benefits and drawbacks. After some pondering, we stumbled upon PHPCR (PHP Content Repository) and turned towards Symfony CMF(Content Management Framework), which is based on PHPCR. This framework has solutions for both of these problems, so after some experimenting we decided to rewrite our code base and base our CMS on the foundation of Symfony CMF. Our progress skyrocketed and we got so much work done.
We then came to the point where we had to deal with our second major challenge: building an admin interface that would allow us to manage our setup. We started creating CRUD (Create-Read-Update-Delete) actions and got along slowly. Every time we started a new part, we refactored it to be as scalable and future-proof as possible. After a few days of development, we realised this was going to take a while. We noticed the Symfony CMF team suggesting to use the Sonata Admin Bundle to handle backends, this led us to considering Sonata.
Our second rewrite
At this point we started to lose confidence in the idea of building our own CMS. We started asking around if people had experience with Sonata and how much work it would take to change course for the 3rd time. We decided we would allow ourselves 3 days to try and get something done. If, within that time frame, we could get a Sonata setup that was equal to or better than our current Symfony CMF approach, we would make the switch. Otherwise we'd continue developing our own CMS since we'd already spent quite some time developing it.
Surprisingly, we managed to get everything up and running. We had a working CMS including our custom features in less than 3 days. At this point we realised we'd been foolish to think we should write our own CMS from scratch. A Content Management System is a common necessity in software development. Many people have tackled this issue before, so we're far better off helping to improve an open source project and contributing to a community than to throw yet another new alternative into the mix, and maintain our own code.
There are always going to be pros and cons when using an open source CMS, these are the main points we're taking away from this experience:
- Fast develoment
- Community help
- Most problems have been solved, or a solution is present
- Less maintenance (since the community helps)
- Security is being watched by the community
- Documentation can be lacklustered(Sonata's, for example, isn't the greastest)
- Open source code means some code may not be optimal and contributing is going to be time consuming. (but worth it)
Overall, writing your own CMS is a great experience since it gives you some insight into a common problem in software development: content management. However, extending from open source has many advantages over rolling your own solution.
So before you start writing the next big thing, make sure you contemplate all your options.