WordPress – Fixing Things

Well, it took me a while to comlete the final post about the  migration from plone to wordpress. But here it is, where I outline the finishing touches to get a fully working site. For background information, please read the previous posts about the intermediate data export from plone to the file system. and the automated import into wordpress.

Content Listings

For folderish objects plone can automatically create content listings in various styles. These listings show the content of the folder or the result of some query definition. WordPress – in contrast – is not aware of a strict folder hierarchy and content and therefore is not able to generate these listings.

What to do?

For a website of moderate size like incunabulum.de I resorted to manually creating these content listings after import into Wordpres. For this purpose the export automatically detects objects with content listings and sets the content to some predefined statement (“Directory listing missing”. After import a quick search for this statement quickly gives all pages where a manually created listings needs to be defined.

The folder listings are directly copied from the plone instance which during migration was running in parallel. There is hence no specific need to manually recreate these listings.

Trouble with Plone Aquistion

Generally defined, Plone’s aqusition is a functionality where objects can aquire any property from any parent. What this means is that e.g. if a link references an image by name, but the image is located in one of the parent folders than plone automatically subsequently searches all parent folders for said image.

Under plone the majority of posts where written manually using the restructured text syntax. Here, I used aquisition for many links to reduce link lengths and to avoid excessive typing.

Again – What to do?

There probably are some plone commands to automatically check all links and to convert aquisitioned links to directly link to the real object. But this would mean at least an additional export step and some handling around with the plone code base.

For incunabulum.de I – once again – resorted to keeping the links as is upon export and import. After import broken links are detected using the excellent Broken Link Checker Plugin in WordPress and are fixed manually by deleting the additional sub folder items in the link.

All in all this required about 2 hours for my site (and therefore was probably more efficient than mucking around with plone python code)

Handling Files, Images and Image Sizes

For all images uploaded to  plone website, various sizes are available by adding e.g. <link>/image_thumb to a link. In wordpress things are handled differently via media elements.

As I did not want to manually change all links to specific images sizes and to other files etc. I created a static mirror of the plone website via wget and copied the downloaded version to a separate subdomain.

A set of rewrite rules takes care of the rest, see below. All links to images are transparently redirected to the archive version of plone.

 # BEGIN WordPress
 <IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 
 # Plone images are served from static mirror (mz, 2014.07)
 RedirectMatch (.*)image_(.*)         http://plone-archive.incunabulum.de$1image_$2
 RedirectMatch (.*)/view         http://plone-archive.incunabulum.de$1/image_preview

 # Plone - Map all jpg images in content directories to default plone variant image_preview
 RedirectMatch /projects/(.*).jpg     http://plone-archive.incunabulum.de/projects/$1.jpg/image_preview
 RedirectMatch /restricted/(.*).jpg     http://plone-archive.incunabulum.de/restricted/$1.jpg/image_preview
 RedirectMatch /travel/(.*).jpg         http://plone-archive.incunabulum.de/travel/$1.jpg/image_preview
 RedirectMatch /work/(.*).jpg         http://plone-archive.incunabulum.de/work/$1.jpg/image_preview

Leave a Reply

Your email address will not be published. Required fields are marked *