OK, so the time has come to upgrade a few Plone 2.0.5 sites to Plone 2.1. I am currently working on 3 sites:

• Dataface
• GRUVI (A lab in the School of Computing Science at SFU)
• FAS (Faculty of Applied Sciences Website)

The FAS site is the most difficult migration by far as it contains a number of template and style modifications, and 5 or 6 custom content-types.

Dataface

The Dataface site went pretty smoothly (although there are still a few glitches like the phase ‘Glossary Definitions’ always being displayed as the page name in portal_breadcrumbs). For this site I simply exported the plone site from the old Zope instance (running Plone 2.0.5 and Zope 2.8.5) and imported it into the new zope instance (running Plone 2.1.2 and Zope 2.8.5), copied the products over (upgrading them if necessary), ran the migration tool, updated all of the schemas using archetype_tool, applied a patch to allow Epoz to work properly, and voila! It is now up and running (sort of).

GRUVI

The GRUVI migration went simlar to the Dataface migration except that I had to delete some content because it relied on products that didn’t work with Plone 2.1 (CMFBoard).

FAS

I could be spending a few weeks on this one 🙁

The FAS site is a huge site (over a gigabyte) with 5 or 6 custom content types and multiple changes made to the templates. The process thus far has gone like this:

• Exported Plone instance from old site (took 3 minutes or so)
• Copied products from old site to new site
• Imported Plone instance into new site (took 30 minutes for each attempt — 3 failed attempts before success)
• Deleted problematic content in a user’s folder that prevented migration tool from working.
• Ran the migration tool. Took 30 minutes
• Updated Archetypes schemas using archetype_tool
• At this point you couldn’t load the site because of site errors.
• Deleted all custom templates so that customized look and feel are gone — now just using default plone look and feel
• Still site errors
• Removed ACASUserFolder and replaced with fresh copy.
• Now site works but some of the custom content types aren’t showing up

The next obstacle is to find out why none of the custom content types are working. The content types were all generated with ArchGenXML 1.4.1. They seem to work fine when you go to view or edit the objects directly but the folder listings (of multiple objects) display “broken” for each object. Can’t find any documentation that says that ArchGenXML 1.4.1 has compatibility issues with Plone 2.1.2, so I am spinning my tires at this point.

I have now spent 5 hours solid working on the FAS migration. I have checked in at the Plone IRC chatroom but nobody has anything helpful to say other than “Find out what is breaking it”.

Now I must venture into the untamed world of plone documentation to try to find out how to find out what is wrong with the products… argh..

Still getting the feeling that Plone is more trouble than it’s worth right now. This is the pain of being an early adopter, I guess.

Found this tip on an IBM website. If you want to convert all http requests to https requests (useful for secure-ish sites), use the following snippet in your .htaccess file:


RewriteEngine on
RewriteCond %{SERVER_PORT} =80
RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI}


Found this tip at : http://www-1.ibm.com/support/docview.wss?rs=177&context=SSEQTJ&uid=swg21114864

Found this tip on an IBM website. If you want to convert all http requests to https requests (useful for secure-ish sites), use the following snippet in your .htaccess file:


RewriteEngine on
RewriteCond %{SERVER_PORT} =80
RewriteRule ^(.*) https://%{SERVER_NAME}%{REQUEST_URI}


Found this tip at : http://www-1.ibm.com/support/docview.wss?rs=177&context=SSEQTJ&uid=swg21114864

Simple Answer: Don’t go there.

Plone, despite its flashy coat of paint, is still a development work in progress. Upgrades from version to version have no guarantee except that they will be problematic. For now, and for many years to come, content management systems based on a relational database are the way to go.

More details later, but save yourself the hassle, unless your a python hobbyist that likes to mess around with code a lot.

1.3.0 is not sufficient. Generated content-types require Products.Archetypes.atapi which is not included in Archetypes 1.3.3.

Archetypes upgrades require the following packages to have the same version as the Archetypes pacakge:

• MimetypesRegistry
• PortalTransforms
• generator
• validation

