Skip to content

Plone 5 Upgrade Plan

Sean Kelly edited this page Apr 17, 2019 · 2 revisions

The following describes a clean approach to upgrading the Plone portal supporting EDRN from Plone 4 to 5.

Background

The Zope application server's original vision was that all applications would be developed through-the-web. To support this, it provided a user interface where you could add items such as:

  • Page templates. These were HTML pages with replaceable variables.
  • Images, obviously.
  • Files, which were binary objects that weren't images.
  • Scripts. This is where you would implement application logic.
  • Catalogs. These provided database and indexing features.

Thus you wouldn't have to provide any filesystem code; everything would be done through the web as a means to make things "easy" for everyone. As far as model-view-controller go, the catalog provides the model, the page templates/images/files provide the view, and the scripts provide the controller. There is even a limited undo mechanism so you can do some rudimentary versioning. All of this goes into the Zope database.

If you developed an application this way, you could even export your Zope database (as a ".zexp" or Zope Export file) and share it with friends. Plone was originally developed this way: plone.zexp.

However larger development efforts often need branching, and this approach provides no way to do that. Developers wanted to develop on the filesystem so they could use their favorite tools (CVS back then) to do revision control.

The Mess

Eventually a combination of approaches began to pervade the development of Zope applications: a mixture of filesystem code as well as Zope-database settings. Nominally the Zope database should just contain content and the settings that support that content. This is the state of things up to and including Plone 4, and including EDRN.

EDRN's portal consists of the following filesystem modules that we developed:

  • edrnsite.collaborations: content types and logic for Collaborative Groups
  • edrnsite.funding: funding content types for Karl Krueger (likely never used)
  • edrnsite.misccontent: a single content type for the home page
  • edrnsite.portlets: the quick links portlet on the left and the DMCC news on the right
  • eke.biomarkers: biomarkers and panels and their ingest
  • eke.committees: member directory, committees, and their ingest
  • eke.ecas: eCAS and its ingest from eCAS and LabCAS
  • eke.knowledge: a base implementation for ingest as well as content types for body systems and diseases
  • eke.labcas: an obsolete ingest from an obsolete version of LabCAS
  • eke.publications: ingest for publications and PubMed lookup
  • eke.review: a way to review biomarkers that never got used
  • eke.site: EDRN member site ingest and site and person content types
  • eke.specimens: ERNE ingest and its content types
  • eke.study: protocol content types and its ingest
  • edrnsite.policy: orchestrates all the components above as well as additional dependencies like LDAP plus initial site settings and upgrade procedures

However, the EDRN portal also has the following script and customizations in the Zope database:

  • A custom contact info form
  • Six custom login logic scripts to comply with NCI regulations
  • A custom login form with the lengthy disclaimer
  • Custom CSS pages
  • And any number of ad-hoc security and catalog settings

Some of these were recently implemented for rapid response to Section 508.

And on top of that, there is the issue of content-type frameworks and LDAP implementations.

The Upgrade

Because of the ad-hoc and database-landed MVC changes, and because of the content type frameworks and LDAP implementations, I recommend we do not attempt to migrate the current EDRN site from Plone 4 to 5. Instead I think we should start afresh.

First, implement the above components as new Dexterity-based content types. Then, begin with a new Plone 5 database and use the Plone Transmogrofier to bring the Plone 4 content to the fresh Plone 5 database.