CampervanLife.com rebuild

Before I start the mammoth task of converting www.campervanlife.com from Drupal to WordPress, I thought I’d try the same process on a smaller site, my travel blog www.itravelabout.com.

Of course, like everyone else, I thought I would start a travel blog, make loads of money from it, and travel forever.  That didn’t happen, but the blog does serve as a great diary for my trips.  It’s nice for me to use it now to look back over the years, and I’m sure it will be even more important for me in the future.

WordPress is definitely the best CMS for this blog, as I want it to be very easy to use, easy to update, and easy to manage photos.

So here’s what I did.

1. Take full backups, as always

I took a full file and database backup of the live site.  Although I wont be changing the live site, just eventually taking it offline, you can never fully anticipate what will happen, and so taking full backups as the first step is vital.

2. Researched current migration options

A year or two ago I found a script on GitHub that someone had created for migrating Drupal (6 or 7) content to WordPress.  I thought this might be useful for me to migrate my sites and searched for it.  Strangely I couldn’t find it, but the top results for migrating Drupal to WordPress was a number of plugins.  Two to be precise: CMS2CMS and FG Drupal to WordPress.  They both have premium options, which I would need to buy.

Af first I thought I would write my own migration code, as that’s an area where I am strong in experience, but then thought I would give these plugins a try, as it will save me a LOT of time, and not cost me that much.

I consider both of the plugins, and they’re pretty similar, but ended up going for FG Drupal to WordPress as it seemed to offer more features and options.

3. Migration

I create a new WordPress website locally, installed the free version of FG Drupal to WordPress and gave it a try.  I copied the live Drupal website locally to reduce the import time.

The import went well, and I was impressed with the results.  The plugin told me I needed the premium version as I had custom content types.  Fine, it was only €50.

I bought it and re-ran the import.  Everything imported really well, pages, posts and comments.  There were a few other bits, such as a Story content type that was really just news, and so I converted those stories to Posts.

4. Problems found on the way

URLs

in Drupal a page (or post, or whatever) can have any URL, as long as its unique.  In WordPress things are not so flexible.

Using the Custom Permalinks plugin it’s possible to have more flexibility, but there are still some constraints.  I’m flexible on the URL structure, but once the campervanlife.com import is done I suspect there will be many broken links from the old site.

I plan to audit every page, revising the content and images, and also the URL if necessary.

The excellent Broken Link Checker plugin makes it really easy find and adjust broken links.  I will also add 301 redirects to the .htaccess file.  Then I can use the 404 to 301 plugin to monitor the inbound 404 links, and address any that have been missed.

<!–more–> tags

I not set the Import summary option “to the content” and I was left with lots of <!–more–> tags and duplicate content in the posts pages.  I only realised this after it was too late.

So I wrote a simple script that went through, compared the content before and after the <!–more–> tag, and removed the duplicate content.

Broken links

There are lots of broken links in the site.  Some because external websites disappear and their URLs change.  Using the Broken Link Checker plugin I was able to find, amend or delete the pretty quickly.  I can’t imagine a similar plugin/module for Drupal. If someone had made it for Drupal, it probably wouldn’t work for my version, would be abandoned, or just simply wouldn’t work as well as the WordPress version.  That’s a major factor with the WordPress community: Pride. People car about what they are making enough to do a really good job.

The Broken Link Checker is also a great way of identifying spammy comment links and easily removing them.

Broken image

There were a lot of broken images, for various reasons.

Images uploaded and inserted via the Drupal media library still have their reference to the Drupal URL path.  So I simply upload all of the images using the old Drupal file structure:

e.g. http://www.itravelabout.com/sites/itravelabout.com/files/images/

The current www.campervanlife.com website is powered by Drupal 7.  The original website was a simple flat-file website.  Then I converted it to Drupal to allow me to edit it online, and to add community features.

In 2007 when I decided to move the website to a CMS Drupal was the best choice.  I think it was version 4.7 at the time, perhaps 5.  WordPress was a much smaller deal back then, and used mostly for blogs, so not a option.

Since then I haven’t added a great deal of content to the website, but I have added features such as allowing members to add information and photos about their conversions.  I was able to do this via modules fairly easily.

I am a web developer with more than 16 years of experience, mostly in WordPress and Drupal.  So I am experienced with both, but for the last 6 years I have focused almost entirely with WordPress, and done very little with Drupal.

This has been a conscious choice as I much more enjoy working with WordPress, not only as a developer writing code, but also as an author writing and editing content.

Naturally It would seem I should WordPress for the new incarnation of the website.  However, Drupal has some powerful points that can’t be simply ignore because of my experience and preference.

So I’m going to outline my experience of using Drupal and WordPress to build and manage websites, and how this related to www.campervanlife.com.

Content management