This is a notice to any who will listen. I have given Plone ample opportunity to woo me. It is almost there but it suffers from over complexity with version compatibility.

Plone is the type of system that you need to work with every day, or you will find your self getting lost in the complexity. Creating Plone Products with ArchGenXML is one example. 4 months ago I had a system all set up to work with ArchGenXML to develop custom content types. Unfortunately, 4 months later, I find myself back on a 4 day learning curve trying to figure out all of the compatibility issues that have been introduced in the mean time. Making sure that all of the Archetypes libraries have the same version is also a headache.

It is my belief that any attempt to make something more complicated than it need be, should be met with harsh criticism and should be avoided like the plague. Plone falls into this cateogory. And for all of its triumphs (of which there are many), this one vice will prove to be its downfall, unless those in the Plone development community find a way to integrate simplicity and maintainability.

Content management systems (which is what Plone touts itself to be), must offer peace of mind in storing the content in the system. The users of the system must believe that their content is safe, and retrievable when the time comes. They shouldn’t have to worry about mucking with python code and api version conflicts every time an upgrade occurs, to make sure that their data is not destroyed. Unfortunately, development with Archetypes does not yet offer this peace of mind.

I have come to the conclusion, that, for now, Relational Databases, are still the best solution for any kind of data-centric application. They offer multiple, simple retrieval methods, and full independence from api version changes in the CMS of choice.

Oh well.. enough of a rant for now.

Found this great PDF version for the ArchGenXML tutorial. ArchGenXML is the best way to do Plone Development

http://www.fraterdeus.com/downloads/ArchGenXML_PDF_0.2.1/view

The default install of smarty is great but simple. I wanted to be able to have multiple template directories so that Smarty would search all of the directories for the requested template, choosing the first one found to be displayed (similar to a UNIX-style PATH environment variable).

This functionality is built-in to smarty (simply specify the template_dir attribute as an array), but only a single compile directory is specifiable, so compiled versions of templates in different directories will conflict. I created a SkinTool as a subclass of smarty to provide skinning. Its code is as follows:

class SkinTool extends Smarty{

         /**
          * Array of registered skins..
          */
	var $skins = array();
	
	/**
           * Overrides smarty method.  This will place compiled version of the template
           * in a subfolder of the compile_dir named after the skin where the template
           * resides.  If this subfolder does not exist, it is created.
           *
           * @param string $resource_name
           * @return string results of {@link _get_auto_filename()}
           */
         function _get_compile_path($resource_name)
         {
    	    $params = array('resource_name'=>$resource_name, 'resource_base_path' => $this->template_dir);
    	    $name = $this->_parse_resource_name($params);
    	    $template_dir = dirname($params['resource_name']);
    	    $skin = $this->skins[$template_dir];
    	    if ( strlen($skin) > 0 and preg_match('/^[0-9a-zA-Z_]+$/', $skin) ){
    		$compile_dir = $this->compile_dir.'/'.$skin;
    		if ( !file_exists($compile_dir) ){
    			mkdir($compile_dir);
    		}
    		if ( !file_exists($compile_dir) ){
    			trigger_error("Failed to create compile directory '$compile_dir'", E_USER_ERROR);
    		}
    	    } else {
    		$compile_dir = $this->compile_dir;
    	    }
             return $this->_get_auto_filename($compile_dir, $resource_name,
                                         $this->_compile_id) . '.php';
        }

	
	/**
	 * Registers a skin to be used as the default skin.  This skin is added to 
	 * the top of the stack so it has the highest priority.  If a template is
	 * requested and this skin does not contain that template, then the SkinTool
	 * will check the next skin in the stack. And so on...
	 *
          * @param $name The name of the skin
	 * @param $template_dir The directory to the templates for this skin.
	 */
	function register_skin( $name, $template_dir){
		if ( !is_array($this->template_dir) ){
			if ( strlen($this->template_dir) > 0 ){
				$this->template_dir = array($this->template_dir);
			} else {
				$this->template_dir = array();
			}
		}
		array_unshift($this->template_dir, $template_dir);
		$this->skins[$template_dir] = $name;
	
	}