eZ Community » Forums » Discussions » eZPublish vs. Drupal
expandshrink

Monday 14 March 2011 7:26:13 pm - 23 replies

» Read full blog post

Introduction

I have encountered a big deal of discussions abut eZP vs. Drupal, all of them stating different facts and opinions. So I hope this will shed some light on the topic...

Monday 14 March 2011 8: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 happy.gif Emoticon
Cheers !

Tuesday 15 March 2011 10:53:07 am

Thanks Marko.

Really interesting piece, I love the Whitehouse comment, A US Partner should give them a call.

You know, more I read, the more I see: eZ Publish has got it right.

But, lets not rest on our laurels as we now need to take on the Vignette, Methode & OpenTexts of the world.

Tuesday 15 March 2011 10: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

Tuesday 15 March 2011 11:35:36 am

There is one fundamental difference between both communities, that easily explain the difference in amount of extensions: the eZ community is currently still more a professional one than Drupal, due to in my opinion two reasons.

The first is the eZ learning curve, still steep. Drupal ain't that easy to master, but it is easier to get into. The result is that there are many more small, very down-to-earth extensions, and a good part of them are technically very debatable... Getting into eZ is more complex, and limits the amount of "noobs" in the community. We (eZ) are working on that aspect, even though our goal isn't to get more noob questions, but to make it easier to get into eZ.

The second is the professional aspect of the community. Many active members are working for integration partners (not all of them !) and therefore don't have the same sharing options as pure community users. Most of what they do is a) not release quality, due to time issues b) "licensed" to the partner, and facing cost issues, since time & money have been invested in most of these devs.

I have lots more to say about the other topics, but not enough time for it right now. I'll step in again soon !

Tuesday 15 March 2011 11: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 11:51:06 am

@Sebastiaan, @Marko: here's my take:

1. eZ is definitely too hard to learn before you get productive.

