Is eZ Publish 4.0 like Microsoft Vista?

Disclaimers usually go at the bottom of a post but because this one is quite lengthy I've decided to put it at the top. Mostly the stuff I post here is of a technical nature, but this time I'm posting an option piece, and as such it is full of wild speculation, personal thoughts, suggestions and of course opinion, all of which may have no basis in any reality other than my own.

You are here - the current state of play

I've been using eZPublish 4.0 since the beginning of the year. It's not quite what I envisioned when the rumbling of version 4.0 first started, oh so long ago, actually it's nothing like what I imagined.

Hence the title of this post. Initially Vista (Longhorn) was slated as a "minor step" between Windows XP (Whistler) and Blackcomb. However it gradually took on many of the features slated for Blackcomb. People got excited, but it's release was delayed several times, the developers were given other priorities and finally development started afresh based on Windows 2003 server and a limited feature set.[1] When finally released the general consensus seems to be one of disappointment or at least significantly underwhelmed.

Over time there has been quite a bit of excitement of what a new version of our favourite CMS might provide. Given the quantum leap in functionality between eZ Publish 2.0 and 3.0 who knew what unimaginable ecstasy version 4.0 would bring! However time marched on, PHP4 end of life was announced and eZ Publish 4.0 became a port of eZ 3 to PHP5 (continuing the community effort by Paul and Kristof).

Now this is not a bad thing, on the contrary it's the best thing that happened to eZ Publish in recent times (including the Online Editor in the distribution would be a close second).

At the local PHP meetup I would get strange looks because I was still using PHP4. I could get people excited about eZ Publish but people soon lost interest when told that it required PHP4 and a specific version at that. No matter how good the product sounded it's was hard to get people interested about something that had "special requirements". "None of the other PHP CMS have those requirements" was the standard response. It was impossible to get a foot in the door. Hopefully now with PHP5 support more people will be willing to try eZ Publish.

PHP5 support also makes it easier to get eZ Publish into corporate environments. RedHat seems to be the Linux distribution of choice in the corporate world (at least here in Australia) and it's lack of support for php4.4 has meant that in situations where we were the "application provider" we either had to convince the systems people to install the newer unsupported (by RedHat) version of PHP or do it ourselves. Of course this just created a bunch of issues around support (of the custom PHP) and called into question the choice of eZ Publish as a CMS platform.

Oh yeah, eZ runs faster under PHP5 as well!

Three cheers for eZ4.0 on PHP5!

eZ Components to the rescue

I spend much of my time working with eZ Publish as a framework by coding extensions that merge existing data sources into a CMS managed environment as well as creating fully fledged applications that run parallel to the CMS. When I learned of the eZ Components project and that it would from the basis of the new eZ Publish version I was very happy.

There are a bunch of subsystems in the current version of eZ Publish that are tightly coupled with the main content module that makes them pretty difficult to reuse in custom modules. Two that come to mind are the Image system and the Rich Text/XML Block Datatype. It seems such a waste that these subsystems can't easily be reused outside of the content module.

From what I've seen of the eZ Components they will solve these type of issues. They will form the building blocks on which future versions of eZ publish are built. From what I can tell current version of eZ doesn't utilise components at all, although some of the components features have made their way into the eZ publish libraries. (Of course running under PHP5 allows the use of components in extensions).

New versions

The roadmap has the next point release, 4.1 (focusing on a new Online editor with support for IE7 for Vista) happening in Q1 2008. Given we are about half way through February that makes it due somewhere in the next month and a half.

Of more interest to me was version 4.5, with the focus points highlighting the integration of a new template & workflow engine based on eZ Components.

With a tentative release date of "Summer 2008" one would speculate that it is planned to be launched at the Summer conference. (Assuming that "Summer 2008" refers to a northern hemisphere summer, because we've in the middle of Summer, here down under. Come on eZ people, you're global!)

I do wonder what "Support for more runtime platforms" refers to?

Better, Faster, Shinyer or a Monster?

In terms of version numbers I'd like to see the version that incorporates eZ Components go up a major revision number and become eZ 5.0. This would signify the gravity of the change. We are not talking about some bug fixes and enhancements here, but replacing major components.

I'd even go so far to suggest that eZ4.0 goes into maintenance mode (feature freeze, whatever you want to call it) and eZ5.0 is written from scratch, built on eZ Components. I fear an eZ Publish that has it's underlying systems replaced bit by bit with eZ Component versions will quickly start to resemble a Frankenstein's monster.

The current system has been through ten major revisions and countless minor ones and is quite stable. I suspect there be teething problems if not major pain (but as the saying goes "no pain no gain") for many with this change. And of course the entire admin and various default user interface will have to be rewritten for to work with the new template syntax.

I suspect that given the current templating system is tied to the caching and translation systems (part of eZ Components 2008.1) that we'll also see those replaced with eZ Components ones as well.

Also of interest was Derick'spost earlier this month about the eZ components 2008.1 roadmap. The majority of the listed new component and enhancements appear to have a specific eZ publish focus. These have tentative alpha & beta release dates in May 2008. This would make a tight squeeze if eZ 4.5 (eZ Components) was to utilise this eZ Components release. Does this mean that eZ 4.5 would not have Translation & Character set support?

So what do you think?Is eZ publish 4.0 like Vista?Do you want to see an eZ publish that is half components or a ground up rebuild?Do you care? ;)

Thanks for the comment! You bring up a point that I didn't touch on in the post, money and the commercial aspect of eZ. I certainly don't begrudge eZ making money, and as a user of their software and someone who makes a living working with it I hope they make as much as possible so they can continue doing what they do!

I'm not sure I agree with your point about the step-by-step approach enhancing the image of eZ Systems. In the end though, the proof will be in the result. As I pointed out in the post I don't see the merging as a trivial task and suspect it will have implications. I suspect that eZ will be able to pull it off, the question I'm putting forward is whether it's the best long term solution.

With my developer hat on I know that it's a lot more fun starting from scratch armed with a great new library and the lessons of the last project.

BTW - I after looking more closely at the template component I suspect that existing templates will be OK. I don't see the old {section} tag there so this will mean that the older legacy templates will require a clean up.

you're right off course. There most certainly will be trouble in paradise as the new pieces are put into the puzzle.

When it comes to the new template engine, I'm really looking forward to it. It will boost speed, and that being added to the php5-effect (especially the XML-parser) will be a doble-boost for ezp-performance.

I image there's been quite a few arguments over at the eZ Bunker (aka eZ HQ) concerning the 4.0-approach. One can only hope that they made the right decission and, even more important, that they wil do their very best to make the transission as smooth as possible.

In the preface to the current Admin interface specification the last paragraph caught my eye:A overview of user task need a dashboard, where she can follow here own content, approval and other tasks she might do on a regular basis.I recently saw a demo of the latest version of the bug tracking system JIRA 4.0 by Atlassian. It used an OpenSocial dashboard to allow users to customise their homepage to access and interact with information that was important to them. The system not only displays JIRA widgets but any OpenSocial widgets (and those from other Atlassian products). You can check out a video of it in action here and more information on how Atlassian is using OpenSocial here.

What is OpenSocial? From the official site:OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML,
developers can create apps that access a social network's friends and update feeds. Google personal home page is an example of an OpenSocial da…

The following presentation was given on 24 July 2012 to the DevOps Brisbane group. Some of the technical detail about Vagrant is outdated but I think it provides a good overview of why moving to a "Infrastructure as code" setup makes a lot of sense.