Finding, editing and adding content in WordPress is easy and intuitive, and this is one of the reasons WordPress has become so popular.  With Drupal things just aren’t as easy. If you’re experience you can generally find your content quickly, but the lack of built-in WYSIWYG editor means the process is not as smooth with Drupal. The content editing tools built into WordPress are excellent I am much happier writing and editing content which is an important factor as it can often be a barrier to putting ideas and content on the website.

A significant factor in content management today is the use of tools such as page builders. I’ve been using page builders  in WordPress for many years for me it’s the tool of choice of building complex, easy to edit content that looks great. Whilst there are some options available for Drupal they are inferior to those in WordPress, and I fear they may not have a very long life or will not be well supported.

Winner: WordPress, by a big gap

Image manager

With each release the media library in WordPress has gone from strength to strength. It’s easy to find and upload images when editing content, or in bulk with galleries. As these features are built into WordPress they work perfectly and they are easy to use. With Drupal I find myself having to think about how the images are uploaded and stored, and most importantly when I try to use images and content it’s always a struggle to find what I want and to insert it into the content.

With WordPress I’m able to upload multiple images at one, rotate, resize and crop images with the native media library manager. This means the images are available to me wherever I am on the site however I am adding content.

It is probably possible to add the same functionality to Drupal, but I want these features to be native and faultless.

Winner: WordPress, by a huge gap

Custom content types and front end editing

Both systems allow custom content types to be added.  Drupal has had this features for year, in various guises.  And it works very well in Drupal.  Unfortunately these needs to be done via the web interface, which is time consuming and makes it harder to push from dev to live. Drupal makes it very easy for users to edit content on the front end, as it’s a native feature.  It just works.  It doesn’t work exceptionally well, and can be a bit clunky, but it’s a great start.

WordPress allows custom content types, created by plugins or code.  I always prefer the code option.  Support for fields is very limited, and one has to use a plugin such as Advanced Custom Fields.  This plugin provides an amazing interface for building content types with extra fields.  The Pro version is well worth the money, for the extra field types. Front end editing of these types and fields is not provided by default.  You have to code your own.  So definitely more time consuming, but because one is force to think about it and implement it, the results are generally better.

Winner:  Draw.  Drupal is more powerful, but the WordPress results are generally better.

Caching

Drupal has a fantastic built in caching system.  It works extremely well, and most sites can turn it on for instant performance gains with little need for testing or compromise.

WordPress has no built in caching system.  But various plugins exist to give this functionality.

Winner: Drupal, but a big gap.

Code

Drupal has great ways of separating code and templates. The Drupal community encourages best practice which works really well. The online community at drupal.org is a great place to find help and inspiration.  WordPress is not is well structured and it can be easy to not follow best practice, be lazy or sloppy. However this is not a problem with my experience.

Winner:  Draw.  Drupal has better structure, but WordPress is easier to use.

Updates

WordPress rightly prides itself on how easy it is to update the WordPress core software and also any updates for plugins and themes. It’s very rare that there is an issue and easy to put right if there is. More recent versions of Drupal have made it easier to update modules, but other parts of the system are not so easy to update, even core.

Winner: WordPress, but a big gap.

Upgrading major versions

When there is a major version of WordPress it is again a simple case of hitting the update button, and everything seems to work seamlessly. However a major version update on Drupal requires significant work and changing your theme and code to match the API changes. This is OK for a large webapp type installation but a great deal of work when you’re running trying to run a small website.

Winner: WordPress, buy a massive gap.

Themes

Drupal has always suffered from a lack of good themes to use. There are some commercially available ones for the quality standards are not the very best. Unlike WordPress where there is a huge community producing great quality free themes, often encouraged by WordPress.com themselves. There are excellent boutique theme shops such as ArrayThemes and Elma Studio.   There is a colossal range of commercial themes on ThemeForest, but they often come with some bloat.

Winner: WordPress, buy a big gap.

Plugins

Whilst Drupal has a good deal of modules available, they are often slow to be ported to the current version of Drupal.  They can often be poorly maintained or have a very slow release cycle.

WordPress generally has a higher number of plugins, of any equal standard, and generally with better support and release cycles.

Winner: WordPress, but a good gap.

Page Builders

Page Builders have been a concept in WordPress for some time.  There are many to chose from, and are rich in features.

Drupal has had the concept of panels and blocks for a long time, and in general they are OK.  But they are not a great substitute for a quality page builder.   There are a couple of premium page builders for Drupal on Code Canyon, but they have limited functionality and features.  The most popular is based on an earlier version by the same author, which has now been abandoned.  A classic Drupal module problem.

I have considerable experience using the Visual Composer plugin for WordPress, and have even built custom components for it.

I assessed all of the page builders mentioned by Pippin Williams and Chris Lema, to ensure I wasn’t overlooking an important player in this area.  I concluded that Visual Composer fits my needs really well, and will by my first choice.

