PhpRiot
News Archive
PhpRiot Newsletter
Your Email Address:

More information

So what is the CMF good for?

Note: This article was originally published at Planet PHP on 31 July 2012.
Planet PHP

The last blog post was just notes on the feedback I got as a reaction to a moment of frustration on twitter. People had asked me to summarize the feedback and this is what I did in that blog post. But I realize now what is more relevant is that the CMF team needs to more clearly explain that we are not trying to go head on against the likes of Drupal, Typo3 or ezPublish but why our work still might matter for to others. The people that are interested in the CMF are developers that have realized that while they have needs to maintain dynamic content on a website, none of the current crop of CMS solutions were really a good basis to solve the needs of our clients. Drupal and friends provide a bazillion features and if your clients for the most part simply need a subset of these features, then by all means use one of these CMS solutions as you and your clients are not in our target group. Obviously we would love it if we could also provide these bazillion features, but realistically it would take us years to catch up. We see our target group among those where their clients need isn't a subset of the offered features; rather where it is necessary to do a custom implementation of the bulk of the features. Today any project that has "content management needs" is build on top of some CMS even if they don't deliver any of the key features. As a result the final solutions end up bastardizing these CMS, creating a lot of pain for the developers and needless constraints for their customers. We want to be "disruptive technology" in the way Clayton Christen described in his book the Innovators Dilemma.

So what does this mean? We want to offer a solution for those developers that need to create a custom CMS solution for their customers. Again to make it clear I am talking about customers who needs are not a subset of existing CMS solutions. As a matter of fact this is why we decided to call it the Symfony CMF initiative and not the CMS initiative. So rather than trying to mold these ideas into an architecture that made lots of assumptions to optimize for other needs, we want to provide the very basic building blocks that we believe is common for content management, i.e. a content repository supporting versioning, tree structures, references and schema management via node types with a tool chain to expose this content to UI's via a clearly defined API. We believe that with these tools available combined with the power of Symfony2 is going to be a faster, more reliable path to creating custom CMS solutions with less legacy baggage for customers to accept. So when people wonder why I keep talking about low level pieces like PHPCR and RDFa then its because I believe that to build a custom CMS solution you need to know these layers. But contrary to legacy monolithic CMS solutions these layers have clearly defined API's that even support your use cases, rather than constrain and complicate them needlessly.

If you feel like being able to interface your custom code with such clean low level API isn't something you need, then again I fear that you will be happier with more established CMS products rather than what we are offering with a content management framework. But for what I see the reality is that many people are stuck in a place that can probably only be explained with stockholm syndrome. Thing that should be simple like migrating content between development, staging and production should be easy. It should not require some hackery to map auto increment values. Being able to hook in a custom UI shouldn't require forking some module, it should just mean coding against a defined API. There is a reason why we are using Symfony2 rather than hacking our needs into some finished product. The users of web frameworks believe that its more effective for customers to build them a solution based on a web architecture, rather than onto the constraints on a product. We want to provide the same for the world of content management.

Now I totally understand that without a stable release, tons of documentation, tutorials and several top of the line success stories from various different companies it is quite a big investment to turn your development model upside down: i.e. rather than spending your time molding some CMS that doesn't do what you need, but that you have come to know well over the years, into what you do need .. that suddenly your development starts and ends doing exactly what you need. For those of us who are working on the CMF today, the pain with these legacy systems was enough that we felt it was necessary to formulate a vision for a better future and invest the time to make this vision a reality. If you do not share this vision then maybe the pain isn't big enough, which is great for you .. because it means todays CMS solutions are already doing what you need them to.

Now I want to do a final word on Drupal 8 and ezPublish 5. Maybe if these products would be finishe

Truncated by Planet PHP, read more at the original (another 2193 bytes)