Converting my Travel Blog from Drupal to WordPress

Darren on February 4, 2017

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/

 

Rebuild of CampervanLife.com – day 3 – WordPress vs Drupal

Darren on February 3, 2017

This is the first post in a multi-part series where I document the rebuilding and promotion of an existing website. Find out more

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

Rebuild of CampervanLife.com – day 2 – The Plan

Darren on February 1, 2017

This is the first post in a multi-part series where I document the rebuilding and promotion of an existing website. Find out more

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.

Rebuild of CampervanLife.com – day 1 – Introduction

Darren on January 24, 2017

This is the first post in a multi-part series where I document the rebuilding and promotion of an existing website. Find out more

What is the website?

On 31st March 2006 I registered the domain name campervanlife.com.  I was about to convert an empty van into a campervan, and then travel through Europe in it.  I had seen a few other blogs when people had added photos and information about their own campervan conversions, and I thought I would do the same, to help others in the future.  I am a web developer, and it’s always great to use your work skills to make something great to help others.

What I didn’t know was that a very slow rollercoaster of emotions would come from this website, as well as money and a huge sense of pride, and disappointment.

What happened?

I left Cornwall, England and headed to France in September 2016.  I had my little van, a camera and a laptop.  I intended to be travelling for 2 or 3 months, but I was away for 9 months.  I was travelling on my own, and had lots of quiet times.  So, I documented as much as I could about my day, traveling in Europe, and travelling in van I had covered myself.

I created the website, a simple HTML site using Dreamweaver, so that I add all of the content offline, and upload it when I got on line next.  These are the days before iPhones and proper 3G don’t forgot.

Anyway, I made the website, uploaded it, went home, and met a girl (now my wife).  I was about to go India, and thought I would convert the website to Drupal.  I’d used Drupal a fair bit, and knew the site would be easier to manage as I wouldn’t have a laptop with me in India.  Drupal also allowed for member interaction. I hadn’t used WordPress at this point.

I first added Google Analytics to the site, on 8th Feb 2017.  2 page views were recorded that day!  Here’s a graph of how the traffic has grown over the last 10 years.

 

Google Analytics for CampervanLife.com from 8th Feb 2017 to 23rd Jan 2017

That first year was a slow builder, but in the second year things really took off!  The site quickly become the most popular resource for campervans in the internet, ranking well for most things.

I had experience of affiliate marketing and Google Adsense, and so I was able to monetise this website well.  Well enough that me and my wife to travel through Asia and Europe for the next 5 years.

We were living the digital nomad dream.  Although I had no client deadlines, and nothing stopping me from going out and doing whatever I wanted each day.  This was great passive income, with no client demands or expectations!

However, as you can see in the data a drop occurs in 2012 and continues through until now.  This was caused by a change to Googles search engine algorithms, which meant the site didn’t rank so well anymore.  I also stopped updating the site at this point, as I had moved back to Brighton, England, and was freelancing.

This drop in traffic also means a drop in income, and with big changes from eBay, and Amazon I was making a lot less money now.  The love for this website was fading out, and I lost interest.

Why do this?

It’s been 5 years since I stopped working on the site (almost exactly).  I the last 5 years I’ve finished a degree, supported my wife, bought a property, started and closed a tech startup. and done a lot of freelance work.

I make websites for people all of the time.  My passion for that is fading, and now I dream of making CampervanLife.com an awesome resource again.  It’s taken a long time to get to this point, as I’ve had a problem saying no to freelance work.  But I’ve got good at saying no now, and today, as I write this blog post, is the start of the rebuilding of this website, and the journey to make it a great resource again.  And, the documenting of that rebuild.

My plan is to make CampervanLife.com an awesome resource that makes a good profit.

Then, I will build related websites and create a portfolio of websites giving me passive income, and allowing me to experiment with the things I love.

What are you going to do?

  1. The site is currently powered by Drupal, and a move to WordPress is likely, as I know and love WordPress, however Drupal has some important features that can’t be ignored.  So it might be an upgrade to the latest Drupal version.
  2. Create a new theme for the site.
  3. Take the existing content, audit it all, and improve it all.
  4. Replace just about ever photo on the site.
  5. Fix and improve all of the membership features.
  6. Add new membership features.
  7. Monetise the site in better ways.
  8. Offer something to sell, probably premium content.

