Stability, predictability, maturity Stability often comes at the cost of innovation. We cannot do all that much fancy within the scope of Plone 3. That would break the promise. So, as happy as we are with Plone 3 — time to get innovating again.
Build Plone 4 and put plone back on the cutting edge.
was called Plone 4 Planned a big release with massive changes in 2010 But as work progressed, it became evident that there was quite some release-worthy stuff that wouldn’t have to wait for such a major overhaul — and till 2010.
So it was decided to make a Plone 4 release, hopefully in 2009 Not as radical as the work on Plone trunk Will have new features, — but stuff that is stable now. Features that are too big for a 3.x release. (i,.e require migration, compatibility changes, might break addons) Not experimental
With release manager Eric Steele , who should take special care to make sure there are more high-resolution images of him available on the web.
All the big changes that were recently referred to as Plone4. Are now called Plone Trunk. Hopefully a 2010 release as Plone 5. Hanno will be release manager for Plone 5.
As there is a formal proposal and review process, code to be written on a volunteer basis, and a general lot of uncertainty here — let’s see all of this as speculation, guesswork and hopes.
Widely used visual editor. Kupu is no longer maintained. The new editing UI for Plone trunk will also be based on TinyMCE. Plone integration already. You will still be able to use Kupu with Plone 4, of course. We’ll just switch the default.
Finally proper support for BLOBs Store binary objects outside the ZODB On the filesystem Tested. We have this running in a 7000 employee intranet.
Upgrade machinery. replaces the critically dangerous reinstall button in the portal quickinstaller. Makes it simple for product authors to define upgrade steps between versions.
No more need for hacks like this. The builtin Zope mailhost is now more advanced than this one. It is better for us to have less custom stuff to maintain.
Newbie (limited/restricted user) Site admin vs Manager
Stuff like Gloworm
Debugmode should be linked to Zope’s debugmode.
Major source for confusion for newbies.
Commenting is one of the original cool features of the CMF and Plone — but it is way overdue for revision.
… so the recently updated plan shows a timeline like this, with a
Tiles is the back-end architecture Deco is the front end editing interface
By having the editing controls clearly separate from the rest of the UI, it makes it obvious to users where to find editing controls. It also makes it easier for us to build more advanced menus, as we don’t have to take theming stuff into consideration. Much simpler job for themers.
Not needed anymore. Since deco handles layout properly no more need for “use content as default page”
Plone looks rather old and worn by now.
…So Alex Limi is working on a freshup to the new default theme … based on the typography and overall feel from Plone org.
Archetypes will still work Dexterity will be there for those that want to switch And if you don’t need types, you’ll not have to relate to either.
Templating engine — can be used for multiple syntaxes of attribute based languages like ZPT and Genshi Quite faster. Maintained, Used by Repoze.BFG, Pylons, Plone
Collective.SOLR integrates with SOLR, an open source enterprise level search engine — much more advanced than ZCatalog. We have used this in a 7000-employee intranet we deployed last year. It works wonderfully. There is no way ZCatalog could have handled the load and the amount of content.
Replacement for Archetypes.
Theming fast and simple. Write html, poke holes in it for your Plone content. There are a lot of talks on Deliverance at this symposium. Catch at least one. XDV is deliverance reimplemented as compiled XSLT. Currently has less features than deliverance, but has much better performance. Laurence’s goal is to have it compile down to a single XSTL transform that can be placed in the pipeline. No special software required to host it. Developed and used. Used on Plone.org.
These are by far the most common tasks a developer will need to perform. plone.Grok directives for these common scenarios. No more need for zcml.
Get rid of portal_properties split more tools into configuration and functionality
(assuming plone trunk will be named Plone 5) There are currently no in-place migration to Plone trunk (like we have in previous Plone versions)