So the other day I was ranting on twitter that there are very few contributors for Symfony CMF. Actually I should qualify this. Surprisingly we have quite a few people helping on the low level architecture pieces like PHPCR. For the inline editing the IKS project is ensuring a healthy doze of development pushing [create.js http:://createjs.org] etc. But on the Bundle level there is very little happening. This to me is quite puzzeling since thanks to our sandbox and the fact that PHPCR ODM for the most part work exactly like the ORM and Mongo ODM, any Symfony2 developer should feel right at home. Lets ignore for now the classic response of "no time", people replied pointing out various reasons like maybe A) the community just need something simpler, B) Drupal and ezPublish are already providing what they need C) they have already developed something RDBMS based in house because the CMF wasn't ready or D) there isn't even documentation to get started. So let me quickly respond to each point.
A) No doubt if all you need is a couple of pages (like an about page and a legal disclaimer) then any CMS solution would be overkill. At the same time throwing together a RDBMS schema to handle such needs is easy enough (if it even has to be RDBMS). Now what to watch out for though is if needs start to grow. Like suddenly you need to also do versioning and then add a few subpages etc. So carefully examine the long term needs and then consider if to invest into the future. Building on the CMF might give you some features for free that you otherwise might forgo. Furthermore the Doctrine DBAL implementation is solid enough for those simple needs, but actually running Jackrabbit for this is also quite simple: all you need is the JVM, download a jar and run a single command to have Jackrabbit running and storing content into the file system.
B) ezPublish will come out this fall, but the bulk of the content management will be inside the old ezPublish 4 code. It remains to be seen how good the integration of their content repository will be to enable using the content from Symfony2. I would be surprised if they will also implement the Doctrine persistence API. They will of course continue to push forward. Similar Drupal 8 still has a fair way to go. They plan for a feature freeze in december, code freeze in spring and a final release in the late summer. So its not like any of this is around the corner. Finally neither will be as "cleaned up" for truely custom CMS needs, but both will provide more out of the box features than the CMF will offer by the end of 2013.
C) If you already went ahead and developed your own CMS on top of Symfony2 than so it goes. If you think you can today sit down and quickly implement an RDBMS based schema, then I think you would be wasting your clients money. The Doctrine DBAL implementation is mature enough to be viable today. The main missing piece is full text search support either via an RDBMS or via Solr/ElasticSearch. Each feature should be implementable in about 15-20 man days .. less time than it would take you to try and come up with a schema of your own, which will be much more limited in capability
D) I think this was the most mentioned point and the one that I personally also feel is the most "valid". Indeed documentation is very sparse. That being said, anyone that bothered to come into the IRC channel or ask questions on the mailinglist got personal support within hours. Freddy's success shows that it doesn't take a lot of time to become productive with the CMF. But of course this doesn't scale and it also requires too much effort for those doing a casual review of the available options. We did actually have some docs and so I finally set up rendering of these docs. I also did a big update to migrate the installation instructions to composer and added lots of links to related documentation. So while there is still a lot to do, there is now instant gratification for anyone that helps writing docs.
*Update*: One more about complexity I forgot. PHPCR is certainly not trivial, but neither is Doctrine ORM. But if you try and understand the storage API of Drupal (and likely also of ezPublish) you will find it to be much more complex and less powerful than what we have done with PHPCR. Thanks to a clean architecture we are in fact seeing lots of contributions to the PHPCR layer. So when people say that the Symfony CMF is too complex for them to write Bundles for, then well I am not sure what I am supposed to tell them, because all this complexity is hidden behind an API that is tons easier to use for a CMS than trying to create your own CMS storage on top of the ORM.
For me i it because i can't see the reason for PHPCR / Jackrabbit and running a Java server for content. Also i think the CMF space is rather well covered with Drupal 8 being Symfony2 and hopefully eZ Publish aswell (if eZ Publish aren't going to ruin it). Sure some of the Bundles have use cases outside of CMF but that is mostly as integrated pieces in other "large" projects like Vespolina or Sonata as i have not had a need for a Chain Routing system at work or in my personal projects yet.
@Henrik: Which part of my post gave you the impression you need Java? I keep explaining that 1) installing jackrabbit is easier than any RDBMS deamon, but 2) we have a pure PHP implementation on top of Doctrine DBAL.
But that is fine, you are in the B) category, if you are willing to wait and are ok to accept all the legacy troubles that these systems still have, then the CMF will not be able to compete on features. Interestingly enough both will be using parts of the CMF to get their work done :)
@Lukas you are saying that you have a pure PHP implementation on top of Doctrine. That is *mostly* correct, if i remember correctly you tweet about the differences, and some of you tweets end with something like "hopefylly the dbal layer will have it soon". That might be correct that installing it on a single machine for development might be easier, but if you go into production with it you have to understand how it works, how to scale it and so on. I dont even think i know anybody how is fluent in hosting java stuff. And personally when i have tried to get Kestrel or Lucene going on my machine it implodes badly.
And for the record i really really hate eZ Publish.
my main reason for not using cmf is that the projects we build all use propel and not doctrine
@Henrik: Not sure if this is the reason why you hate eZ Publish, but afaik they recommend using Solr for full text search. Both Solr and ElasticSearch are really the go to solutions for this so its kind of hard to escape Java. The only alternative is http://sphinxsearch.com which afaik requires a custom MySQL build.
But yes, the Doctrine DBAL implementation doesnt have all the features, the main missing one is full text search which is being worked on as noted in the blog post. I will try to add a table showing the differences in available features for each of the implementations to http://phpcr.github.com.
@ulrik I agree with you, though not with exactly the same line of reasoning. I think every bundle (package, module, whatever) should be able to choose their own persistency layer inside a CMF (like you would assume from a framework).
Developers used to propel must get the same capabilities as the developers using doctrine. The right tool must be used for the right job, so if you need an RDBMS (if it's PostgreSQL, MySQL or SQLite) or something else (CouchDB, MongoDB, Cassandra, Redis, Riak): the application logic prescribes the type of persistency. It's not something the CMF must prescribe for you.
This is also the reason we are now experimenting with a custom CMF setup and watch the development of Symfony-CMF from a distance.
@Jurian/@ulrik: We are doing the best we can to enable different persistence managers: f.e. RoutingExtraBundle was developed to allow dynamic routes, we simply implemented PHPCR ODM compatible models, but we specifically aimed to enable other persistence layers.
But seriously, we have limited resources, how in the world can you "watch from a distance" because you are missing support for every NoSQL database under the sun?
Finally you don't seem to realize that PHPCR is a storage API that can be implemented on top of any of the databases you listed. That is the key point of PHPCR, to enable a clean separation between business logic and the actual persistence layer.
At any rate .. I urge you to checkout RoutingExtraBundle and our Routing component. Drupal8 will be using the component. The eZ Publish guys will likely use the Bundle.
I would like to add one point point:
People dont use CMF although for simple CMS development because of the production hosting offers.
If you take a look at all hosting services (OVH, 1&1,...) they're all about PHP and MySQL.
And they have damn fast MySQL servers (they are not scared of a Drupal high traffic website)
Something not known to run on these wont be used.
@Rakotomandimby: Right .. which is why we have the Doctrine DBAL implementation. If you look at our demo the only thing missing to run exactly the same site on SQLite/MySQL/PostGreSQL is that we still need to finish the full text search for this page. Everything else works already.