When are you going to do it

Over the next 2 or 3 months.  I will be doing some client work in this time, to pay the bills.  I’ve taken many steps to get to this point, and I’m really excited to get started.

Then what?

Once CampervaLife.com is established again I will look to leverage its traffic and membership base.

I’ll use the Coca Cola model:  Once they started selling Coke, then they introduced Diet Coke, then Vanilla Coke.

Other ideas include a camping classifieds website, and a van database website.

Send WooCommerce emails using code – useful for testing custom emails

Darren on November 10, 2016

If you need to test custom WooCommerce checkout email templates or functionality you don’t want to constantly be generating orders, or changing order statuses.

Instead use this snippet to send the emails until your code is working perfectly.

Just add it to your theme functions.php.  Be sure to set the $order_id and the $email_class if necessary.

add_action('init', 'send_wc_email');
function send_wc_email() {

// The order ID we're testing the email with
$order_id = 623;

// The email we want to send
$email_class = 'WC_Email_Customer_Processing_Order';

/*
Available emails are:
WC_Email_Customer_Note
WC_Email_Customer_Note
WC_Email_Customer_Completed_Order
WC_Email_Customer_Completed_Order
WC_Email_Customer_New_Account
WC_Email_Customer_New_Account
WC_Email_Customer_Reset_Password
WC_Email_Customer_Reset_Password
WC_Email_Customer_Processing_Order
WC_Email_Customer_Processing_Order
WC_Email_Customer_Invoice
WC_Email_Customer_Invoice
WC_Email_New_Order
*/

// Load the WooCommerce Emails
$wc_emails = new WC_Emails();
$emails = $wc_emails->get_emails();

// Select the email we want & trigger it to send
$new_email = $emails[$email_class];
$new_email->trigger($order_id);

// Show the email content
echo $new_email->get_content();
}

How to Show KGs as grams in WooCommerce

Darren on October 13, 2016

The default metric value in WooCommerce is KGs.

My client has been running his site for years in KGs, and many of his products have the weight entered as KGs.

Now he wants to show the value in grams.

WooCommerce has an option to show the weights as grams:

WooCommerce weights

Whilst this changes the label on the website, WooCommerce was still showing the actual weight value in KGs.

I could run a script to change the weights of the products from KGs to grams, but my client was using a CSV export, and I didn’t want to disrupt this.

The following code will display the KG weights as grams on the WooCommerce templates


// Convert the product weight
function ag_woocommerce_product_get_weight( $weight ) {

// Only convert if we have a weight
if ($weight) {

// The weight is in KGS, and we want grams, to multiple by 1000
$weight = $weight * 1000;
}

return $weight;
};
// add the filter
add_filter( 'woocommerce_product_get_weight', 'ag_woocommerce_product_get_weight', 10, 1 );

wp_foots() Compromised WordPress and Drupal sites

Darren on April 13, 2015

I’m seeing a few WordPress and Drupal sites with template files being compromised, and a call to a PHP method wp_foots being added

<?php wp_foots();?>

This PHP call injects malicious Javascript code that typically writes spam links to the footer.

It is safe to delete the wp_foots() call. However, this call is part of a bigger compromise, and other PHP files within the website have almost certainly been injected as well.

You should look out for calls to eval(base64_decode( and delete/fix those files.

Dropbox stuck at 100% CPU on Mac, nothing seems to work

Darren on April 4, 2015

If you find your Dropbox is stuck at 100% CPU and constantly ‘Downloading file list’ on your Mac, and you’ve tried all of the unlink/re-link suggestions, be sure to check you don’t have a symbolic link in your Dropbox folders.

I did (from a downloaded website backup), and my Dropbox was stuck synching for weeks.

Run the following from Terminal to search for symbolic links, then delete them (or zip up the folder in my case, then delete the files).

cd ~/Dropbox
find . -type l

1 2 3

Latest from the blog

View All
Social media & sharing icons powered by UltimatelySocial