Monday 14 March 2011 12:34:20 pm

Thanks Marko for this write-up ! I like the approach of trying to identify general-purpose criteria for a CMS choice, and confronting both solutions against them.

Brilliant conclusion, by the way :)
Cheers !

--
Nicolas Pastorino
Director Community - eZ
Member of the Community Project Board

eZ Publish Community on twitter: http://twitter.com/ezcommunity

t : http://twitter.com/jeanvoye
G+ : http://plus.tl/jeanvoye

Tuesday 15 March 2011 2:56:01 am

Hi Marko,

First of all, thanks for your insightful technical evaluation of eZ publish and Drupal. I have recently spent 2 days on comparing eZ publish and Drupal as well, but with a focus on comparing the differences between the ecosystems and code base.

Ohloh.net asks the question what the project costs would be if you hire a team to write this project from scratch. For Drupal this would take 43 person years or approximately $ 2,363,881. For eZ publish it would take 113 person years (code only), or approximately $ 6,238,321. Looking at the code, Drupal has about 127260 lines of PHP code, and eZ publish about 223737 lines of PHP code. Looking at all types of code, Drupal has 142865 lines of code and eZ publish 561385 (see http://twitpic.com/47glq5). So eZ’s code base is much bigger than Drupal's. However, it we look at extensions (eZ publish) or modules (Drupal), we get a different picture: For eZ publish, there are approximately 1124 extensions available. For Drupal there are 7557 modules available.

Without jumping to conclusions, this raises a number of interesting questions: is the Drupal community more successful in contributing code, or do users/developers have difficulties in getting Drupal to work the way they want? Does the standard installation of eZ publish require the abundance of functionalities, or should some of these be moved to community maintained extensions? Is the size of the code base an indicator of effective coding or a lack of focus? Is the number of extensions/modules related to effective community mobilization, or to the code architecture of the system? Is there any relation between the size of the code base/extensions/modules and the learning curve for a system? How do the developers that use eZ publish differ from the ones that use Drupal? There are many more questions that can (and should) be asked, and in my opinion answering those is vital to the understanding and strengthening of the eZ ecosystem.

The two companies that based their business on these CMS systems, eZ systems and Acquia, seem not to have fared with an equal amount of success. As eZ systems launched yet another business model, based on the distinction between a community and enterprise edition, Acquia launches Drupal Commons and Drupal Gardens (a hosted Drupal solution). Drupal Commons is social business software providing organizations with a complete solution for forming collaborative communities. It combines popular social web features for users and community management tools for site owners. In my opinion there is still no successful, out-of-the-box community solution for eZ publish (not even Teamrooms). According to Acquia, "Drupal Gardens is a hosted version of Drupal so you don't have to worry about installation, hosting or upgrading. Think of it as Wordpress.com or Ning, except that it comes with the power of Drupal. Equipped with multi-user blogging, commenting, forums, custom content types, and advanced user management, Drupal Gardens should be a great tool for organizations that want to build social sites." Drupal Gardens, which has been launched just over a year ago, already hosts over 40.000 sites.

Assuming that Marko’s technical evaluation is correct, there are a few questions to be asked. First, what explains the success of Drupal’s ecosystem? Second, is there an opportunity to make eZ publish as popular as Drupal, or is eZ publish a CMS in a whole different league? Third, if the quality of the code architecture does not matter to so many Drupal users, than what is the decisive factor in choosing Drupal? Fourth, has the eZ publish CMS maybe become too complex, and the learning curve too steep for the 'average developer'?

Again, there are many more questions that arise in the comparison between the Drupal and eZ publish ecosystem. In my opinion the eZ publish CMS deserves a proper answer to these questions – the whole eZ ecosystem will eventually benefit from it.

Looking forward to your comments,

Sebastiaan

Certified eZ publish developer with over 9 years of eZ publish experience. Available for challenging eZ publish projects as a technical consultant, project manager, trouble shooter or strategic advisor.

Tuesday 15 March 2011 3:43:15 am

Interesting post thank you.

I had a great deal of experience trying to keep a Drupal 5 site serving 3 million pageviews a month and ran into a lot of problems with SQL queries in the Drupal core that became very slow due to the fact they weren't at all scalable once the number of articles became very large due to the number of joins and other problems.

Jon

Tuesday 15 March 2011 4:24:39 am

@Sebastiaan

eZ publish isn't pop because it is known to be hard to install on shared hosts ( Ok, I have one installation at hostgator, but I made some workaround to get it working ).

Drupal can be installed on every crap server, and the average blogger just want a server to handle a few thousands pageviews / month.

eZ Publish Certified Developer: http://auth.ez.no/certification/verify/376924

Twitter: http://twitter.com/tcv_br

Tuesday 15 March 2011 4:37:44 am

I tend to find that different frameworks & CMS have their strengths and weaknesses, and hence suit themselves to different projects, people and teams. I also find that getting my head round a new system, and the patterns they use, is often quite difficult. I think the article has stumbled on a few of these, and is thus inaccurate.

You should never be thinking about putting a query into the templating system in Drupal. Contents of the page should be passed to the templating system, not created there. Drupal has had to work hard from a start a long way back to make a friendly templating system for non-php-developers. But have a look at Morten's presentation linked from http://morten.dk/blog/awesomeness-redefined-drupal-7-theming-0 it's all variables with the occasional hide() and render() function.

I'm not sure what the use case for the display 10 articles sql was in the template suggested above. Generally your article lists would be supplied by the appropriate module, maybe you're writing one yourself. To see how it would be done we could look at the code of the blog module http://api.drupal.org/api/drupal/modules--blog--blog.pages.inc/function/blog_page_last/7 again doesn't look anything like the statement above. It's ending up with a render array it can then pass to the templating layer above.

Alternatively you would be using the views module http://drupal.org/project/views Some of these http://www.drupalove.com/article/100-drupal-views-tutorials-and-resources might give you the idea.

So that for the example with actual substance. The rest is a bit more conjecture. How much OOP is often just a religious discussion, myself I tend toward oop patterns more than less, but it is PHP and in the words of Rasmus Lerdorf 'in Drupal 7, “you guys have gone almost overboard on OO”' http://drupalradar.com/liveblog-rasmus-lerdorf-drupal-performance

Similarly I'm not sure for example what the problem with the database abstraction layer is (see example of it at work in link above in the blog module). Except that it's creating yet another PHP database abstraction layer, but we all want it just so don't we.

On that note, before I finish, schema kept track of, indexed in install files etc. http://drupal.org/developing/api/schema If you want to see it in the UI even you can http://drupal.org/project/schema

Tuesday 15 March 2011 6:07:23 am

You're right Thiago. But let's think in what you would need to make that extensions compatible with 4.5 (s/templateInit/eZTemplate::factory/g) and what you would need to make your custom module for drupal 5.5 to be compatible with drupal 6 or drupal 7.

If i'm not wrong, even the more powefull (and really cool btw) drupal module (views) was totally rewritten from drupal 5.5 to drupal 6.

It's just i'm not agree with http://drupal.org/node/65922 at all.

so, you start to work for a company with drupal 6. you add lot of custom modules to it. and maybe, when you are near to go live, drupal 7 appears. and the customer probably will be like 'hey, drupal 7 is out, why not use it?'. and you probably say... 'because our modules are not compatible' - 'that's not my problem, man...'

you can have the same with ez publish, ok. but i think that situation would be solved easily.

in other words, i started projects with ez publish 4.2 and in the time of going live, core was 4.4. none of our custom code needed to be tweaked...

the buddy module was only a little example. sure it does more things, but sure they can also be done with ez publish (with more or less job, ok). but the good thing is what you built today, probably will be working perfectly two years later.

and with core changes, some of them intended to improve perfomance and whatever... but still taking older code in account.

Tuesday 15 March 2011 8:35:28 am

For something like that normally I would create a custom content type, adding the appropriate fields. That's Drupal core. If you need something special there are lots of additional field types - they are in contributory modules. For per field level access control there is also a contrib module.

Then I'd use views to create the display of it with required fields for that page rendered in which ever way is appropriate and ordered however.

So yes you would have to install a couple of modules, but that's the Drupal way.

Tuesday 15 March 2011 12:42:39 pm

Ok, some appologies to the Drupal fans (but only some, not all)...

It seems that the template system in Drupal is not so bad as I got the impression (see chapter "2 - Template system" of this blogpost). When doing this analysis I was mislead by some of Drupal modules that were made that way and some of Drupal "experts" that told me "that's the way Drupal works".

Also, at the time of writing this analysis Drupal 7 was not yet released so our efforts were concentrated on Drupal 6 (being the only stable version that we could rely on). Since I didn't quite follow Drupal's progress since then I apologize for any misinformation in this conclusions.

Now I've investigated a little further (many thanks to ekes for pointing me in that direction) I found that a lot of improvement was made in Drupal 7:

• http://api.drupal.org/api/drupal/CHANGELOG.txt/7

I'd like to point out few of them I find most important:

• Database changes (completely rewriten database layer)
• Many changes in "Theme system"
• New Field API featuring custom fields

Probably some of this functionalities were already present before as custom modules, but it's an important fact that now they are part of the Drupal's default instalation.

So I'd also like to give some congratulations for this great improvements. Well, it did took you 3 years to make it, but now I would say that Drupal can be compared to eZ.

But there's still the fact that Drupal implemented only recently some concepts that were in eZP for a long time (more than 7 years now). So I still believe that eZP is way ahead of it.

And in the new eZP release coming out soon I think we'll find a lot of things that Drupal hasn't even started to develop.

--
Nothing is impossible. Not if you can imagine it!

Hubert Farnsworth

Thursday 17 March 2011 4:58:54 pm

I enjoyed reading your article (which seemed just a bit bias to me) and while I am finally making peace with the Ez Publish CMS I could see where performance of Ez Publish coud be easily slammed by enterpise developers.

Now before I get nailed to the cross let me say that many of the issues with EZP were resolved by our team when implementing it with our site www.aquariuscasinoresort.com , for instance at first we experienced very slow page delivery while using custered servers. However this issue did not seem to pleague us when we dropped the clustering.

Another annoyance that we found, and probably is contributing to EZP being met with negativity from others, was the vagueness of suppport when trying to address certain bugs.
For instance, Our server was already configured with PHP in CGI mode and when we tried to find a solution here, as many others, we we met with what seemed a standard answer, "Ez Publish does not work well with PHP in CGI mode, recompile your PHP."!!

It's only my 2 cents worth but it is just bad for to tell someone to change their server in order to use your product. I would suggest instead that either patches or workarounds are posted OPENLY in easy to find areas of the support community.
BTW, I did make a post in the Install & Configuration forum detailing the workaround solution I came up with to help others in trouble with this issue also.

Microsoft gets away with telling the world to change their stuff to match their whims because they have the world running in the palm of their hand (FOR THE MOMENT), but the Open Source community should always strive to hold itself to a higher standard.

Some of the issues in the forums were repeating our troubles over and over and receiving what seemed to be shot in the dark attemps to resolve.

I realize that this is a developement community and I would like to thank everyone for all the hard work in bringing EZP to fruition as a viable CMS which can hold its own in an enterprise environment, but I think it is important to recognize that OOP is not the end all to be all, neither is Procedural, but both have their places.
EZP does have some serious performance issues that can be tweaked out of it as we have done for Aquarius, but my point is they need to be worked on without bias, something we all are guilty of from time to time.
Finally I would like to add a suggestion; Add a section to the documentation for work arounds to allow EZP to be compatible with a wider range of server setups and perhaps one to suggest tweaks to boost performance (one may exist that I just havent run across yet), it isn't impossible to get it to play better with other server setups.

You have a great product here and being more user friendly can only help you achieve the ranking and recognition you deserve.
Thanks for EZP

=MANTA=

The past is past and cannot be changed, while the future is shaped by action taken in the present.

Sunday 20 March 2011 12:20:57 pm

I found eZ publish in 2004 at http://cmsmatrix.org. I ran a query with the requirements for two sites that were being built and the ONLY system returned was eZ. I built the sites on eZ and began using it for other projects.

In 2007, I tried to compare eZ publish with Drupal by building the foundation of a system.

The primary system requirements were:

• Ability to create structured content (custom classes)
• Include flexible content options
• Allow a widely distributed organization to post content
• Allow high traffic
• Have nice SEO friendly URLs

I started with Drupal, since I was more comfortable with eZ than Drupal. After installing the core Drupal code, I had to install many additional components to meet these requirements. I was immediately concerned about version conflicts between the core and compenents, the variation of quality and documentation, and the ease of future upgrades.

I began building the system and found it very awkward. A lack of experience can explain some of the awkwardness, but it seemed as if everything was more difficult than necessary.

After two weeks, I had met the core content requirements, and decided it wasn't worth further pursuit. In 2 days, I was able to build the equivalent solution with eZ.

With eZ, the initial installation provides virtually every feature needed for a CMS, and you can extend it if needed.

Key Advantages of eZ

• Documentation
• Ease of installation
• Content classes - creating custom content classes makes it easy to represent the data well, and produce higher quality sites
• Roles and permissions
• Hierarchical template organization - makes it easy to display content consistently across the site, reduces duplicate code
• Multilingual support
• Design flexibility - I like to use the sitestyles delivered with eZ, but you can also create completely custom template systems. It can look any way you want it to.
• Access control - URL, hostname or port. It is easy to restrict access to the admin URL
• Efficiency - the caching greatly improves performance, and it can be customized to meet additional requirements
• eZwebin
• Multisite installation - the same eZ installation can support multiple sites
• Upgrades - I've done many upgrades, and the scripts, documentation, and support have always been excellent
• Community
• Paid support