Most php developers would rather code a feature from scratch in php (hey, they're PHP developers!) than learn how to use the same existing feature, if the learning time is above epsilon (for very small values of epsilon).

2. with eZ is definitely too easy to build something that does not perform / scale

In fact I'd say that doing templates that have bad performance and bad cache dependencies is the norm, with optimized templates only achievable with great experience and care.

If you look at history of IT, worse-is-better has always won, with windows overtaking unix, and wordpress becoming synonim of blog (with a horrible, horrible code base).

All the rest, the better patterns, the vastly inferior number of exploits, the code QA really matter less.

So what to do to improve the status quo?

- slim down the kernel: remove modules that are not really core content management (eg. rss feeds, webshop), use a different template engine and a lighter mvc infrastructure

- improve diagnostic and development tools

- more docs

- community buzz ?

All of this is known to eZ Engineering, and slowly but steadily happening. Watch out for 4.6, big things boiling in the cauldron at the moment...

Tuesday 15 March 2011 12:24:39 pm

@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.

Tuesday 15 March 2011 12:35:41 pm

I agree with all your points. but let me add something eZ Publish wins. It's the bc changes. Sebastiaan says "For Drupal there are 7557 modules available.", but only about 1200 of that are compatible with the last drupal core version i know (7.x).

We haven't done really big projects with drupal, but i think i can say we've done small-medium problems with it. and we did custom modules. but the thing is we cannot use those modules anymore without rewriting.

i know some cases where same site has parts of it using drupal 5 and some other parts using drupal 6.

And regarding to database thing. well, normally with ez publish you start with about 120 tables. we've done big projects with ez publish and at the end we have probably 130 tables because custom modules.

when i first installed drupal i remember about 50 tables in the database... when we finished that small project, we had nearly 250 tables...

and about the contribs. well, yep. they are lot of them... but sometimes they add functionality to the core, functiontality that eZ Publish has by default (i mean, buddy module is no more than relations between objects, for example).

I fully agree with Bertrand about community contribs. we have done cool modules here... but probably they're too specific modules and only for our needs. that implies probably not really well formed coded, not really well indented code, not really well documented code... and because of that, not really good modules in order to be used for all the rest.

Finally, some replies to Sebastian:

  • First, what explains the success of Drupal’s ecosystem?

I would say it's easy to start. it's friendly to the user. and they are LOT of sites showing videos like 'do it with drupal'. those videos last less than five minutes. and have an interface for something soo simple as adding a google map key, is something customers tend TO love.

On the other hand, you look drupal portfolio and you can see big projects and no so big projects. you look to the ez.no one and you only see big projects. that makes the customer said... 'too big for my needs'. and well, even not using all ez publish features you can still do small websites with it...

  • Second, is there an opportunity to make eZ publish as popular as Drupal, or is eZ publish a CMS in a whole different league?

Would be difficult, but why not? on the other hand, i wouldn't thing ez publish is in a whole different league. i think it's in the same league. this kind of comparations makes me think this way...

  • 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?

Seems so. but don't forget sometimes is the customer who choose, letting the developers no option...

  • Fourth, has the eZ publish CMS maybe become too complex, and the learning curve too steep for the 'average developer'?

I've been working with eZ Publish for almost 7 years. i don't think it became too complex now. it's as complex as it was in the past. but as Bertrand said, that is something that hopefully will be improved.

Cheers

Tuesday 15 March 2011 12:37:44 pm

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/....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/...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 1:39:20 pm

... It's the bc changes. Sebastiaan says "For Drupal there are 7557 modules available.", but only about 1200 of that are compatible with the last drupal core version i know (7.x)...

I'm just wondering, how many ez projects extensions is really compatible with eZ publish 4.5, since most of them is from eZ publish 3.x age ( php 4 ), and there were lots of changes since them ( almost all event types extensions will not work, and all modules that uses templateInit() also will not work ).

...i mean, buddy module is no more than relations between objects, for example...

I tested Drupal Commons and Buddypress, I need to say that they do much more than simple relations between users. I also started an eZ publish Social extension, and the work to create something like Drupal Commons isn't trivial.

Modified on Tuesday 15 March 2011 1:46:51 pm by Thiago Campos Viana

Tuesday 15 March 2011 2:07:23 pm

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 4:09:36 pm

Ekes, thanks for the counterarguments. I always like a good discussion so I'll bite...

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/....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/...drupal-views-tutorials-and-resources might give you the idea.

The example with fetching 10 newest articles was just a general example, think about fetching 10 of anything with any fields and based on any sort criteria.

For example, let's say I want to create a custom entity for my site called "Printed edition" which has this data:

  • Title
  • Edition number
  • Image
  • Some sorted out edition articles for online view, each article containing title, image and text
  • Edition PDF file - viewable only by registered users
  • Edition ISSUU ID

And let's say that I have a page where all this printed editions are listed and sorted by edition number. And for all editions, links to the download of the edition PDF, online view of the ISSUU and online articles are presented to the registered users.

So in order to implement this in Drupal do I need to:

  • create additional SQL tables?
  • install additional modules?
  • create custom functions that execute Drupal SQL queries which use joins or reference several tables?

In eZP answer to all this question is NO. You just create two classes and one user role via the admin interface and use the same fetch function that you use for fetching all other types of data. I'd say it could all be done in a half an hour, one at the most.

This is the true power of eZ Publish content model that I believe Drupal doesn't have.

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.

You should really try using eZP for a while to see what a really powerful abstraction layer is. Also note the part where I mention "several abstraction layers"... As far as I have seen the Drupal's "abstraction layer" is only one small part of the eZP's complete abstraction layer.

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

Again, the Drupal's schema api is just a small part (the ezcDbSchema class) of the complete eZC' s Database schema component.

Tuesday 15 March 2011 4:35:28 pm

So in order to implement this in Drupal do I need to:

  • create additional SQL tables?
  • install additional modules?
  • create custom functions that execute Drupal SQL queries which use joins or reference several tables?

In eZP answer to all this question is NO. You just create two classes and one user role via the admin interface and use the same fetch function that you use for fetching all other types of data. I'd say it could all be done in a half an hour, one at the most.

This is the true power of eZ Publish content model that I believe Drupal doesn't have.

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 4:57:54 pm

Thanks Ekes for joining the discussion.

I would love to have more Drupal community members join and feed this very interesting discussion.

You are the first one, thanks !

Tuesday 15 March 2011 8: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:

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.

Modified on Tuesday 15 March 2011 8:57:22 pm by Mavko Žmak - Žmale

Tuesday 15 March 2011 10:28:59 pm

I would add another point of comparaison, not citated so far :

http://secunia.com/advisories/search/?search=drupal&sort_by=date : more or less 300 security advisories since 2009

http://secunia.com/advisories/search/?search=ez+publish&sort_by=date : 5 security advisories since 2009

Friday 18 March 2011 12:58:54 am

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=

Saturday 19 March 2011 10:12:49 am

Thank you Ron for a in-depth view on the subject.

When it comes to CGI, this was solved last fall and will work out of the box in 4.5.
I have not tried it, but it might work to replace eZSys (lib/ezutils/classes/ezsys.php) in 4.4 with the one in 4.5(GIT master atm).
But as this change where quite big it was not back-ported and is thus not supported on 4.4.
I fully agree with you that any answer that asks you to re compile anything is not really helpful, it might have been ok 4-8 years ago, but not today as we all depend on distros to do that work for us.

When it comes to cluster: What kind of cluster did you try? DB or DFS (nfs/san based).
The former is indeed known to be slow, and while the latter improves on lots of things it still requires images/binary files to be served via php, hence increases the load on both php and mysql. So in this kind of setup it is recommended to use a reverse proxy / http caching to avoid at least images/binary files to cause to much overhead.

Modified on Saturday 19 March 2011 10:14:46 am by André R

Sunday 20 March 2011 8: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

Sunday 20 March 2011 9:27:29 pm

Betsy... As far as I've looked Drupal also supports many of this key advantages that you listed. It's true that some of them are supported only in Drupal 7 which was released about two months ago, but it does have them.

As for the version conflicts and upgrade problems I found many different sources (that are more objective than me) stating that upgrade in Drupal can be more diffcult than in eZ. The Drupal team itself and the founder of Drupal, state that they don't preserve backwards compatibility:

which is something that I personally disagree with. Very, very much disagree.

Modified on Sunday 20 March 2011 11:02:46 pm by Mavko Žmak - Žmale

expandshrink

You must be logged in to post messages in this topic!

36 542 Users on board!

Forums menu

Proudly Developed with from