Personal tools
You are here: Home Documentation Manuals Plone Upgrade Guide Version-specific migration procedures and tips Upgrading Plone 2.5 to 3.0 Updating add-on products for Plone 3.0 General product development and migration tips for Plone 3.0
Support

Get Help

Join our chat rooms or support forums if you have more specific questions.

Plone Training
Learn how to design, build, and deploy a website in Plone through one of the numerous Plone training sessions around the world.
Find Plone training…
 
Document Actions

6.4.2.1. General product development and migration tips for Plone 3.0

Up one level
Before we get started on the specific tips for how to update your product to work with Plone 3, let's mention some general recommendations that might save you time when updating your product in the next versions of Plone (3.5 and 4.0).

Depending on your product, it might be hard to include compatibility for both Plone 2.5 and Plone 3.0 in the same product. There are several reasons for this, but the main ones are:

  • The workflow definition standard in CMF has changed
  • The new portlet infrastructure (although it does support old-style portlets, performance will suffer)
  • The introduction of viewlets as the main way to render content fragments in the layout

So, the general recommendation is:

  • If your product is more complex than a simple type, create two releases — one for Plone 2.5 and one for Plone 3.0.
  • If you used ArchGenXML to create your product, you should be able to regenerate your product from the UML model to get a Plone 3.0-compatible version.

Tip

  • To further future-proof your product (for Plone 3.5 and 4.0), try the following:
    • Start Zope in debug mode using zopectl fg and use your product normally. Check if it outputs any deprecation warnings to the log window.
    • Disable the plone_deprecated skin layer and make sure your application still runs without it (this disables deprecated methods and deprecated CSS styles)

Other recommendations and suggestions

  • You can use the contentmigration product to write migrations for your own products. More information on this product can be found in the RichDocument tutorial
  • A lot of the new components use Zope 3 views instead of templates. These can be customized through-the-web using the portal_view_customizations tool.
  • Do not ever rely on the JS libraries in Plone being the same across releases. Use the KSS abstractions, the underlying implementation might (and will!) change.

These things are not mandatory yet, but represent best-practice recommendations that will save you from updating these parts in the future:

  • QuickInstaller-based installation should use GenericSetup profiles instead
    • use events instead of manage_ methods (which will probably disappear in plone 3.5 or 4.0)
  • Packaging technology:
    • Use python packages instead of Zope products
    • Ship packages as eggs and register them with the Python Cheese Shop
    • Use Python Paste to create new packages
by Alexander Limi last modified August 3, 2008 - 09:30
Contributors: Martin Aspeli, Geir Bækholt, Sisi Nutt
All content is copyright Plone Foundation and the individual contributors.

For any issues with the web site functionality, please file a ticket.

Please consult the policy on plone.org content if you want your content published on this site.

Servers and hosting by