ZOPE+PLONE
· 2 PRODUCTS: web-application ZOPE and the CMF Plone

Plone is based in the Content Management Framework (CMF) which in turn is based on the Zope Web Application Server (WAS).

The CMF on top of this defines object types and processes for content management.
Plone builds on this to deliver a complete Content Management System.

· Python is the more appropriate choice of programming language to meet these goals in a Zope and Plone combination providing an almost unparalleled development platform.
Python is fast enough on the execution side and blisteringly fast on the development side.
It is object oriented from the ground up instead of having had objects tacked on late in the game and remarkably intuitive.
You’ll find the percentage of correct first guesses is higher in Python than anything else you try.

·Zope stands for “Z Object Publishing Environment” and that sounds like a lot of buzzwords like many acronyms, but it turns out that’s exactly what it does. You write Python objects.
Then, Zope makes them available on the web. Available to humans. Or software. Or whatever. Zope itself is a web server (though it is frequently run behind Apache), an object database (which holds most everything in a Zope installation and is something I miss about every non-Zope system), and an application server that executes the objects you’ve written.

· Plone is more oriented toward sites with lots of static content. with fewer releases and the releases more polished. The templates which exist for Plone are more attractive than the themes that currently exist for Drupal.

· Plone already does blogs, forums, stories, images, wiki, and more.

· Plone/CMF is built around multi-users with roles-based permissions (which can apply at several levels of granularity, from cross-site server level down to individual object level) and workflows. ppropriate model for all community sites – particularly where you NOT want a model of all content is available as soon as it’s written – IF NOT for many communities. The endusers are restricted by default because they can’t figure out how to get into the CMF, and because you have this object oriented inheritance based scheme for giving people access to editing various objects.

OKOK

· There are a lot of products on top of Zope, not only CMS/CMF, but for example ERP systems, that offers an incredible amount of functionality out-of-the-box that you just won’t find anywhere else. Features like: end-to-end i18n; localisation; placeless content; pluggable, configurable workflow; messaging; granular security (in way more depth than Drupal);

· Plone would be a strategic core system for complex requirements like an intranet for insurance companies or financial institutions.

· Zope/Plone is fantastic for large-scale projects, as you can do amazing things with it in a very short period of time.

MODULARITY
I’d like to bring some of the power and flexibility of Plone’s content management functions to Drupal,
Plone’s modularity strikes me as more powerful and flexible than Drupal’s.

· Zope is quite a mature company with quite a few proprietary ‘industrial strength’ products.

OKKO

· PERMISSIONS
Available but complex inheritance based permission schemes

KO

· Plone can similarly be stripped-down considerably, however, due to the approach of presenting everything by default, there’s actually more work involved in making a simple site.

· Plone does have “customisation policies” that allow you to choose from a number of default setups for a site, however, this extraordinarily powerful feature has never been properly utilised.

· Finding cheap and reliable Zope hosting is very difficult

· Zope can easily be configured to talk through Apache and the permissions logic is extremely granular but

· The core problem I have with the zope/plone/cmf pile is its open source-ness.

· The Zope framework is still free, but I wonder ‘how long’ and ‘will there be a development fork?’.

· Plone’s exterior seems usable, but to do very basic things you have to get into the Zope CMF which is not intuitive at all.

Plone CMF is quite confusing.

· Very difficult to enter in the code, If you don’t know about Python and the massive number of files just scare. Also having troubles in common setting tasks designing the rights permissions with plone.

· Plone is very RAM-hungry, a common gripe about Java appservers.

– DRUPAL –

· ONE PRODUCT the CMS Content Mangement System or Knowledge Management System (KMS),

· PHP

I think Drupal could be improved by taking choice pieces of Zope/Plone to heart.
replyDrupal attract by his simple and clear internal structure, which requre minimum time for learning to use and administer it. Drupal and more attractive for realization of complex workflowDrupal – mostly supports communities and hobbyst projects. While I don’t think I’m fully qualified to answer your question I can explain why I chose Drupal over the others.

* PHP/MySQL/{Apache,IIS} LAMP STANDARD

* Installation — Installation is fairly simple and a very small learning curve to get going.

* Interpreted, not compiled — meaning the module I write here will work on (virtually) any other machine that can run the other modules.

· Drupal is not by any stretch of the imagination an application
server. It’s a collection of PHP scripts connected to a database.

· The main requirement of Drupal is to provide an easy and intuitive way to allow some users to update web pages. ‘Here’s your login bob, please add a document here, I’ll review it, then publish it.’

