CMS Watch’s Tony Byrne recently published his annual “kudos and shortcomings” report on 40 major web content management systems. It’s a summary of a much more in-depth pay-to-read report.
Byrne evaluted CMS in 30 different categories — user-generated content, usability, overall value, etc. In each category, he identified one leader, several “honorable mentions” and several laggards.
Scott Paley of Abstract Edge took the time to add up Bryne’s evaluations into a simple scorecard, and found that Plone handily topped the list, beating out both commercial and open-source competitors as CMS Watch’s most lauded CMS.
| Platform | Kudos | HM | Lagging | Score |
| Plone | 2 | 6 | 4 | 2 |
| Clickability | 1 | 3 | 3 | -1 |
| CrownPeak | 1 | 6 | 5 | -2 |
| Day | 2 | 4 | 5 | -2 |
| FatWire | 2 | 1 | 4 | -3 |
| Hot Banana | 0 | 4 | 4 | -4 |
| Mediasurface | 1 | 2 | 4 | -4 |
| EPiServer | 0 | 1 | 3 | -5 |
| Hannon Hill | 1 | 1 | 4 | -5 |
| Oracle/Stellent | 1 | 3 | 5 | -5 |
| RedDot | 1 | 3 | 5 | -5 |
| Tridion | 3 | 1 | 6 | -5 |
| e-Spirit | 1 | 0 | 4 | -6 |
| Ektron | 1 | 1 | 5 | -7 |
| Escenic | 0 | 1 | 4 | -7 |
| Midgard | 0 | 1 | 4 | -7 |
| Serena | 1 | 1 | 5 | -7 |
| CoreMedia | 0 | 2 | 5 | -8 |
| Ingeniux | 0 | 2 | 5 | -8 |
| Interwoven | 1 | 4 | 7 | -8 |
| PaperThin | 0 | 2 | 5 | -8 |
| Percussion | 1 | 2 | 6 | -8 |
| Refresh Software | 0 | 2 | 5 | -8 |
| eZ Publish | 0 | 1 | 5 | -9 |
| GOSS | 0 | 1 | 5 | -9 |
| Immediacy | 0 | 1 | 5 | -9 |
| TYPO3 | 0 | 3 | 6 | -9 |
| eZ Systems | 0 | 0 | 5 | -10 |
| TerminalFour | 0 | 0 | 5 | -10 |
| WebSideStory | 1 | 0 | 6 | -10 |
| Drupal | 2 | 2 | 9 | -12 |
| Enonic | 0 | 0 | 6 | -12 |
| IBM | 2 | 2 | 9 | -12 |
| Documentum | 0 | 3 | 8 | -13 |
| Joomla! | 1 | 1 | 8 | -13 |
| Sitecore | 2 | 3 | 10 | -13 |
| Vignette | 0 | 1 | 7 | -13 |
| OpenCMS | 0 | 0 | 7 | -14 |
| Microsoft | 0 | 5 | 10 | -15 |
| Alfresco | 1 | 2 | 10 | -16 |
What do I make of all this numerosity? A couple of things come to mind:
Jon Stahl: Plone Blows Away Commercial and Open-Source Competition in CMS Watch Review
Originally from Planet Plone by
So. I’ve been Ploning for about 18 months now. I’m strictly an “integrator” type. As an integrator/customizer, hardcore Plone developers probably won’t find this blog of much interest, except perhaps how we integrators work with Plone. We are, in fact, just another segment of the Plone user population.
Oh, and I write documentation. I actually enjoy that kind of writing. Very straight forward, very logical, very organized 
Speaking of documentation, I’ll be attending my first sprint ever, five days at the Googleplex, writing documentation for Plone with a focus on new Plone 3.0 features and cleaning up the how-tos written for integrators/customizers (go figure!) I’ll be meeting a lot of Plonistas from #plone that I haven’t met before and meeting up folks I met at the Plone Conference in Seattle last fall – I’m looking forward to it!
In other news of the day — I have resisted any kind of suggestion (or coercion 
to become more of a developer type quite successfully for the past 18 months. I’m an ex-programmer. Or I was. Now I’m the new maintainer of CMFSin (”Syndication In”). Plinkit relies heavily on incoming RSS feeds to create “automatically updated” content throughout a Plinkit site. And I actually plan on expanding its use to create “Subject Guides” via RSS feeds of del.icio.us bookmarks contributed by Oregon librarians.
So now I guess I’m dipping my toe in and testing the waters. We’ll see how it goes!
Darci Hanning: Plonista at large
Originally from Planet Plone by
I’m in the preliminary/research stages of upgrading Plinkit and other Plone 2.1.2 (yes, I know!) sites to Plone 2.5.3. The nice thing is that I have two separate machines to play with so my existing production system can remain untouched — when you work for a state government, things like having a separate development and production system can feel like a luxury
So first comes the Plone 2.5.3 Unified Installer love. LOVE IT! I had heard a lot of great things about it but had not had the chance to actually use it before. Well, you just download the package, run the install script and watch the messages fly across the screen. LOVE IT!
Next came plopping the production Data.fs file into the new install. That didn’t work out so well. Basically, Zope kept restarting, too quickly and finally died a critical death. Hrm. Not encouraging.
But that’s alright, I thought. The night before, I had managed to do a mini-upgrade of the Plinkit template site on my Windows box at home (!!). I figured I could just export a working 2.5.3 Plone site from there and import it into my Linux/Plone 2.5.3 install at work. As it turns out, not quite. The import failed with the following message:
Error Value: Input MIME type ‘text/x-web-markdown’ for transform markdown_to_html is not registered in the MIME types registry
Huh? Really, the .zexp import from the same version of Zope/Plone should work. Well, luckily for me, Bryan from #plone came to the rescue. By adding the ‘text/x-web-markdown’ and ‘text/x-textile’ MIME types in the mimetypes_registry in the original site and re-exporting, the import was successful.
Emboldened by my success, I decided to see about exporting a Plone 2.1.2 site (after adding the above MIME types!) and importing it directly into Plone 2.5.3. Success! And in fact, both portal_migration and portal_atct/migration ran fine as well.
Now, I just need to go back and see if I can’t do it “properly” by moving my Data.fs file from the Plone 2.1.2 install to the Plone 2.5.3 install. Perhaps next week!
Darci Hanning: Starting the whole migration/upgrade dance
Originally from Planet Plone by
Here is a short story about a lovely executive report about what lovely people like Jürgen (jukart) and Bernd (dobee) are doing on an average friday 
They made some changes in the zope.security package:
——————–
While deploying the first egg based portal using zc.buildout we found that idle lovely.remotetasks caused a CPU load of 5% despite doing nothing.
After some investigation with the profiler:
lovely.remotetask throws an IndexError exception if there is no job to do. It is doing this once a second.
The publisher gets a traceback for the exception using python’s traceback module.
traceback.extract_stack() uses python’s linecache module.
Now here is the problem:
linecache is extremely slow when using eggs. We could measure 54 ms for the time spent in the zope publisher!
So we changed remotetask to not throw an IndexError.
But the publisher still took 27ms.
Profiling again showed us that traceback.extract_stack() was still called somewhere.
Finally we found it in zope.security.manager.py
newInteraction was storing a traceback to be able to print a nice traceback in case newInteraction is called a second time. This is really a good thing for the developer because you get a very detailed error report which shows you exactly from where newInteraction was called the first time.
But for which price:
Removing the extraction of the traceback put down the publisher time to
2ms
So we decided to remove this feature.
The change is now in the newest egg for zope.security version 3.4.0b2
With this new version we also measured the time with zope as a trunk checkout (no eggs involved).
The publisher is now twice as fast as it was before! newInteraction is called exactly once for each request but was taking 50% of the time (without eggs) for the publisher.
Here’s Jürgens lesson: “I’m writing this just to show everyone what can happen if not enough care is taken in really critical parts inside the zope core.”
——————–
Yay! good job guys.
Questions:Â
Does someone know why running python code out of eggs is slower (e.g. linecache)? Are there other functions that are slower out of eggs? What can be done against that?
Lovely Systems: lovely jukart and dobee – Still on (double) speed.
Originally from Planet Plone by