I’ve been coding for a while now.
A long time ago, I used to work with a lot of Java code. During that time, I even created an open source project called VWTK and used it on research projects at Indiana University. I have great memories of staying up late trying out different architectural patterns, spending tons of time watching videos from JavaPolis (now called Devoxx), learning about the latest additions to the Java language and even rolling my own Dependency Injection library using AspectJ.
(I also got very fat eating lots of Twinkies, honey buns and bear claws at 3 AM at the gas station. Those were the days! )
Then for a while I gave up Java (it got too verbose) and started working with Python, thanks to probably one of the most amazing pieces of software I've ever worked with: Plone (built on Zope). Plone takes advantage of the dynamic nature of Python to implement a great concept called acquisition. Think of acquisition like water in a container. Water is not something one thinks about as having shape. It is a fluid so it takes on the shape of whatever container it is in. Acquisition does the same thing to objects - if a property can be found on on object, it is used. If not, the same property on the object's container is used instead. Acquisition is not inheritance - the type of the object and it's container don't have to be compatible at all.
That's a relatively simple concept, but Zope takes it to the next level. You can change the properties on, and services available via an object by simply changing the acquisition context. For example, if you asked for /folder1/file1, file1 would pick up folder1's properties, but if you went to /folder2/file1, file1 would pick up folder2's properties. The acquisition context is built up dynamically, which means File1 doesn't even have to be inside folder1 or folder2!
This concept blew my mind. Acquisition, combined with a pure object database called the ZODB made the development experience pleasurable and efficient and left me with lots of time to explore the good stuff - automated testing using doctest and selenium, rich content management using the CMF framework, incredible server-client UI integration with KSS and jQuery (it was kinda new back then!) and one-step deployment using zc.buildout. I learned a lot about architecting software by working with Plone and loved every minute of it.
It was during this time that I really got starting digging content management systems. “No one needs to write a WebApp from scratch anymore”, I said to myself and started exploring some others (Django, Drupal, Joomla, even Wordpress) but nothing ever came close to offering the kind of richness and depth that Plone did.
There was another reason behind that dissatisfaction - I hated PHP.
PHP never felt like a language that was designed by thinking people. It felt as if a bunch of idiots got drunk over the weekend, wrote some half-backed scripts to open files and post forms and decided to call it a language (remember I was coming from Python, which is anything but poorly designed). It didn't help that almost all of the PHP code I encountered looked like crap and behaved like crap. The worst of these crappy behaviors was random PHP stacktraces and errors showing up on web pages in the CMSes I tried. These CMSes also didn't handle Unicode (because of PHP) and suffered from tons of security issues (based on what I read online because at the time I really didn’t understand PHP very well), a hundred different ways of customizing something and horrible, horrible coupling where every piece of code seemed to be in bed with every other piece of code. It was extremely ugly.
So I dumped PHP, vowing never to work in it again.
Fast-forward to a few months ago. I was evaluating a bunch of different CMSes for an eLearning site that would host documentation as well as streaming videos for the Kuali project at Indiana University. The university already had a flash media streaming server, so all we had to do was build a way to stream videos from that server instead of figuring it all out. Given that I know absolutely nothing about video, this was a big relief.
That’s when we found out that another group on campus was hosting their site on Concrete5. After we got to see an initial demo, I was impressed, but a bit skeptical. It just didn’t seem like it was ready to be used in an enterprise setting, so I decided to reserve judgment. An enterprise-ready CMS should have support for functions such as scripted installation and upgrade, excellent versioning, well-developed extension and customization hooks and most importantly, the ability to backup, restore and rollback changes within transactions. Concrete5 seemed to have these features, but they were all rough and unfinished. And the worst part? It was written in PHP. Ugh!
But then I did something that started me on a path I thought I’d never take. I installed it on my machine anyway, on top of WAMP. Hey, I was evaluating these things. I had to give it a fair chance!
To say that I was blown away by the ease of setup and use is an understatement. Everything worked the first time, I was able to install other packages (and uninstall them), add pages, blocks of content, change layouts, themes, customize the theme, etc. And all this without ever touching any configuration files or code. But I still didn’t seriously jump into the core code, because it was PHP. Besides, I was too busy figuring out how to setup the whole infrastructure regardless of which CMS we went with.
So I finally checked out our code from subversion, fired up Eclipse PDT, configured it work with Xdebug in WAMP, set it to break on first line, started the debugger and stepped through the code for the first time.
Wait a minute, what’s this? No random functions in weird files? Everything’s in classes? Small, properly formatted methods? Is that…could it be…the MVC pattern actually implemented without fat controllers?
I couldn’t believe my eyes. Either PHP in general had come a long way (true) or the Concrete5 developers really did write nice code (also true).
In my personal opinion (which is not very well informed when it comes to PHP), Concrete5 has some of the cleanest, most readable code I’ve ever seen. I spent a lot of time digging into the source, understanding how it was built (in this regard, I have to say, the API documentation sucks). Once I got into the source code, though, things Made Sense™. This meant that I, a Java, Python and C# developer could actually do some real work on this thing.
This is a big deal. It’s one thing to have a system that’s easy for end users to use. But making the source code itself understandable? That speaks of quality. Now granted not everything’s all rosy with Concrete5. It is lacking documentation, there is some magic involved in making the convention based resource lookup work (involving the PHP __call) that can make things difficult to understand , there are problems with error recovery (you have to do it all yourself basically), performance is a major issue and running multiple sites off the same code base is a challenge. But these can be fixed. The product is free and open-source, the community is knowledgeable and helpful and it has been proven to work in the real world, despite the issues. The experience with working with Concrete5 is, although sometimes frustrating, fulfilling.
So if you actually read this far and it’s not clear what I think about Concrete5, allow me to spell it out:
Concrete5 is the easiest CMS you will work with, as a content editor, designer or developer, period.
Concrete5 made me respect PHP again. And that is a guarantee for a bright future.