Anton Stonor and the crew at Headnet.dk are hosting the Copenhagen Performance Sprint 2007 in early November:

Anton writes: "We'll spend four days on making Plone run faster and have fun in the capital of Denmark, Copenhagen."  Sounds pretty good to me!

There are still a few seats left, you can sign up online.

Update: It's not Sept 1-4th, it's November 1-4.  :-)

If I understand this and this correctly, it means that Varnish now supports the Vary: header, which means that the last barrier to using this fast, easy-to-configure webserver proxy to front multi-lingual Plone sites should now be gone.

I also found a sample Plone/Zope config file for Varnish, contributed by Stig Sandbeck Mathisen. Cool!

According to Wichert, Plone.org is now using Varnish as its proxy.

Reading the tea leaves, it looks like a new generation of simpler, faster, easier-to-configure caching for Plone has arrived.  Hooray!

If you've had experience implementing Varnish for your Plone site, please share your stories.  I'm sure there are lots of folks who'd love to hear more.

I've just made a donation to support Alex Clark's trip to this week's DocCom Sprint, so that he can update Plone's online API documentation.  This is one of those unsexy but vitally important documentation tasks that pays huge returns to every single Plone developer, integrator and site administrator.

Alex is planning to create up-to-date automated API docs for:

• Plone-2.5.3
• Archetypes-1.4.4
• CMF-1.6.4

• Plone-3.0
• Archetypes-1.5.0
• CMF-2.1.0

While at the BBQ Sprint in Chapel Hill, North Carolina earlier this year I was part of a team of people working on improving GenericSetup.  A lot was accomplished in NC, but it's been languishing on a branch for a while, waiting for me to find the time to finish up some tests.  At long last I've done so, and the changes have been merged back into the GenericSetup trunk.  Following is a description of the new goodies you'll find there:

No more stateful "active profile"

It used to be that you had to visit the (poorly named) Properties tab of the setup tool to choose an active profile.  Then you would visit the Import tab to run all the steps.  The process was the same for both base profiles and extension profiles, even though the consequences of importing those profiles are very different.
Now things are better.  The profiles available are more clearly separated into baseline profiles and extension profiles.  Only one baseline profile can be active at a time, but you can import as many extension profiles as you want to; you don't have to jump through the hoop of making them "active".

Audit trail logs of import actions

Every time you import any profile, or any steps from any profile, the setup tool will now generate log objects recording the actions taken.  Now, if things go pear shaped after an import, it's possible for developers to know exactly which steps were ran.

Improved setup tool interface

We needed to tweak the setup tool interface to support the new functionality, and the usability has improved considerably in the process.  The ZMI is hardly end user friendly, but people who are managing site configuration will appreciate the changes.

Profile metadata

GenericSetup profiles now support a metadata.xml file, for profile metadata such as profile version number and profile dependencies.

Upgrades

This is the one I'm most excited about.  The CPS upgrade extensions to GenericSetup have landed in the core and been extended somewhat.  We've now got <genericsetup:upgradeSteps> and <genericsetup:upgradeStep> directives.  Here are examples of what these might look like:

<genericsetup:upgradeStep
     title="Merge Types"
     description="Merges two formerly separate portal types into one type"
     source="3.0"
     destination="3.5"
     handler="plone.upgrades.3_5.merge_types"
     sortkey="1"
     profile="Products.CMFPlone:plone" />

<genericsetup:upgradeSteps
     source="3.0"
     destination="3.5"
     sortkey="2"
     profile="Products.CMFPlone:plone">
  <genericsetup:upgradeStep
       title="SubStep 1"
       description="SubStep 1 Desc"
       handler="plone.upgrades.3_5.substep1"
       checker="plone.upgrades.3_5.substep1IsNeeded"
       />
  <genericsetup:upgradeStep
       title="SubStep 2"
       description="SubStep 2 Desc"
       handler="plone.upgrades.3_5.substep2"
       checker="plone.upgrades.3_5.substep2IsNeeded"
/>
</genericsetup:upgradeSteps>

Once Zope has started, you can visit the Upgrades tab of the setup tool.  There you'll see a dropdown of all of the profiles for which there are registered upgrade steps.  Choose one, and you'll see the steps that are available.  Only the upgrade steps that need to be run (by virtue of either the source and destination versions, or a declared checker function) will show up by default, but you can choose to view all of them if you need to re-run a previous upgrade.

