Date: November 2016
Type: wordpress development
I migrated JohnEnglander.net from Drupal to WordPress and rebuilt the website on the Divi theme.
I recently wrapped up a large website project, and it’s a good one to use as a case study. I migrated JohnEnglander.net from Drupal and rebuilt it on WordPress using the Divi theme.
John Englander is an author, oceanographer, and sea level rise expert. He gives talks around the world and also works directly with businesses and governments to help them understand and prepare for rising sea levels. I was really happy to be involved with his website, because climate change is an important issue to me and this is the best way I can personally contribute.
This is one of those projects where, if I lived in the corporate world, I would say there were multiple “stakeholders” that I had to account for.
Mike Shatzkin is John’s literary agent, and recommended me to him. I know Mike from my work at The Logical Marketing Agency. Mike is now putting some of his focus onto authors who deal with climate change, including John. In addition, John’s wife wanted to provide the content and work with me on the layout and design of the website. So that’s three different personalities and interests, which had me a little worried in the beginning. But it worked out well in the end.
In any migration from one content management system to another, the big considerations are:
I’ll go over what I did to accomplish this below.
Mike was encouraging John to start creating a new type of email newsletter. The details of that are not too important for this discussion, but he needed to be able to automatically pull certain blog posts into a newsletter template. John was already using Aweber as his newsletter software, so they wanted me to find out what was possible in that system. I would not be creating the newsletters myself—they have someone else who would handle that. They also needed some prominent optin boxes on the website.
Moving to a new CMS means that you have to essentially re-build your entire website, even if you’re importing content from the old one. That requires all of the same work that’s needed when building a site from the ground up, including a new design, layouts, menus, graphics, etc. Plus, the old website was not responsive, so it was good time to upgrade.
I also knew that I would need to introduce the clients to WordPress, since they’d never actually used it before. They were trusting our recommendation to switch to it. From what I’ve seen of Drupal, WordPress is much more intuitive and user-friendly.
In any project like this, one of the first things I do is help the client look for a theme. Not much else can be done until a theme is chosen. Plus, it’s a fun job for the client because they get to hunt around for a design that they like.
In this case, the clients had already found a new theme for Drupal before they decided to move to WordPress. Even though we couldn’t use it, it helped me narrow down what they needed.
Based on their previous theme choice and the options it came with, I decided to show them Divi from Elegant Themes. I do not recommend this theme in all cases, and I’ll give some pros and cons below. However, I knew it would be an easy way to get all of the features they wanted.
There’s a new-ish trend in WordPress where companies build giant “all-purpose” themes. These themes essentially give you an extra layer of software on top of WordPress. It gives you more control over your pages than you’d usually have, and you get access to a bunch of special modules.
All of that being considered, I only recommend themes like this in certain situations:
Those conditions seemed to be met in this case, so we decided to use Divi. It was not without its challenges, but I think it was a good decision overall.
Please don’t use this as a “how to move from Drupal to WordPress” guide. I’m just going to outline what I figured out for this particular website, and it might not work for you.
My goal was to import all of the old content while keeping the same URLs. I decided to use the first plugin on the list because it seemed able to handle all of that. Plus, it was the most up-to-date and was compatible with the newer versions of Drupal. I ended up buying the premium version: FG Drupal to WordPress Plugin
It migrates everything over, including users, categories, tags, pages, posts, images, featured images, comments, authors, custom post types, and attachments. It also automatically redirects the Drupal URLs to the new WordPress URLs.
One downside is that you have to keep the old Drupal authorization in place in order for it to keep handling the imports and redirects. That caused me some trouble later.
In Drupal, you can set up multiple “blogs” and call them different things. This is quite different from WordPress. In WordPress, there is one blog per site.
Sometime in the past, John had created two different blogs. One called “Sea Level Rise Blog” with /sea-level-rise-blog/ in the URL, and another simply called Blog, with /blog-1/ in the URL. The majority of his posts were associated with /sea-level-rise-blog/, but I had to take note of all the rest that were not, just in case I had to redirect them manually later.
Secondly, I was able to use the WordPress permalinks function to make sure all of the old and new blog posts had /sea-level-rise-blog/ in the URL. This is what that looks like:
The old site had many custom post types, things like “Presentations”, “Projects”, and others. Eventually I figured out that the FG Drupal to WordPress Plugin wasn’t enough to handle those on its own. The developers instruct you to use another plugin called Toolset Types to handle your custom post types. I had to mess around with that for a little while to get it all working. It was quite a mess and I consolidated and hid a lot of junk.
Finally, the old site was using Drupal’s multisite feature. I am very familiar with WordPress multisite, having used in on Zen Web Themes and another project in the past, but I didn’t know that Drupal had a similar function.
I only discovered this because while I was poking around in the FTP, I came across a folder called /sites/ that had three folders with other domain names. I didn’t know what the heck they were doing there. It turned out that these other websites were being created from the same Drupal installation. I was pretty sure I would end up wiping out Drupal, or that it would become non-functional at the very least. I had to notify the clients about this and ask them what they wanted to do. These were only minor websites, so it ended up not being a big problem. Two of those domains are now redirecting to pages on the new site, and the last one will be re-built in WordPress next month.
The new website had to be developed alongside the old one. I always prefer to do a fresh installation of WordPress without any other software on the server, but in this case, the old website had to remain while we built the new one. In addition, the migration plugin had to access all of the old content in order to bring it over.
I did some reasearch and decided that the best option would be to develop the site in a subdirectory. Generally when people put WordPress in its own directory, it goes in a folder called /wordpress/ or similar. The rest of the Drupal files stayed outside of that.
Since I had to be careful about not killing any of the Drupal files, I didn’t want to use any automatic WordPress installers. I did it manually, following their official instructions, as I’ve done before. The only real difference is that you upload the installation files into your subdirectory instead of the root. I’d have to point WordPress to the root domain later, once the new site was ready to be launched, but I wasn’t yet sure how to to handle the existing Drupal installation.
I should be clear that I didn’t do much in the way of design. My role was more technical. The theme handled most of what I’d call design, and the client handled the layout and many small design-related choices.
This client was great in this regard. One of the things most frustrating to web developers is when clients won’t deliver the content for the website. But this client did quickly, and it worked out well. They gave me all of the text for the website in Word documents and even included specific ideas for layout. That helps me tremendously because I’m able to follow their outline, even if it’s only notes and ideas. Then once the pages are created and they’ve seen their ideas come to life, minor adjustments can be made.
This website doesn’t have many pages, but they were fairly complicated to build. They’re long pages with a lot of different elements. The Divi theme handled much of that, but I also wrote some custom CSS when necessary.
This is probably a good time to show you some before-and-afters so that you can see the updates and various elements that were implemented.
These are large files, so I’ve shrunk them quite a bit and cut off the length. You can click on any of them to see a full size version.
This page didn’t exist on the old site. Instead, it lived on its own website at HighTideonMainStreet.com. That now redirects to this new Book page. Unfortunately, I don’t have a “before” screenshot. The nature of the website made it really hard to get one. But I can tell you that the design and layout of this page is very similar to the old website, except translated to fit within the theme and match the other pages.
Another big goal for the project was to point the clients in the right direction towards creating a new email newsletter. John had been emailing out notifications of new blog posts, but Mike wanted him to start creating curated news posts about climate change. In a nutshell, he would be gathering interesting news about climate change on a regular basis (perhaps weekly or something) and using that as subscription content along with his regular blog posts.
They showed me a couple examples from other newsletters. I was supposed to find a way to automatically pull specific posts into a newsletter that would build itself. I was restricted by what Aweber could do, though.
I read through Aweber’s documentation to find out what was possible. They have a “Blog Broadcast” function. It allows you to enter a feed for your blog, which will parse itself into a template of your choosing, and it will automatically create a newsletter every X days, and things like that.
We didn’t want to pull in the entire blog every time—only some of the posts of a certain type. WordPress allows you to group posts based on categories and tags. I found out that you can get an XML feed for any category simply by adding “feed” to the end of a URL. So for example, the feed for my “Web Design” category at http://www.zenwebconsultant.com/category/web-design/ can be found at http://www.zenwebconsultant.com/category/web-design/feed
Following Aweber’s Blog Broadcast instructions, I set up a proof of concept for the clients to see. It does what Aweber claims it will do, but at this point the clients don’t know if they will use that or create something manually. I am not involved further in that part of their marketing plan, but I was able to show them their options.
As I mentioned above, the new website was developed on WordPress in a subdirectory so that the Drupal installation would still exist during development.
When it came time to launch the new version of the site, I still wasn’t 100% sure what I would do about Drupal. I had backed up all the files, done research on the subject, and I even called the web host to see what they would recommend.
All in all, it seemed like I should do two things:
This was just as tricky as the original transfer of content from Drupal to WordPress, but scarier.
I completely understood the process for pointing WordPress to the right place. All it really requires is modifying one file, changing your Site URL setting, and copying your index.php and .htaccess files from your subdirectory to the root. But I still wasn’t sure what I should do with the Drupal files. It seemed like we didn’t need them anymore. I had backed up all of those files and folders onto my computer multiple times, so there was no risk of losing individual files. We also didn’t need the multisite function anymore because plans had been made for those other domains. The guys at the web host even told me to delete them all, and that I could always simply put them back if I needed to.
Okay, so, that was that. Everything was backed up, so there was no time like the present.
I was like this:
I followed the instructions for WordPress. That seemed fine. No big deal at all. The website had errors at this point, but that was expected.
So I started deleting the Drupal files and folders. Deleting, deleting, deleting …
And there were new errors. Errors that had something to do with the login info for Drupal. I opened up the PHP file that was generating the error, and indeed, it was something about authorizing a user’s login. I knew that removing that line of code wouldn’t do anything. Something still wanted an active Drupal authorization.
I was like this:
At this point in any project, worst-case scenarios start flying through my head. What if I can’t figure this out? I work by myself. I have no manager or colleagues to go to. My coworkers are Google, online documentation, and whatever forums I can find. Could I call the hosting company and ask for help? Would they even know what the hell I was talking about?
Get it together, self, I said. Let’s just restore the Drupal files until we can figure out something else.
I copied everything back onto the server, dying inside while I waited for the uploads. At the end, I considered whether I should replace the .htaccess file. This is one of the two files that you’re supposed to copy over from your WordPress installation because it handles redirect information for the server. If I followed the instructions properly, I should not replace the new one with the old one from Drupal. But I thought, eh, let’s go ahead and replace everything so that we can at least restore the old website.
I refreshed the website, and the NEW WORDPRESS site was live!
I was like this:
In the grand scheme of things, it ended up being easy. Sometimes these things go on for hours. But I wasn’t totally sure why it had even worked. I figured it had something to do with the plugin I used to migrate the Drupal content, since that’s what the error message had referenced. So I brought up that website and glanced through the instructions again. And yes, it made sense. Remember when I said that it required you to keep your Drupal authorization active? But since I had copied over the index.php from WordPress, that must have been enough to display the new site. Phew!
Now the new site was live, but two things were broken.
It’s so typical, isn’t it? Pick one of the main goals of a project, and that’s the thing that will suddenly break on you.
None of the email optin forms were working. They were working in development, but now they were giving generic “configuration error” messages.
I figured that it must have been related to how they were built when WordPress was in a subdirectory and also displaying in that same subdirectory. Now the website was pointing elsewhere, so there must have been an old reference in the database or something.
These are boxes that look like this:
They are Divi modules and you can authorize your email service to interact with Divi, and send subscribers to your lists. I reviewed all the settings and even rebuilt one of the boxes. Nothing helped. I put in two tech support messages with the theme developers, but nobody answered. I was afraid I’d have to create all the optin boxes from scratch with a ton of CSS to make them look like the Divi modules.
Finally, I went into the Aweber account and de-authorized the connection. Then I started over from scratch with the authorization in WordPress. That fixed it.
The top element on the homepage is a slider. It has an image that slides in from the left and some text that slides in from the bottom. There are four slides.
It looks like this:
The first image refused to load on time. It would remain blank until the second slide started sliding in, and then the rest of the images would behave normally. On the second round through the slides, the image was there because it had already loaded. If you refreshed the page, the image behaved normally because it had already loaded. But if you cleared out your browser’s cache to simulate opening the page for the first time, it would happen again. The first image would stay blank until it was too late and that slide had already left the page.
Of course, this was ridiculous because it’s the first thing a visitor sees when they open the website.
I tried everything I could think of to fix it. I did an entire site speed investigation. I made some huge improvements, and the website as whole loads pretty quickly now. I adjusted all of the settings of the slider, even with some custom CSS to tweak the animations. Nothing helped. I increased the delay between slides up to 16 seconds, and the first image still flatly refused to load until the next slide started to slide in. It made no sense because other images were loading just fine.
Eventually, the more I tested, the more I started to suspect that the page was feeling overloaded and it was taking it all out on that first slider image. The page has a lot of elements on it, but there was one element that was a super drain: a gif. The clients had asked me to create a gif out of a chunk of video. It’s the same gif you see on the top of this page (and even there, it takes a while to load). It was also on the homepage, but once I removed it, the slider problem cleared up.
Wow, this case study took forever to write 🙂
Now that JohnEnglander.net has been built on WordPress and is online, the main part of this project is finished. I’ve given the clients a tutorial on WordPress and showed them what they need to know to make their own updates. They are now experimenting with creating new blog posts and making their own edits. Next month, I’ll be building another minor website for them, and I’ll continue to help them with their website questions going forward.