planets

links

buttons

It feels like every minute a PHP developer somewhere on this planet starts implementing something aching to a CMS from scratch. Some do it because their project is "so big" it that it "obviously needs" a custom solution. Some do it because their project is "so small" it "obviously needs" just a few days of hacking .. to build a custom solution. Let me briefly focus on the later group. Working in a company with less than 10 people building websites for customers a project needs a bit of a CMS to manage those 10 "semi static" pages seems to be the poster child example of this group. The devs whip up a DB table, slap an ORM in front, maybe even use some generator for the admin UI. Done. Later the clients also wants versioning and luckily many ORMs provide some solution for that. Easy. Permissions? Most frameworks provide some ACL system. Child pages? ORM has some tree algorithm supported. Fulltext search? Integrate ElasticSearch. Custom page types? Uhm well by now you have enough sunken costs that you will make that happen somehow too. Some morning you wake up and you have created the next Drupal or Typo3. If you did, then it would be hard to claim that you did it wrong because both are very successful projects. What PHPCR aims to be is to provide you with a short cut for this path. Or in other words there should be a PHPCR implementation that is so easy to use, with so many helpful higher level components in your favorite framework, that it becomes the natural choice for your next CMS needing project.

Every time anyone talks about PHPCR, they will mention Jackrabbit sooner or later as it is the basis for the currently most mature PHPCR implementation. Here, I just did it too. Jackrabbit requires Java. More importantly it is not trivial and most of you have never heard about it, let alone used it. I think for many high scale use cases its great that PHPCR has been integrated with Jackrabbit, but it needs to be relegated to a side note you mention when someone starts talking about scaling to millions of documents and many GBs of data. Once there is a PHPCR implementation that works with pure PHP, using any RDBMS (including SQLite which is bundled with PHP) it will become easier to just use that instead of whipping up your own tables. No more convincing the sys-admin guy about adding a new daemon to the setup. Instead being able to tell the client what other features they could get in the next code sprint.

So today, we are not there yet. We have an implementation of PHPCR that works on top of Doctrine DBAL to in theory support any RDBMS. Well in reality it already does though the search API only works with MySQL and PostgreSQL. It also doesn't support versioning and ACLs. Oh and if you drop more than 50 documents into it, search performance will start to hurt quickly. Bummer. But there is good news too. The core infrastructure is laid out thanks to Benjamin. Progress on it, while not rocket fast, is continuous thanks to Liip intern Adrien .. as a matter of fact if you go to our demo page it would run all but the admin interface on top of it just fine (yes this includes the cool inline editing!).

I believe that a decently experienced database developer would need a man month to fix up the searching to perform decently unto lets say 1k documents as well as implement simple versioning on top of SQLite. Another 2 man months should enable implementing permissions and support for even more documents, ACLs and a few other goodies. Is this something that a 10 developer company can commit to when offering that simple CMS solution to one of their customers? Obviously not. This takes a few developers who are willing to invest into the future. Until they come along unfortunately PHPCR will continue to not be a viable option for many small CMS projects.

Update: In this post I failed to mention that there is also already a pretty solid implementation of PHPCR written in C by the Midgard team. However just as a Java solution can't be our pitch, I believe that a custom extension cannot either.

It should be noted that a PHP C extension is still a lot easier deployment requirement than whole another Java process. And Midgard is now available in Debian and Ubuntu (from 12.04 LTS onwards), so getting it installed is usually only a apt-get away...

We haven't implemented the PHPCR API, but we've been using a pretty decent hierarchical content repository in Ariadne ( http://www.ariadne-cms.org/ ) for some 14 years. It has decent performance up to a few million objects. It doesn't have workspaces yet, but we do have a lab version that does - still a work in progress though.

Perhaps we could combine our efforts, although I'm not charmed by the verbosity of the API... :)

@Auke: Cool. It should probably be quite doable to at least write a transport implementation for Jackalope to support your content repository API. This is for example the implementation that provides the integration with Jackrabbit while this is the implementation for Doctrine DBAL. If we did something like this for Ariadne's implementation it could give us a mature pure PHP implementation.

Well, started to create a phpcr implementation around Ariadne's store, but it's not going to be pretty. One of the things is that Ariadne hasn't migrated to namespaces yet. Fortunately the store is first on our list to refactor and update to PHP 5.3 and namespaces.

For now I'm rather hacking the thing together, learning the structure of the API as I go. Not sure how far I'll get :)

I live in enschede, which is about 2 hours away by car from Amsterdam, so its not exactly next door... also I'll be on holiday untill june 9th so I don't think I'll get much work done on phpcr and ariadne in the mean time. Let's see how it goes :)