EnSimpleStaging 1.1 (Beta release) (Sep 09, 2008)

This is not a final release. Experimental releases should only be used for testing and development. Do not use these on production sites, and make sure you have proper backups before installing.

Lots of enhancements including a progress meter and increased performance.

For additional information about this project, please visit the overview page .

Available downloads

Release Notes

Tested with Plone 2.1, Plone 2.5, Plone 3
State Beta release
License LGPL
Release Manager Josh Laplace

WARNING

This version of EnSimpleStaging with the attached ZopeVersionControl module requires versioning to be turned off for content types that are staged.  If you staged versioned content you would have multiple versions in the repository.  Bloating your repository considerably.  We will not be fixing this in the 1.1 release.

 

Release Description

EnSimpleStaging is a staging solution for the Plone CMS.  It enables content to be "staged" to other locations in the database (ZODB).

 This release includes:

  • Significant performance increases
  • Ability to stage non-contentish items (i.e. PageTemplates)
  • Fixes for Kupu's "URL Rewriting" policies to optionally preserve the resolveuid PATHs
  • Progress mechanism for incremental and full deployments - ensuring browsers do not timeout
  • Option to preview what changes will be made and ability to select which items you want include/exclude in deployment
  • Non-destructive uninstall
  • Increase in test coverage

 

Next release to include:

  • Preserving containment ordering in target destination (ddixon)
  • More javascript hardening (patrick hunlock)
  • Merging of 'CMFEditions' and CMFStaging 'connection handling' (ddixon)
  • Timecapsule support (ddixon) for ISO compliance

 

Dependency updates:

  • CMFStaging
  • ZopeVersionControl

 

EnSimpleStaging now requires:

  • simplejson
  • AdvancedQuery

 

Thanks to:

 

Change log

 - Migrate VersionPathInfo to VersionPathInfo2 on Incremental
   Deployment (saves us the trouble of migrating all VersionPathInfo
   for all stages manually).
   [sidnei]

 - Messed up on initializing PublishStageStart event.
   [sidnei]

 - There was an error reporting an error reporting an error. 'Sweet',
   on Patrick's words.
   [sidnei]

 - Use effectiveRange RangeIndex if it's available.
   [sidnei]

 - Stick the last logged exception for a stage into the stages'
   progress status['process']['ERROR']['current'].  
   [sidnei]

 - In the previous fix, forgot to also check the items marked as skip
   and/or remove during iteration.
   [sidnei]

 - Content that was inside an expired folder too was showing up as
   pending deployment. Now we mark it for deletion along with the
   folder.
   [sidnei]

 - Content that was expired was filtered out when deploying but not
   when computing the changeset, which lead to always displaying
   expired content on pending changes.
   [sidnei]

 - Unified getLastChangedPaths and getLastAddedAndRemoved to use the
   same base codepath to avoid diverging in the future. Optimally,
   they should do one 'base' query to compute the current 'deployment
   candidates' then incrementally filter on to 'changed' subset
   instead of doing two queries. This might be possible using
   'IncrementalSearch' (TODO).
   [sidnei]

 - Fix a backwards-compatibility issue: 'root' of the VPI tree needs
   to always be equal to the stage path, without an ending slash.
   [sidnei]

 - Hide 'Pending Changes' if incremental deployment is not
   possible. Doesn't make sense to show it otherwise. (ENTRANSIT-110)
   [sidnei]

 - Changed VersionPathInfo to use a less expensive structure, named
   VersionPathInfo2. Added manual migration from VersionPathInfo to
   VersionPathInfo2.
   [sidnei]

 - Add more notifications for each of the separate steps (CHECKIN,
   TAG, EXTRACT).
   [sidnei]