OKOK

· Drupal has a very small learning curve relative to Zope and Plone,

Youth & Fresh adaptable to the new situation as the broadband communications conditions.
· Drupal is still in the early stages, ‘cleaner’ and quicker.

· Drupal has a more modern system for organizing the site. While Plone basically is built around the old catalog/document metaphor.

· Drupal offers the possibility to use categories to structure the site and its navigation.

· the functionality of the submission queue.

· Using MySQL also allows you to nicely hand-hack tables ‘n stuff incase things break.

- Small by comparision.
What it does (community plumbing) it does very well and important when you want to adapt it to other systems, it has clean code and well-documented programming interfaces – something I rarely see in the PHP world.

· Add its flexible templating and caching and it is very well capable of driving even large community sites or just the interactive parts of more traditional websites.

· Drupal is the best foundation for even large public community websites.

· Drupal works pretty well for smallish community sites that require minimal expenditure of effort in setup, and a defined set of core features.

· Permissions schemes with multiples roles for user

· Drupal’s configuration, layout, content editing, and style to be far more comfortable than Plone’s.

· Reworking and building a website time

· Drupal tends to move quickly and the development is less centralized.

· Drupal is easier once you understand it

· Drupal is more oriented toward community sites and blogs, where Plone is more oriented toward sites with lots of static content.

· Drupal is much more geared toward the same kind of audience that drove Movable Type to popularity; individuals and small groups of people who are more interested in communicating with the outside world quickly and easily. That’s one of the things I like about Drupal: users can do a great deal with minimal training.

Drupal’s modularity as one of its big strengths.
It intially comes configured as a small, easily manageable package. If all you want to do is maintain one blog, Drupal can do that without blinking. But as your needs grow and you require more functionality,

Drupal can easily grow with you.

· Drupal’s modules get more refined and polished, if it’s conceivable that Drupal eventually might compete on even footing with Plone

Drupal is a bit easier for the initial setup of the site.

Drupal is more permissive, a bit harder to lock down.

Drupal permissions are not inherited.
Drupal can assign more than one role per user by selecting a simple checkbox, ideal for many sites. The reason this works so well, is that sites implemented with several admins, each performing a different task, and not allowed to directly work on another department’s tasks.
Ideal DRUPAL site is for a fairly large media company, with branches country-wide.

· Drupal is confortable with the very little code threre is to drive this CMS.

· The real issue is the size of the developer community. Drupal has functionality I need, and it has it now.

· Drupal offers incredible functionality that I can access on very low cost hosts, and that’s what won this time for me.

· Drupal’s approach to a lot of the process of adding content is more streamlined, and that works well for users.

· Drupal’s is simpler and quicker to use.

· Drupal is extremely well suited to smaller, personal sites, whilst Plone is designed ground-up for enterprise applications.

· Drupal could conceivably work its way into this space with official support for Postgres, Ingres, DB2, MSSql, and Oracle.

· Drupal offers genuine simplicity out of the box.

· Lots of companies out there just want a CMS that will allow them to negate the need to pay a design company bucks to update static pages.

· Drupal can be just as ‘enterprise’ as the competition.

KO

· Drupal is not as easily able to handle the big stuff.

· Drupal still has some core things to fix (such as taxonomy_access and getting it working with some better features) that could make it very painful for a medium or large scale company to deal with.

· DRUPAL documentation is of a lower quality than Plone

· DRUPAL needs a template, making Drupal look like Plone

en Ferran

Login to ZMI. Enable syndication on your Plone site. Select portal_syndication -> Properties tab -> Enable syndication

Login to Plone. Go to the folder which contains documents you want to syndicate. Select Syndication tab -> Enable Syndication

You can also create RSS feed by any search result.

Our team has been working on Civicspace since February. It has come a LONG way and has some really exciting stuff coming up “very soon” such as the CivicCRM integration (contact management).

A caveat, tho: this is definitely bleeding edge stuff, and I would suggest that if you’re not ready to roll up your sleeves (codewise) you’ll have a rough time.

The communities (DRUPAL and Civicspace) are very supportive and informative; and, as mentioned above, the rate of progress in many directions (including, thankfully, documentation) is very rapid.

My $.02. Keep up the good work on the comparisons and keep checking on CS/Drupal in the next month in particular.

Charlie in TX

alexandrasamuel.com ? Choosing a platform for the telecentre.org network Most importantly, Drupal was alone among all CMS options in its compatibility with a distributed network approach. The platform is essentially built for exactly this kind of ap…