migrate

This is the second article in a series looking at migrating from Jadu into a LocalGov Drupal (LGD) site for Central Bedfordshire. In the first article we looked at the Jadu API and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.

In the second article we looked at reproducing Jadu URLs to create redirects for migrated content, even though the Jadu API doesn't contain any URL information.

Now that we have a the Jadu connection created and redirects working we can start tackling other aspects of the migration, so let's look at migrating the main content of the site from Jadu. We can pull structured pages of content out of the Jadu API and apply them to the structure of a LGD site, maintaining the same hierarchical structure and order of pages.

This is the second article in a series of articles looking at migrating from Jadu into a LocalGov Drupal (LGD) site for Central Bedfordshire. In the first article we looked at the Jadu API and setting things up so that we could make calls to the API and parse the XML data using the migration systems available.

In the last article I mentioned something about the Jadu API that caused me a lot of headaches. The API contains most of the information for a page, but critically, the Jadu API contains no information about the path of a page. There is basically no way to get the URL of a page in Jadu from the XML API.

I'm quire sure that this makes creating anything useful in the API a real pain since referring back to the site needs to be done with manually placed links, but it's clearly like this by design. I couldn't find any documentation on why it is like this, but it almost feels like vendor lock-in. Please correct me if I'm wrong here.

This is the first article in a series of articles looking at migrating content from a Jadu site into a Drupal site running the LocalGov Drupal distribution. The site I was migrating content into was the new site for Central Bedfordshire, and whilst other implementations of Jadu may differ from what I describe here, it should be enough information for you to understand the process.

Jadu is a proprietary CMS application that is mostly written in PHP. Back in 2011 I went to a talk by one of the developers from Jadu at the PHPNW11 conference, so I was aware of the system. That talk, by the way, was interesting as they built a system called Phalanger that allowed PHP (and Jadu) to be run on a .NET environment. That project is now called PeachPie and it looks like it is still under active development.

LocalGov Drupal is a Drupal distribution that combines Drupal, some configuration, and a collection of modules with the aim of making it easier for councils to create websites.

Drupal's migration system allows the use of a number of different plugins to perform source, processing, and destination functions. 

Process plugins are responsible for copying and sometimes manipulating data into the destination. There are a number of different process plugins that allow you to get data in different ways and and apply it to your destination fields.

Both the core Migrate module and the excellent Migrate Plus module contain a number of different process plugins that you can use to process your data in different ways.

I've been doing a bit of Drupal migration recently, and one of the tasks I have undertaken is to migrate "likes" from a Drupal 7 site to a Drupal 10 site.

The likes in the old Drupal 7 site were built using a custom module, with the Flag module was selected to provide the new functionality on the new Drupal 10 site. This meant that I needed to migrate the old custom structure into the entity structure provided by the Flag module.

To add further complication, it was possible to add likes to nodes and comments, which meant that the flags on the new side needed to be applied to two different types of entity. This was simple enough to do using two different types of flag entity; one for nodes and one for comments.

When moving a Wordpress install from one place to another there are a number of things you must be aware of. If you have created your templates properly you will have used calls to bloginfo('home') rather than using static links, but you will need to update these links to make your Wordpress install work properly.

Once the files are in place, the database connection details have been edited and the database created there are a number of things to alter in the database to make your Wordpress install work.

The most important changes are in the options table. There are two references to your URL in this table that must be altered to stop Wordpress redirecting back to your old site. This must be done via database access as Wordpress will redirect you when you try to login to the stie.