Scalar Migration the Easier Way

This week I was excited to try out a new trick I learned in Scalar, so I thought I’d take the opportunity to share the tip and talk a little bit about our processes when it comes to projects built in the increasingly popular platform.

In our program, we publish scholarly works using a wide variety of technologies. Although in general we advise against using pre-built platforms like Drupal or WordPress, we’ve kept the door open for Scalar projects in large part because of the platform’s and developers’ scholarly focus and motivations. And since we do have Scalar projects in the pipeline, I’ve had the chance to develop a rather productive working relationship with some of those developers constantly working to improve the platform. It’s been great to be able to talk one-on-one when we’ve run into glitches or need to customize something.

One of the more recent issues we’ve encountered involves migration. As publishers, this process is inevitable. Whereas individual scholars might seamlessly develop and deploy their Scalar projects in the same server space, we’re in the position of needing to move such projects from their development environments to our own testing and publication server spaces. Over the past few months I’ve become pretty familiar with what transfers smoothly and what doesn’t. Scalar acknowledges that the import/export tool isn’t perfect, and no doubt it’s one of the kinks they’ll eventually work out. But in the meantime, with the help of Scalar’s team and documentation, I’m developing my own processes for embracing or mitigating some of the imperfections.

The main issue is this: When a Scalar project is imported into a new location, the media files are not automatically loaded. The pages containing them are, but the media locations, i.e. where the actual media is pulled from to populate those pages, remains unchanged. And in some cases, many internal links may also still direct to the old project rather than automatically flipping over to the new domain. (This second problem can be partially avoided by initially using the correct linking function in Scalar’s WYSIWYG editor, but by the time a project is ready for migration it’s usually too late.)

I recently encountered both these issues at once. The first time it happened, I solved the problem the hard way. I re-uploaded each media file, created new pages for them, deleted the old pages and files, and then renamed the new ones so they matched the old ones to ensure links to those pages remained intact. Then I went through the file list, editing each page’s source code to remove the absolute urls and leave only the relative paths. Though time-consuming, the process ensured I looked thoroughly through the project and put eyes on every piece of it. I was able to catch other issues along the way, so it turned out to be a very productive part of the editing process. It also provided an opportunity to simulate the process of copy-editing so I’d have a better idea of how to estimate the time and cost of that stage. It was an important learning experience but not one I necessarily wanted or needed to repeat for the same project if I needed to create another copy.

It turned out I did need to make another copy for internal purposes, so when I realized that none of my hand-edited relative links held over in the next migration, I almost panicked. Luckily, I had an old email from a member of Scalar’s development team that had the solution. He had anticipated I’d need to be able to change media locations on a large scale and gave me a link to one of the Scalar guide pages that explains just how to do it. And it turns out the process also applies to links pointing back to an old version of a project. What had taken me weeks to do the first time took me five minutes.

The guide essentially provides instructions on how to use a server-side query in phpMyAdmin to replace old base urls with new ones on any media or file links within the new project still pointing to the old project. Even without expertise in php, I found the instructions intuitive and straightforward.

So for anyone else working in Scalar and thinking about migrating a project to an individual or institutional hosting platform, bookmark this page!