Winner: WordPress, by a massive gap.

Membership features

Drupal’s membership features are excellent.  Users can register, add and edit content all from the front end.  It’s possible to assign permissions to make this happen very easily.  Buy, annoyingly user management is quite bad.

WordPress has no proper support for this, but it can be added with plugins.  Some of which are very good, but not native.

Winner: Drupal, by a big margin.

Drupal 8 assessment

CampervanLife is currently running on Drupal 7, and so I decided to install the latest Drupal 8 and give it a test drive. In particular I wanted to see the improvements with content editing and more and importantly image management.

After installing Drupal 8 I edited some content and checked  the media manager and was quickly disappointed. Of course I was assessing the built-in features are not looking beyond this with additional modules. However it’s important that my reliance on external non-core features is minimal as possible as this is cause me problems using the last few years running Drupal 7.

Page/node editing was not inspiring, and this is a major factor for me.  When I edit a page I need to feel the inspiration to write and insert media, to avoid any sort of creative block.

The Winner?

WordPress.  And here’s why, in order

1. I love writing in WordPress
2. Photo management is so good
3. I can write themes, plugins and manage data very easily due to my experience
4. Amazing range of starter themes to chose from, and plugins
5. Page builder
6. Easy updates
7. Very future compatible

Here’s where Drupal was a contended

1. Membership features
2. Front end editing
3. Caching
4. Code structure

The success of a project like this relies on good planning.  Time spent thinking and making good choices before the work starts will save time and headaches not just now, but for years to come.

1. Write a website manifesto

This might sound a bit ‘blue sky thinking’, but having a simple manifesto, or a few paragraphs that defines what the website is about, its purpose, and it’s values will help to keep the project on track.

I keep the manifesto at the top of a Google Doc, that I use to keep notes and information about the website.  When I open the document the manifesto is right there for me to see and take in.

2. Drupal vs WordPress

This is a big one.  The current website is powered by Drupal. When I created the site 10 years ago Drupal was a much better CMS to do the job then WordPress.  However, since then WordPress has become a much better contender, and perhaps more importantly I am now a very experience WordPress developer.

The first stage will be a (mostly) impartial analysis of the two CMS systems, and making a choice as to which is the best for to power the new website.

3. Pre-import

This is to prepare as much content and process as possible, so that the live site is offline for as little as possible.
Work done on my computer in preparation for the import of the data.
It’s vital to remember anything stored in the database will be lost, except for custom pages I create).

Tasks

1. Asses which content types from Drupal need to be imported into WordPress, and record any important details about the data
2. Import data and ensure all correct for:
   1. Media
   2. Posts
   3. Camper van information
   4. Directory Listing
   5. Forums
   6. Full page adverts
   7. Pages
   8. Photos?
   9. Photo Albums?
   10. Story
3. Create a theme, including header, footer, style guide
4. Create a homepage template
5. Sitewide adverts (to ensure advertisers get continued coverage).
6. Format templates for pages, blog posts, directory listings, comments
7. Turn off membership registration until this feature is ready

Import things to check

1. The data for the following are retrievable for working on at later stages:
   Members : username and email addresses. Passwords will not be copied over, and each member will have to reset their password to login to the new site.
2. Member galleries
3. Member conversions
4. Forums
5. Newsletter email addresses

Some tasks are too complicated, and will be revisited once the website is live, such as finalising and displaying members conversions content, and the forums.

4. Import stage

On my computer

1. Turn off all member interaction: New member registration, commenting and adding of any content. This is because I will be taking a copy of the live database, and any interaction from the members will be stored in the live database, and not used by my import. The quicker I get the import done and the new website live, the less time these features will be deactivated.
2. Download database from the live website
3. Import content
4. Build menu structure
5. Create homepage
6. Ensure all pages and content appear OK
7. URLS – check the new WP has the same URL structure for important pages and sections. This is important to ensure traffic sources such as search engines and links are not lost.

5. Go live

1. Take full backups of the website
2. Archive the existing Drupal site to a new live domain, so that I can cross reference it still
3. Upload all of the WordPress files.
4. Upload the database
5. Go live!

6. After go live

1. Allow member registration
2. Allow commenting
3. Format the Forums and allow proper interaction
4. Edit member profiles
5. Format membership conversions. This includes revamping the way the images are stored, and how members edit their conversion story.
6. Format News items
7. Format blog posts

7. Content audit stage

Once all of the data is considered moved over from Drupal to WordPress, the audit of the content can begin.
This is where I would start if I wasn’t moving from Drupal to WordPress.

1. Visit every page and audit the content, images, URL, SEO, etc.
2. Comment link audit (use Broken Link Checker plugin)
3. Use the Smart 404 plugin to automatically direct links to pages that have URLs that have changed.