I could hardly wait to upgrade to the latest Plone version, which was released a few weeks ago. I finally was able to schedule enough time to spend on the upgrade to make sure that, if anything went sideways, I would be able to take the time to fix it. The upgrade went smoothly, but I ended up having to back out and fix my Plone 3 before I finally was able to successfully complete the upgrade.
I ran into this issue before, when I was upgrading to Plone 3. I went through all 6 Plone 3 sites via the Web-based Site Setup and uninstalled any products that I wasn’t actively using. My thought was that this would eliminate the number of products I would have to upgrade.
I shut down my Plone instance in Ubuntu 10.04
and then renamed the Plone folder. Then I ran the installation for Plone 4
./install.sh standalone –password=…
You can leave a current Plone in place and specify an alternate folder for your Plone 4 (with the –target= switch on the install command) but I like to take the defaults when I can.
Once Plone 4 was in place, I started it up with the default buildout.cfg and viewed the new Zope Management Interface (ZMI) to confirm that it had installed properly. Since it was an empty Plone installation, I created a test site to make sure it worked.
All good so far. I stopped the Plone instance and then went into the folder containing my Plone 3 data file
and copied it into the Plone 4 folder. I always rename the initial Data.fs to Data.original or something else that will enable me to avoid overwriting it! Tip: you should be sure to chown the Data.fs file that you copy over back to your Plone user. For example, when I copied my file over, it was owned by a different user and group. When you start your Plone instance, it will appear to start but it hasn’t. Chown the file back to the Plone user and then restart your instance and you should be in good shape.
Plone 4 has a nice upgrade page that immediately tells you which sites are not upgraded. 4 out of my 6 sites upgraded without any problem but 2 would not. I ended up having to go through the following loop a few times until I was able to get the last 2 sites upgraded:
- Stop Plone 4 instance
- Rename /usr/local/Plone to /usr/local/Plone4
- Rename /usr/local/Plone3 to /usr/local/Plone
- Edit buildout.cfg to add back the necessary product eggs and ZCML entries
- Run bin/buildout
- Start your Plone 3 instance
- Go into the site that won’t upgrade and, from the ZMI, install the products
- Again, from the ZMI, immediately uninstall the products
- Stop the Plone 3 instance
- Rename /usr/local/Plone to /usr/local/Plone3
- Rename /usr/local/Plone4 to /usr/local/Plone
- Copy over the Plone3 Data.fs to Plone 4 and restart
If you have ever had the pickling error: can’t pickle ... error, this has worked for me to eliminate the problem. In fact, I got a variety of errors that didn’t actually give me much information about what caused the problem. But there was usually something in the error that pointed to a product that I thought I had successfully uninstalled. That was the product that I would then install/uninstall and add back to the buildout as necessary and, after about 3 iterations, that cleared up all of the conflicts.
You may be scratching your head as to why it would be necessary to install and uninstall products. I can’t answer that. But what I found was that the Traceback information in the error log referred to products that I had thought were uninstalled in Plone 3. They appear to leave some hooks in the templates or somewhere else, so if you (a) uninstall them from the Web, rather than the ZMI, or (b) even from the ZMI, you may find that the upgrade fails. The products that seemed to be the most problematic were the Collective.Blogging product and the SC.Social.Bookmarks product. When I finally was working on my Plone 4 buildout.cfg, I had to add those two products and one theme – even though I never installed them subsequently – before I was able to finish the upgrades.
Plone 4 indicated that all of my sites had successfully been upgraded. You can imagine my annoyance when I clicked on the links and each site gave me a white screen that indicated I had a language KeyError. Anyone visiting this site will probably realize I am not a developer, and so diagnosing where a KeyError is coming from (shoot, what a KeyError is!!) is beyond my skills. At first I thought it had something to do with the portal_language settings so I went into the Plone 4 ZMI to see what the settings were. Strangely enough, the default drop down menu was entirely unpopulated. It seemed to me that the upgrade had correctly transferred over my Plone 3 language settings – U.S. English en-us – but for some reason they didn’t appear. At one point, when I was checking the language settings on one of the sites, I noticed that none of the language choices was hyphenated. I could only choose the top level language (English en, French fr, etc.) and wondered if that was the reason the default drop down menu was empty.
I repeated the steps above to get back into my Plone 3 and this time set the available langauges to en-us, en, fr, and de, with en as the selected default. This time, when I ran the upgrade, and I accessed the Plone 4 portal_language settings, the default menu was populated and English was the selected language.
This didn’t fix the KeyError though!! I finally tracked down the source of the problem, which was in my Plone 3 main_template file. I customized these files in each of my sites to contain information about my Google Analytics tracking. But there was clearly a conflict between the Plone 3 file and what Plone 4 was seeking. I deleted the Plone 3 main_template in the /portal_skins/custom folder and immediately each site was working again.
I have not scanned through the main_template file to figure out what the conflict was but will do so at some point in the future.