Sadly, this website suffered increasing bit-rot. For many years I have hosted the blog using Drupal, from v5 – v6. That system however became more and more difficult to maintain, converting from one version to another was a nightmare, and upgrading versions of modules became a real time-sink, and fraught with problems caused by incomplete maintenance of the modules by their authors. Combined with competing demands, ultimately that led to me halting updating the site’s code and content. However, my hosting provider, AMS Computer Services forced my hand by upgrading PHP to v7 which completely broke the Drupal v6 site. So my apologies for the extended period of time my site was down.
The final straw came in trying to convert from Drupal v6 to v7, which just became practically impossible, with conversion failures. I spent considerable time diagnosing the problems with the conversion, asking questions on the Drupal forum which elicited no response, finding maintenance practically impossible without drush, which was not possible to run on shared hosted sites, with an actively hostile hosting provider making running ssh very difficult (requiring fixed IP addresses of the clients to access the server, which becomes tedious to continuously manually ask to update with DHCP IP addresses).
What really caused me to balk was finding that Drupal v7 moved to a database schema which held binary blobs of persisted PHP objects which makes maintenance highly complex, practically impossible to fix anything with SQL, nearly always requiring drush and breaks the model/view/controller paradigm. In my opinion, Drupal’s original vision has fractured into a set of uncoordinated modules which makes it a complete gamble if you can keep a site operating with differing levels of maintenance support of each add-on. Complicating this is a generally poor level of PHP coding for many modules, and a tendency for them to be abandoned very quickly. There are others who have highlighted the decline of Drupal. For a large scale site which can devote a full-time developer to simply keeping all modules maintained and operational, it might be worthwhile, but for a personal blog with varied media support requirements, it clearly had become too much of a burden for me.
The most obvious solution was to convert the site to a different content management system, and WordPress clearly stood out as the best candidate. The architecture has continued to evolve, and support remains high, it’s a simpler system to Drupal, yet much more of the functionality for my needs was present, without relying on as many modules just to produce a set of blog posts with some varied media types. To be fair, Drupal v7 and v8 have attempted to address many of these issues, but of course getting the site from v6 to v7 was problematic. Some research showed that FG Drupal to WordPress converter (FGDW) by Frédéric Gilles showed promise.
This plugin requires purchasing the premium version in order to do a halfway useful conversion of a relatively complex Drupal site using the Content Construction Kit. I generally avoid commercial software as I don’t want to lock myself into proprietary solutions. However, the possibility of saving time by using commercial software proved too tempting. However, there are a number of gotchas to this process. I found I had to purchase both the CCK and Toolset Types plugins in order to run the conversion to completion without errors. The Toolset Types plugin is particularly problematic as it’s a yearly subscription. I opted to pay for it to do the conversion with the intention to abandon it’s use over time. I also had to make a special version of the old Drupal site available (using the partially broken v7 conversion) so that all the content (images, and other files) could be retrieved for the conversion.
I found Gilles support to be quite helpful, as it was not possible to do the conversion on my webserver due to PHP memory constraints unhelpfully enforced by the hosting provider. This required using the instructions for installing and upgrading on a local machine using AMPPS. However, while the final conversion went without error, after all the conversion plugins were properly installed, I found I was left with a site which was not practically usable. All the data was there, but instead of converting Drupal posts to WordPress posts, the posts were converted to a WordPress custom post type labelled as a blog. This seems to have occurred because of the way in which blog posts were defined in the original Drupal v4 and may not occur for other people attempting such a conversion. Unfortunately, FGDW did not convert the abstract and main blog post fields properly, actually merging the two into a single HTML field with an HTML comment separating the duplicated abstract from the main body of the text. This required manual editing.
I then found that the WordPress Post Type Switcher plugin can be used to switch individual blog entries to WordPress post types. While an individual blog entry could be converted relatively painlessly, more problematic was converting from the custom tags which were created by FGDW to WordPress categories and tags. That is also possible using the Taxonomy Switcher plugin. Finally, the individual images in Drupal which were in Image galleries needed to be converted to WordPress Media entries, and the individual captions and descriptions migrated. Ultimately these were done manually, but could probably have been done with some judicious SQL with a significant enough investment in time to understand WordPress’s database schema.