Join GitHub today
I’ve worked on various big content engagements, and I’ve talked to a lot of number of people with more big-content experience than me. And people agree that big orgs, even if they now have content problems, won’t hire editors, or enough editors, to manage their content. Think: museums, non-profits, giant corporations, government. I get very sadpanda when I see someone spend $500K plus deployment, development, and licensing costs on a Java EE-based multilingual platform incorporating a JSR-238 repository with a custom workflow/process approval engine. Because they could build out something for about 20 percent of that (or sometimes 1/2 a percent of that), and hire a few editors to wrangle the content. The content, were it approached strategically, could be of far higher quality—-better SEO, more durable, consistent voice, vetted for legal compliance, primed for re-use. And you can make an end-run around workflow if you add versioning and reversion capability to your text fields (like Wikipedia), give most users the ability to edit, and give the editor full revert and publish privileges. Most CMSes are parasitic technologies dedicated to preserving the cultural and hierarchical status quo of their hosts no matter the cost, literally. People hear me whine about this and they say: Our case is different; we need to have a system that sends out seven thousand “todo” emails per day. And I grieve for the spirit of Work, killed by her evil child, Workflow.
I like the idea of being compatible with JCR as long as there is no reliance on using non PHP solutions such as Jackrabbit. Therefore we would need to create a JCR compatible storage component. This would be attractive to enterprise level organisations who wish to put a PHP frontend on an existing JCR based system. However, we also need to support smaller implementations that just want to use PHP and Doctrine. This would also allow for the creation of alternate storage systems using Propel, Mongo or web based APIs.