Profile dependencies --- NOT

Whoops.  We put support for profile dependency registration into the metadata.xml parsing code, but we ran out of time and it isn't actually being used anywhere.  Want to help? 

You may be wondering at this point what versions of Plone this will work with.  Unfortunately, it will currently not work with Plone 2.5.x; the GenericSetup trunk requires Zope 2.10.  It works just fine with Plone 3.0, however; just replace the GS that comes with the bundle with the one from the svn trunk (svn://svn.zope.org/repos/main/GenericSetup/trunk), restart Zope, voila.  It probably wouldn't be too hard to backport the changes to an older GenericSetup branch, for those so inclined.

I'm happy to see this stuff land; I've been looking forward to it for a while.  Hope you enjoy it.

Alan is excited about Varnish (a new caching proxy that is simpler and faster than Squid).  Even better, the Varnish developers are planning a CMS best practices document. 

Great stuff.  I hope that setting up insanely fast caching for Plone is about to get a lot easier!

The idea that Plone is going to stop using Archteypes seems to be percolating out there in the wild somewhere.  As Martin definitively states: it's not true.

Hi all,

Just in the interest of avoiding confusion and doubt:

The Plone team have no immediate plans to remove Archetypes or stop maintaining it

Archetypes is alive and well. It has a new, pragmatic and reliable maintainer in Daniel Nouri. We all use it. Our customer deployments all rely on it. New documentation is being written for it. Plone's core content types are all built with Archetypes. Probably 90% of third party components are built on it as well.

It is true that there are new technologies that overlap in part with what Archetypes has covered in the past, such as better ways of making references between content or new ways of generating forms (especially when those forms are not meant to edit a content object). As Archetypes evolves, we will standardise on more such technologies and improve Archetypes' ability to interoperate with other parts of our stack. This is the way our evolution has always happened.

That does NOT mean that all your AT-based content types will suddenly stop working. So long as you keep testing your code with the version of Plone you want it to run with, and listen to deprecation warnings to pre-empt things being removed (after the standard two-version deprecation period) all will be well.

In Plone 3, Archetypes has gained a few new features that make Archetypes content types a bit more fleixble. To my knowledge, "plain" Archetypes content types should not break in Plone 3.

In other words - this is a big message about nothing. But just like the "Plone 3 will run on pure Zope 3" myth (also not true!) this one is dangerous if a number of people believe it to be true.

Regards
Martin

Martin Aspeli recently wrote to the plone-users email list:

It's recently come to my attention that some people are confused about
the role of Zope 3 in relation to Plone 3 and beyond.

The position is summarised here (and has been for a while):

http://plone.org/documentation/faq/zope-3-and-plone

The upshot is that Plone 3 will categorically not run on the Zope 3
application server. To move Plone to be a pure Zope 3 application would
require an almost complete rewrite, and there still technologies we
depend on from the Zope 2 world that have no Zope 3 equivalent (yet).

We are committed to backward compatibility and forward migration paths.
All the core developers have applications deployed on the existing
code-base, and no desire to see every add-on product or customisation
break when moving to Plone 3 (or 3.5 or 4 or 5). We do not want every
existing developer to have to learn a completely new set of technologies.

What is also categorically true is that Zope 3 is becoming more and more
important in our world. Zope 3 can be seen as a library of small
re-usable components. The "Zope 3 application server" (as a direct
competitor to the Zope 2 application server) is but one configuration of
these components. Since Zope 2.8 (and Plone 2.5) these have been usable
inside Zope 2 via an integration component called Five. In a sense, Zope
2 and Zope 3 are converging as some of Zope 2's internals are improved
by borrowing technology from Zope 3. Full convergence is still a long,
long way away, though.

In Plone 3.0, almost every new feature uses Zope 3 development patterns
and components (where appropriate). This is a Good Thing. It has made us
more productive, made Plone development more fun, and made us better
able to re-use technologies that we didn't have to (re-)invent
ourselves. Developers who've yet to learn about Zope 3: we can highly
recommend that you dip your toe in the water - if anything, you will
probably find it fun.

We hope this clears things up for those who were confused or may have
heard erroneously that Plone 3 would run on Zope 3 only. This has never
been in the plan. Plone 3 will be a great improvement over Plone 2.x,
but it is more of a rapid evolution than a complete revolution.

Please do respond to the plone-user mailing list (only) if you have any
questions.

Regards,
Martin and the Framework Team

    Congrats to gnome team for picking Plone.  Before they start down the road of a implementation -- I would like to put my 2c.  This is only one way to use the Plone CMS.  Many people do not follow this approach, i.e. plone.org.  But I believe if you have limited Plone expertise and you want people to change the public website very easily in the future it might make some sense.

    These suggestions revolve around open/free software that our company built -- the principles are what really matter -- and I dont have 1st hand experience with similiar Plone/Zope tools.  But all software is open and can easily be read/modified/abused to do whatever you want -- hooray FOSS.  This is certainly not the path of least resistance.  But it formalizes the use and expectations of the Plone CMS is a reasonable fashion.

    Seperate the content management and content delivery.  You can do this both logically (staging, skin switching, etc) and physically (cmfdeployment, entransit).  So lets stick with the simplest which is keeping everything inside of the Zope application server and database.

    All of the 'content editing' can happen in Plone with minimal customization, which is good.  The further you get away from 'out of the box' in the way of UI and editing environment.  You are bound to feel pain in the future as Plone UI templates change.  And the reason people pick Plone is the base authoring environment is decent.  We separate it out by having two containers: 'public and 'authoring'.  The 'public' container is where all the content is staged to and the 'authoring' container is where all content edits, workflow, and sophisticated collaboration occurs.

    There is a great tutorial that explains this technique written by Martin Aspelli (UK) titled,  Creating public websites with staging and custom skins NOTE: I can not say Martin would vouch for this approach he only wrote the doc.

    The 'public' user interface (gnome.org) will change much more frequently and can be changed indepedently of the 'authoring' user interface.  The public interface is where the gnome.org skin will be applied and where all the presentation logic can be isolated.  You want the 'public' site to have the least amount of logic and features as possible.  You *do not* want the Plone skin.  You want the 'gnome.org' skin to be displayed for the 'public' website.

    In my experience the website will evolve/change frequently over time while changes and enhancements to the CMS (Plone) will become less frequent. Also isolating your modifications into at least two sets of modules, 'authoring' enhancements and 'website' themes/views/etc.  Since the website software will be touched frequently and often -- use z3 views and have nothing complex in the templates.  Tres Seaver wrote something called 'PushPage' would sounds ideal -- only variables (functions, classes, values) explicitly exposed to the template can be used in presentation.  This guarantee's the templates remain as clean and explicit as possible.

    Also as a side effect you can adjust database/caching parameters better between authoring and public containers.  Oh and hardware: nothing less than 2GB of RAM and dual 3GHz.  Use LDAP.  If you want to use a external search engine it's easier to add it to the public interface -- I recommend Xapian.  Especially if your 'public' container gets notifications that content is being added its a snap to notify xapian or other systems of updates (deletes, edits, etc).

    Hope you guys have a good experience.  (Un)fortunately there are many ways to deploy a Plone CMS.  It really depends on the skill sets and isolating the complexities of the system so that future developers enhancing gnome.org can focus 100% on the 'public' website and minimize exposure to the 'authoring' environment.  Keep in touch.

As a relative newbie to the world of Plone & Zope, I found Martijn Faassen's talk "Zope in Perspective" a great introduction to the past, present and future of the Zope community.  It's always great to hear the oral history of our community summed up so eloquently (and humorously!).

Big props to Christian "Mr. Topf" Scholz for videotaping the session.  (More video here.)

Technorati Tags: plone zope

Yesterday marked the first important date in the Plone 3.0 development
process: the deadline for submissions of review bundles. The result is
an impressive number of twenty bundles:

PLIP 8 - Versioning
PLIP 48 - Use session instead of cookie plugin to store PAS authentication
PLIP 112 - XML Import / Export
PLIP 118 - Portlets engine based on PlonePortlets and Viewlets
PLIP 119 - Contextual help portlet
PLIP 121 - Asynchronous loading of content views
PLIP 122 - Edit-in-place mode for all basic field types
PLIP 125 - Ensuring link/reference integrity (removing 404 links)
PLIP 127 - Move properties to Edit screen using pre-loaded fieldsets
PLIP 142 - Componentise the global content menu
PLIP 144 - Generalised Next / Previous navigation
PLIP 145 - Locking
PLIP 148 - Move to CMF 2.1
PLIP 157 - Content rules engine
PLIP 168 - integrate iterate for checkin/checkout/staging
PLIP 171 - KSS / Azax to Plone
PLIP 172 - Wiki syntax support for all content
PLIP 173 - OpenID support
PLIP 174 - More configurable and reusable i18n features
PLIP 179 - Improved commenting infrastructure

Thank go to everyone who was involved in the development of those
bundles - the result of their work is going to make Plone 3.0 an awesome release.

The remainder of the Plone 3.0 time-line looks like this:

- September 25: framework team finished reviewing bundles
- October 8: final verdict for all bundles
- November 30: first beta release
- January 22: first release candidate
- March 12: release

During the next couple of weeks the framework team will review all
submitted review bundles. A first review is not final: the framework
team may have suggestions for improvement that make a bundle acceptable for merging. The window for making and reviewing those improvements ends on October 8.

During this phase we will be making alpha release with the accepted and merged bundles.

The OpenID folks are offering a $5000 bounty to qualified open-source projects that implement OpenID.  Plone is on their "most wanted" list.

http://iwantmyopenid.org/bounty

To answer the obvious question: "OpenID is a light-weight, decentralized authentication mechanism that allows you to have one login that you can use anywhere on the Internet. "

Plone 2.5 was released yesterday.  This is the first "infrastructure" release under Plone's new release plan and version numbering scheme, which includes alternating "infrastructure" and "feature" releases.

Most of the new stuff in Plone 2.5 is underneath the surface, where the first big chunks of Zope3 plubmbing are now in place -- most notably the PlonePAS user authentication framework, which makes it easy to have Plone authenticate and store member properties in external data sources and the new GenericSetup system for creating and configuring sites.

There's also a slew of minor bugfixes and usability enhancements.

Congratulations and thanks to all those who worked so hard to get this out the door.  Onwards to Plone 3.0!

Although they didn't manage to quite time to sync up with the Ubuntu Dapper Drake release ;-), it's very exciting to report the release of Plone 2.1.3, which bundles up four months of bug fixes, usability enhancements and performance tweaks.

The full list of fixes is pretty long (249 items!), but among the highlights noted by release manager Stefan Holek are:

• You can now insert resized images into pages.  This is a hugely useful feature, and I believe it may be unique to Plone, thanks to the extremely tight integration between Plone and its graphical editor Kupu.
  
• Portlets now have support for rounded corner styling, which makes Plone even easier to customize.
• Viewing an uploaded file now downloads it directly
  
• Various improvements to the navigation portlet

It's great to see Plone kick another quality release out the door.  Plone 2.5 is just around the corner!

Late spring must be NGO season for Plone.  Following hot on the heels of Oxfam GB's very successful Ploneability  Plone for NGOs mini-conference, Matt Blair, Humaninet's Chief Plonista, has written at length about his experiences implementing Plone as a collaboration tool for Humaninet's internal and external project teams. 

There's a lot of great feedback in these documents, covering both the general usability of Plone, as well as features specific to intensive team collaboration.

Matt's also written a very practical guide to evaluating third party Products for Plone, which contains a ton of hard-won wisdom, a simple explanation of Humaninet's custom workflows (a great example of this powerful feature in a real-world situation), and some interesting thoughts about Plone's unsuitability for multi-author real-time collaborative document editing.  (Which is a darn hard problem, I might add, which no open-source CMS solves very well. Yet.)

Matt's writeup deserves a much closer look than I've had time to give it, but one thought that occurs to me right off is this: a bunch of his needs and frustrations seem to revolve around's Plone lack of built-in document versioning and rollback.  I'm surprised that he didn't give CMFEditions a whirl, which on the surface seems like it's exactly what he needs, and was sponsored in large part by a fellow NGO, Oxfam GB, who presumably are using it for similar use cases.

Alexander Limi just posted a lengthy report-out on last week's Archipelago Sprint, which was the first big work session for Plone 3.0, slated for a late 2006 release.

It's a great report that blends community, technical geekery and screenshots of some mind-bendingly cool new features that are going to push Plone to even greater heights of usability and power.

This is exciting stuff.