Performing a Drupal to WordPress migration can be very complex, especially if you have many content types. You’ll make the process easier if you create a migration mapping document beforehand. A common migration mapping is to convert Drupal pages to the WordPress page type and Drupal stories to the WordPress post type. However, many Drupal sites also have custom content types so the mapping won’t always be obvious. Will they be converted to WordPress pages or posts? Do they have custom fields? How about views and panels? Perhaps you may need to develop a new WordPress content type to support them.
Your Drupal to WordPress migration mapping document will give everyone involved a clear idea about how the Drupal content will be migrated to its equivalent in WordPress. If you’re running the migration yourself on a simple blog or company site, there might not be much need to spend the extra effort but sometimes running through the process uncovers aspects of the site that you may have overlooked. I’d say this is vital for migrations where you’ve hired someone else or if you have a content-heavy or news-based site. Not only will the document make it easier for someone to quote for the job, you’ll also have a specification for reference when checking the results post-migration.
Creating the content mapping
Creating the mapping needn’t be complex. The easiest way is draw up a table with at least two columns. On the left column, list down all your Drupal content types. Next write down equivalent WordPress content type on the right column for each row of Drupal content types. You might find it helpful to have a third column for writing notes, such as whether or not you need do develop a new custom WordPress content type. If your Drupal content type has custom fields, simply add rows below each type listing the fields.
Sample content mapping table
Developers responsible for the migration can also add additional sections specifying back-end table and field names where the relevant content can be found.
Creating the functionality mapping
Follow a similar procedure to create the functionality mapping. Instead of content type names, list down Drupal modules and equivalent WordPress plugins.
Preparing for your migration project
The migration mapping document will have helped prepare you for your project and provide you with a specification for the migration. You might also find the following articles useful:
If you do a lot of exporting and importing to different database servers, you’ll be familiar with the frustration of encountering MySQL import errors. Every so often when importing a WordPress dump file into a client’s database, I will encounter an Unknown collation error like the following:
Unknown collation: 'utf8mb4_unicode_ci'
Sometimes it will come up as:
Unknown collation: 'utf8mb4_unicode_520_ci'
This is caused by a difference in encoding types between the source and destination databases. It usually happens when you export from a newer MySQL database (MySQL 5.5.3 and above) which uses utf8mb4, then attempt to import into an older version using utf8. If you are importing from a dump file generated from a MySQL 5.6 database, you may get the utf8mb4_unicode_520_ci message. The 520 refers to MySQL’s use of Unicode Collation Algorithm 5.2.0. Unknown collation errors may also happen if you are trying to import a MariaDB database into MySQL. I tend to get unknown collation errors with my Rackspace Cloud accounts after Rackspace started offering MariaDB as a database option.
Ideally one would upgrade the older destination database but this isn’t always a realistic option. There are a number of discussion threads on the WordPress forum about what to do. Fortunately, many web hosting accounts have a phpMyAdmin interface which provides an easy work-around for the problem.
Format-specific options during a phpMyAdmin database export
Log in to your database server using phpMyAdmin
Make sure you select your database and go to the “Export” tab
Select the “Custom” radio button
Go the section “Format-specific options” and in the setting for “Database system or older MySQL server to maximize output compatibility with:” select MYSQL40.
Since many of my WordPress database migrations are under my migration service, I don’t always have control over the client’s platform. The phpMyAdmin export format method is often the simplest solution.
Side-effects of a character encoding downgrade
You might be wondering about the purpose of encoding types and if there will be any side-effects of downgrading. Character encoding allows support for a set of characters, such as the Western alphabet, Asian scripts and non-alphanumeric symbols. Older utf8 databases support a smaller set of characters whereas utf8mb4 includes emojis, musical notation and Chinese Han characters. If you’ve ever exported a website from one CMS to another and found random characters scattered throughout the copy, it’s because of an incompatible character encoding.
Solving the unknown collation error as described here could mean you’ll end up with unsupported characters after your site migration. However, as with many of my Drupal to WordPress migration clients, in all likelihood you’ll be migrating from an olderutf8 Drupal database to a newerutf8mb4-supported WordPress database. In this case, your old content will not have characters that will cause a problem after an encoding downgrade.
Any successful project requires careful planning and a Drupal to WordPress migration is no exception. It can be tempting to head straight to setting up WordPress, trying out new themes and experimenting with plugins. Website owners and administrators know their content is important but it can sometimes become an afterthought in the excitement to play with the new content management system. After all, you can use the Drupal site as the template and simply export over all the content over, right? For some site owners that’s all there is to it. However, you should be aware that site migrations can have hidden pitfalls that turn an apparently simple project into one fraught with complications.
The key to avoiding problems is to plan your Drupal to WordPress migration before you even touch your server. Whether you migrate the site yourself or hire me to help you, this guide will give you a head start with your planning. Keep in mind that general project planning principles apply but there are already many resources on this topic. I will focus on the areas important specifically for a migration from Drupal to WordPress.
Step 1: Consider why you are migrating to WordPress
There are many content management systems available and I’m going to assume you have already thought carefully about why you’ve chosen WordPress. For the sake of completeness, I’ll include this step because your reasons will determine whether or not the migration project will be a success.
In case you need a reminder about the merits of either CMS, here are a few Drupal vs WordPress posts:
Step 2: Decide on your approach to building the WordPress theme
The WordPress theme, just like in Drupal, is what handles how your site looks. A migration to a new CMS often goes hand-in-hand with redesigning the site. I’ve put this step early on because a site redesign could be an entirely separate project. You might want to run in parallel with the migration or it could be something you’d want to start before kicking off the content migration.
You have three options:
Redesign the WordPress site entirely.
Create a custom theme based on your existing Drupal design.
Use one of the many pre-made free or premium WordPress themes.
Step 3: Be aware of any SEO impact when migrating to WordPress
WordPress has an excellent reputation for being SEO-friendly but beware of taking this for granted. The Search Engine Journal post linked in step two should have given you a sobering outlook on how making changes to your site will affect your SEO. In my experience, preserving SEO takes a large part of the time and budget of many migration projects. Sometimes the cost will outweigh any benefit of trying to preserve the SEO customisations on your Drupal installation. This is often a commercial rather than technical decision. If you run a site that relies on search traffic, I recommend that you hire an SEO consultant to advise you. In fact, I will often work with and take direction from a client’s SEO consultant during a typical Drupal to WordPress migration project.
Step 4: Gather as much information as you can about your Drupal installation
Knowing as much as possible about your Drupal installation will help me come up with a more precise estimate for your migration project. If you’re doing the migration in-house, it will help you plan how much time to set aside and which team-members need to be involved.
Site owners who built and manage the site will likely have records of some information but not necessarily all the details of how Drupal is configured. Site owners also come to me with a site built by a third-party. They have working knowledge on how to manage it and add content but not anything else. I can help you discover the information needed for the migration if you are in this position but you can save budget by doing some investigation yourself. Use my Drupal to WordPress migration worksheet as a guide.
The formal name for this is a site audit but essentially you need to find out about two areas:
How to access your server
What kind of content you have
You’ll need your FTP server details to access your Drupal installation, media files and to upload the WordPress package. When running a migration, I like to download a full working version of the Drupal site on my local development server. This isn’t necessary but can be useful for figuring out formatting problems that crop after content migration. For example, you may find missing bits of text on WordPress and some investigation on the Drupal installation will show the text will be from a custom field or block.
The database server is necessary for exporting your Drupal database and setting up WordPress when the migration is complete. Some hosting providers offer access through a cPanel interface, a separate phpMyAdmin link or by command line. Gather all these details ahead of time will help get your project started quickly.
The content audit helps you discover what type of Drupal content do you have. Drupal, like most other content management systems, keeps content in two places:
On the server filesystem
Types of content include:
Static HTML files
Embedded media like videos, images and audio
User profile information
You may be surprised where the different bits of content that make up your site ends up being stored. A content audit will avoid unnecessary complications with trying to hunt down bits of data mid-migration.
Step 5: Write a Drupal to WordPress migration mapping document
The migration mapping document will help both with quoting for project as well as keeping track of everything that needs to be done during the migration. It gives everyone involved a framework to work on.
I know, this sounds like a mouthful and so very tedious. Truth be told, few people find writing specification documents fun but it is a necessary step if you want to avoid unexpected costs and delays. The more detailed you are, the fewer surprises there will be for everyone during the actual migration. Your investigations during step 4 will lay the groundwork for the migration specification.
I will write another post on how to write migration mapping document but the document doesn’t have to very formal. All it needs to do is clearly convey the state of your Drupal site and what you’d like migrated to WordPress.
Ready for your migration project
Running through these steps will put you in a good position for your migration from Drupal to WordPress. Admittedly, there have been projects where I or the site owner didn’t bother to do any detailed planning and we were able to get by. Usually, this was because of limited budget or a rush to launch the new WordPress site. However, the projects where we took some time out to plan ahead were always closer to the estimated budget and posed fewer surprises.
A little plug to keep the lights running. If you think all of this work is too much trouble, please consider hiring me for your Drupal to WordPress migration project.
If you are using my Drupal to WordPress Migration Tool or have hired me for Drupal to WordPress migration service, it’s important that you gather as much information as you can about your Drupal installation. The more detailed you are in your investigation, the fewer surprises there will be during the actual migration. You may have hired a web development company or freelancer to build your site and they’ll sometimes be able to provide you with the necessary information. However, gathering this information can involve some work so they may be reluctant to provide help without an extra fee.
You can use the questions below to help structure your investigation process. I can help you with this if you’re not able to run the investigation yourself. Please ask for details.
Note: You may print out this worksheet as a guide so you can record your investigations. It is not an online form. I will send you a link to my online form if you’d like me to quote for your migration project. You may also download a PDF version of my online form.
Drupal Installation Questions
What are the FTP login details of your hosting provider?
You will need these details to make a backup of your Drupal site. When the migration is complete, you’ll need them to install WordPress on your server.
Send through secure channel e.g. password manager
What are the database login details of your hosting provider?
You’ll need these to export your Drupal database to perform the migration.
Send through secure channel e.g. password manager
Do you know how to export your database to a dumpfile?
If you’re unsure how to export your database to a ‘dumpfile’, please contact your hosting provider. They will likely have tools such as phpMyAdmin and help articles to guide you through the process.
I know how to export my database to a dump file
I need help exporting my database to a dump file
What version of Drupal are you running?
The database column names differ slightly between Drupal versions. This means that a different set MySQL queries will be needed to perform the migration. You can sometimes find this information using your installation’s CHANGELOG file at http://[YOURDOMAIN.COM]/CHANGELOG.txt. Some developers remove this file as part of their security hardening process so it may not exist in your installation.
List your Drupal modules and site functionality
Can the functionality can be handled with existing WordPress plugins? Will you need to develop custom plugins?
Drupal modules and functionality
How many custom content types do you have set up?
Additional migration MySQL queries will be needed for each Drupal custom content type. WordPress supports page and post content types as standard. Additional development work will be needed to support other content types.
Drupal custom content types
How many custom fields do you have set up?
As with custom content types, custom fields in your Drupal installation will need additional work to support them under WordPress.
Drupal custom fields
Do you have blocks, views and panes with important content?
Many Drupal sites display content in blocks, views and panes. These will also need additional work to support under WordPress.
Drupal blocks, views and panes
How many nodes do you have?
The number of Drupal nodes you have does not usually play a big factor in the complexity of the migration. However, it will still be useful to get an idea of the number since many nodes can have an impact on how long it takes to troubleshoot migration problems.
Approximate number of Drupal nodes
Do you expect to have multiple aliases referencing the same post?
Aside from migrating to WordPress, do you also plan to redesign the site?
Redesigning the site will obviously involve more work as it will require a custom WordPress theme. Some site owners are happy to use a free or premium off-the-shelf theme template.
Ideas for the WordPress theme
e.g. list the names, URLs and prices of any pre-made template candidates
Are there existing WordPress plugins that match your Drupal functionality?
If you’re happy to be flexible, you may find WordPress plugins that closely match any Drupal modules you have installed on your existing site. Set aside some time to search the WordPress Plugin Directory. If you don’t find anything suitable, you may have to consider setting aside some budget for custom plugin development.
List some possible WordPress plugins you may have found
“The consensus that WordPress has better SEO is a guess…WordPress fans will guess one way, Drupal fans the other. In my opinion, WordPress SEO plugins work better for sites which are short on skill or time or money. If you want to give your clients hand-made quality, Drupal does rather a good job. This also goes for SEO. Nevertheless, lack of developer skill and client budget does sometimes mean we are better off simply ‘reheating’ and rolling out the wonderful prepackaged solutions available for WordPress.” (Slightly paraphrased for clarity.)
If you’re reading this post, I will assume that you’ve already decided to migrate your site to WordPress. Rather than re-hashing the Drupal versus WordPress SEO debate, I’ll focus on some technical details that affect your SEO efforts when migrating from Drupal to WordPress. First, let’s start with some basics.
Can I preserve my SEO during the migration?
The quick answer is, ‘Yes’. It is possible to preserve search engine optimisation during a migration. However, it can be easy to overlook the idea that you might end up with better SEO by revisiting your approach entirely. I’ve had site migrations where replicating optimisations from the Drupal version wouldn’t have made a significant impact in the business—or at the very least, where SEO was something that could be improved after the migration. If your site falls into this category, I would not recommend putting too much into preserving your Drupal optimisations. The money spent hiring me or anyone else may be better spent on improving the WordPress SEO after exporting your Drupal content.
There are some easy and low-cost approaches you can take such as:
Using or building an SEO-friendly and responsive WordPress theme.
Installing SEO WordPress plugins.
Creating higher quality content.
Improving page load times. WordPress is a lighter CMS so you should get this ‘out of the box’ but you can lose any gains if, for example, you replicate calls to third-party libraries.
Of course, you should consult an expert if you rely heavily on search traffic. Preserving SEO may be vital for your site but it’s worth making a conscious assessment about the investment needed.
What kind of work is involved in preserving SEO?
The underlying differences between Drupal and WordPress mean preserving SEO often takes the bulk of a migration budget. The amount of work needed depends on what you’re trying to preserve. To give an example from a past migration project where SEO was vital, tasks included:
Pre-migration auditing, mapping and analysing links on the Drupal site;
Developing an SEO-friendly custom theme;
Creating redirects for every URL that would change on WordPress;
Making further adjustments as directed by an SEO consultant after she analysed her webmaster tools.
Remember that SEO isn’t a one-time effort. The project needed multiple months of on-going work. Further, I was taking direction from the client’s SEO consultant who incurred her own separate fees. Thus the client allocated a sizeable budget for SEO alone. In his case it was worth the money because the Drupal site earned him many times that amount on revenue from search traffic. Minimising any negative impact on SEO after migrating to WordPress was a priority.
How much time and money you’ll need to allocate for your migration depends on a range of factors that are very specific to your site. You’ll only know after doing some in-depth analysis and documentation. Here’s an article on Search Engine Journal that I send to clients when they ask about the SEO impact of a CMS migration: How To Avoid SEO Disaster During a Website Redesign. It’s worth a read and afterwards you can think about how much SEO should play a part of your site migration project.
What exactly will affect SEO during a typical Drupal to WordPress migration? Here are a few SEO considerations to keep in mind for your migration project. It’s certainly not an exhaustive list but paying attention to these points should cover the basics.
A lot of the on-page SEO comes over as a natural side-effect of most content migration processes. For example, page titles, content keyword optimisation, sub-heading tags, image file names and internal linking are all embedded into the Drupal node content. These remain intact when the nodes are imported into WordPress, unless content cleaning or other manipulation is part of the project.
Other areas, such as URL structure, meta data and load speed will need work due to the differences of the two systems.
Off-site SEO will be unaffected by a CMS migration as long as you have the necessary redirects set up to catch URL changes for any backlinks. This is an effort that’s external to the site so not within the scope of this article.
Drupal aliases vs WordPress permalinks
URL structure is one of the SEO areas that will change after a CMS migration. A big part is because of some important differences between how Drupal and WordPress handle URLs. Drupal creates URLs using either the node ID or a URL alias stored in its database’s url_alias table. Take a look at some sample entries.
You’ll see an entry for node/28 associated with a URL alias projects/april. This means that under Drupal, the page with node ID 28 can be accessed using either http://example.com/node/28 or http://example.com/projects/april. Not shown is that content can have multiple aliases. The site could therefore also have another entry node/28 associated with URL alias projects-april and yet another with my-projects/april. You will always be able to find a page by appending the URL alias entry in the url_alias table to the site’s domain name.
WordPress has a different mechanism for creating URLs. Rather than relying on database entries, it generates rewrite rules and builds the permalink dynamically depending on your permalink settings. WordPress’ closest equivalent to the Drupal url_alias is its permalink slug stored as the post_name in the wp_posts table. Under my standard Drupal to WordPress migration, I migrate over the Drupal aliases by converting them into WordPress post name slugs. (See the table mapping in a separate article, Drupal to WordPress migration: posts table mapping.) If you have the Post name structure set in the WordPress Permalinks Settings, you’d then find the Project April page at either http://example.com/?p=28 or http://example.com/april/. Note that this would cause an SEO problem because the new WordPress link does not match the old Drupal link.
We would have to do some extra work to solve this problem. For example, if the april node was a page, we could create and link to a parent Projects page to create the Drupal http://example.com/projects/april structure. Alternatively, if it was a post, we could create a projects category or tag and set the Category base or Tag base setting. We could also create .htaccess redirects or use one of the many WordPress redirection plugins. The exact solution would depend on your project’s requirements.
WordPress permalinks have more constraints
Aside from the differences in how URLs are stored and generated, you should also be aware of WordPress permalink constrains. These will have a big impact on the amount of work needed to preserve your Drupal SEO when migrating to WordPress. I’ll briefly summarise them below.
The Drupal URL alias has a 255 character limit but the WordPress the post_name field stores only 200 characters. Make sure to keep track of any truncated posts names and create a corresponding redirect.
Since there’s no WordPress equivalent of the Drupal url_alias table, you’ll need to decide which alias will be converted into the post name. You should create separate redirects for the other aliases.
WordPress slugs which create the permalink are essentially a URL-friendly version of the post title. WordPress automatically cleans up the post title to create slugs for new content but you may encounter problems when migrating Druapl aliases into slugs. Characters that would be valid within a Drupal alias are invalid as a WordPress slug. For example, you cannot have forward slashes, accented characters and quotes in your WordPress slug. You’ll need to clean up and keep track of any problem aliases, otherwise WordPress will not be able to serve the page.
As previously mentioned, under Drupal you will always be able to find a page by appending the URL alias entry to the site’s domain name. WordPress does not store any records of its URL structure. You will end up with broken links and a potential SEO nightmare if you change the Permalink structure settings without consideration.
Remember your Drupal taxonomies
It’s easy to forget Drupal’s powerful taxonomy system is capable of generating listings that attract valuable traffic. Use webmaster tools to audit your site traffic to pick up on any such listing pages. Unlike Drupal which allows for multiple vocabularies, WordPress only offers one set of categories and tags out of the box. Replicating your Drupal taxonomy listings in WordPress may take considerable development but a quick fix may be to manually replicate the important listings pages. Obviously the size of your site will dictate if this will be feasible.
Menu and breadcrumb navigation
Menu structure and breadcrumb navigation is often an important part of your SEO. Ensure that your selected WordPress theme both supports breadcrumbs (some don’t) and the same type of breadcrumbs e.g. hierarchy, attribute and history-based breadcrumbs.
Migrate metatags generated by Drupal metatag modules
Also remember that you may have installed modules that generate metatag information contributing to your SEO. Export these from the relevant Drupal table and import them into the WordPress database using the format for your preferred WordPress metatag plugin. For example, if you used the Drupal metatag module and would like to use the WordPress Add-Meta-Tags plugin, you’ll need to extract data from the metatags table and insert them into wp_postmeta table as a meta_key and meta_value pair. Keep in mind that some investigative work will be necessary to find out how your preferred modules and plugins store their data.
Search engine visibility
WordPress has a setting to discourage search engines from indexing site. It can be found in Settings > Reading > Search Engine Visibility. It’s normal to have this checked during development but make sure you disable it when launching.
WordPress, in general, requires fewer hosting resources than Drupal. You could very well find that a slow site on an under-performing server running Drupal becomes more responsive under WordPress. Don’t take this for granted, however. Use the migration as an opportunity to make improvements. Thoroughly vet plugin candidates to make sure they’re not pulling in third-party scripts that will increase page load times. Also avoid bloated page-builder themes. In my experience, these can be terrible for load speed as they try to cram in every conceivable bit functionality, thereby drastically slowing down what could have been a nimble site.
Preserving SEO during a Drupal to WordPress migration can be lots of work
As may have gathered by now, the amount of work and budget needed will reply on many factors. It’s not possible to prescribe what will be necessary for your site without in-depth detail about your configuration and requirements. Nevertheless, I hopefully will have given you enough information to get started with planning an approach.
A little plug to keep the lights running. If you think all of this work is too much trouble, please consider hiring me for your Drupal to WordPress migration project.
I’m a huge fan of Bare Bones Software’s Yojimbo, an extremely useful tool for keeping information organised. It has been one of my most important applications since around 2008. I rely on Yojimbo as my ‘Anything Bucket‘ to save scraps of information, from code snippets and troubleshooting notes to project logs and research sources. A downside is that it’s only available for Apple Mac OS X and therefore was a factor in tying me to the Mac OS X platform.
When I started moving back to Linux for day-to-day development work, finding a Yojimbo replacement was a top priority. A colleague pointed me towards the GNOME project’s Tomboy application which runs on Linux, Unix, Windows, and Mac. Tomboy is a basic though perfectly usable cross-platform alternative but of course, I still needed to find a way of migrating my old Yojimbo notes.
Fortunately, Yojimbo has a sharing feature called Sidekick that exports your data to a set of web pages. Digging in to the Tomboy Note XML format showed me that Sidekick together with a bit of Python and some BeautifulSoup magic would provide a quick solution. I threw together pyYojimbo2Tomboy which I’m releasing under the The MIT License on GitHub in case anyone else needs it.
Keep in mind that Sidekick does not export the Yojimbo note metadata, like tags and modification times, but you can to migrate the title and note body over to Tomboy. Time permitting, I would like to find a way to save the extra metadata in a future version.
Though Bare Bones Software hasn’t released any updates and new features in a while, I still highly recommend Yojimbo for anyone on Mac OS X who needs an information organiser. It’s a little dated and doesn’t offer modern features you’d expect like an easy way to sync to the cloud and across devices. Personally, I find this one of Yojimbo’s strengths. An app in 2016 that doesn’t keep pestering you to push your information to some remote data centre with questionable privacy policies is somewhat refreshing.
Hopefully having a way to export data to a multi-platform open source alternative will reassure anyone worried about getting locked-in.
When mounting an encrypted disk in OS X for the first time, you’ll be presented with a dialog box that doesn’t allow you to paste in the password. This can be troublesome, especially if you’ve used a long, high-quality random password. Here’s how to get around having to manually enter your password into OS X’s password dialog box.
A. Get the logical volume UUID
First get the universally unique identifier (UUID) for the drive using diskutil. Open a terminal window and enter the following command:
$ diskutil corestorage list
Look for the Logical Volume for the disk. Ensure that you copy the Logical Volume UUID, not the Logical Volume Group or Logical Volume Family UUID.
B. Save a Keychain Access password item
Now we need to save a Keychain Access password item for the disk. Open Keychain Access and create a new password item:
Keychain Item Name: Name for your disk
Account Name: Name for your disk
Password: Password to unlock the disk
We’ll need to save more information into the item so once it has been created, search for it in Keychain Access and open.
Edit the password item to make sure it contains the details for your encrypted drive:
Name: Name for your disk
Kind: encrypted volume password
Account: Name for your disk
Where: UUID for the volume copied found using diskutil
Show password: checked
The important part for this step is to make sure you enter the UUID for the volume in the Where field.
Save the password item and OS X will no longer ask you to enter a password when you mount your drive.
This is a guide for setting up an Apple Mac OS X workstation with SSH key-based authentication to a remote FreeBSD server. I won’t go into any detail about these protocols or try to make a case for using them. If you’re reading this, you probably already have a basic grounding on SSH, SFTP and the implications of SSH key-based authentication. My goal is to outline the steps needed so you can start using key-based authentication on your Mac.
I. Intended audience
The instructions here are aimed at Mac OS X based web developers with at least a moderate level of systems administration knowledge. Most likely you host websites for your clients or employer on *nix servers controlled through a command line interface. You generally work on multiple servers per project. Repeatedly entering secure long random passwords is becoming a hassle. If this sounds familiar, this guide is for you.
I’m on a Mac OS X workstation, currently Yosemite, using the Mac Terminal App to connect via SSH and Panic’s Transmit FTP client to transfer files. The server instructions here are for FreeBSD but you should still find the information useful if you run a Linux-based web server. I expect that you’re familiar with your own environment and have a preferred way of doing things so won’t list every command needed.
The prerequisites for this guide are that you:
already have your server set up to SSH and SFTP with password authentication;
have an account on the server that you use for day-to-day web development;
also have root access to the server.
II. Setting up your Mac workstation and server for SSH Key-Based Authentication
We’ll need to do two main things to get everything working:
Set up your server to accept the key files instead of a password.
Configure your Mac OS X workstation to use SSH key files.
We’ll be moving back-and-forth between the them so for clarity, open up two terminal windows: one will be used for configuring the server, which I’ll refer to as your server terminal and another for configuring your Mac workstation, which I’ll call the Mac terminal.
A. Configure the server
First make sure your server is configured to accept key-based authentication. On the server terminal, open a secure shell to the server as you normally would. Edit the configuration file for your OpenSSH Daemon at /etc/ssh/sshd_config.
Look for the following lines and uncomment or add them:
You may need to return to this file later but for now, save it and restart sshd. On FreeBSD, it’s the command:
# /etc/rc.d/sshd reload
B. Generate the key files on your Mac
Now you need to generate your private and public SSH key files. The private key file will remain on your Mac and you’ll place a copy of the public key file on the server. To generate the key files, switch to your Mac terminal and run:
$ ssh-keygen -t rsa
The -t flag specifies that you’re creating an RSA key.
You’ll be asked to enter a file name for the key. The default for key files on Mac OS X is /Users/username/.ssh/id_rsa.pub. While you can simply select the default, it might be a good idea to create a key file specifically for each project. That way, if your Mac workstation is ever compromised, you minimise the risk of access to servers used for past projects where your account has been inadvertently left active.
ssh-keygen will also ask if you want to set a password for the key. If you set a password, you’ll have to enter it every time you try to authenticate with the key file. 1
The result should be two new key files in your .ssh directory:
The public key: /Users/username/.ssh/yourkeyfile_rsa.pub
The private key: /Users/username/.ssh/yourkeyfile_rsa
If you use a service like GitHub you may also see your GitHub key files already in that directory.
C. Copy the public key to the server
Transfer your public key to the .ssh directory of the server account you use to do your day-to-day web development. There are two ways to do this on a standard-install Mac OS X workstation. You can follow these steps:
Go to the server terminal and cd into the account’s home directory.
Create a .ssh directory (~/.ssh/).
Switch back to the Mac’s terminal and copy the public key text using the command:
$ pbcopy < ~/.ssh/yourkeyfile_rsa.pub
Move back to the server terminal and create an authorized_keys file within the .ssh directory.
Paste the public key text into your authorized_keys file. (Remember that the pbpaste command won’t work on a non-Mac operating system.)
Alternatively, you can run the following command on your Mac’s terminal:
However it’s done, you should end up with a file ~/.ssh/authorized_keys for the developer account on the server.
It’s worth making this clear so there’s no confusion: you are giving the public key, yourkeyfile_rsa.pub, to the developer account that you’d previously been using to connect using a password. You should not be giving it to the root account. Make sure you put the authorized_keys file in the developer account’s home folder. Also make sure you don’t accidentally copy and paste the private key, yourkeyfile_rsa.
D. Test authentication to the remote server over SSH
Make sure everything worked by checking if you can connect to the server without having to supply a password. Log out of your existing connection on the server terminal and try connecting again:
The -i flag should be the path to the private key file we generated in step B. Also, if you set a key password, you will be asked to supply it before you can access the key.
You should see your server motd and terminal prompt after pressing enter.
E. Optional: disable password authentication
Since you’ve gone to the trouble of setting up SSH key-based authentication, you may want to disable password authentication after you’ve successfully testing the connection. Uncomment or add the following lines in /etc/ssh/sshd_config:
Finally, restart sshd:
# /etc/rc.d/sshd reload
Make absolutely sure that everything works before disabling password authentication, otherwise you may find yourself without any way to remotely connect to your server.2 Unscheduled trips to the data centre are no fun. (Can you tell I’m writing from experience?)
F. Optional: use a ssh config file
An option to save yourself some typing is to put the server and key details into an ssh config file. On your Mac terminal, create a config file at /Users/username/.ssh/config with the following:
This will let you login just by typing:
III. Setting up the Transmit FTP client for SSH Key-Based Authentication
After configuring SSH key-based authentication on your server, the SFTP service will start rejecting your login attempts unless you supply your key. Setting up Panic’s Transmit FTP client with key-based authentication is simple but it can be a little buggy.
In Transmit, delete your old connection details and add new connection settings 3
Leave the password blank
From the menu, select Favourites > Import SSH Key File
Or click the key picker, which is the key icon to the right of the password box
Import your private key file yourkeyfile_rsa
Connect with these new settings and the SFTP server will grant you access.
If you try this process with a password-encrypted key, Transmit will give you the error: “The file is not in a supported format.” This is a bug and you’ll have to apply a workaround. Panic’s customer support sent me the following instructions:
If the private key is passphrase encrypted (as yours is), or if it lives in a directory other than ~/.ssh/, there are a few extra steps needed to get up and running.
Instead of using the key picker, edit your ~/.ssh/config file and add the following:
Then set the site’s Password field to your key’s passphrase and try connecting.
Alternatively, you can try this method:
First, add the keyfile and password to your keychain:
ssh-add -K path/to/.ssh/yourkeyfile_rsa
Now add the connection details to Transmit but do not enter the password or set a key file.
Transmit will connect using the credentials in you keychain
In addition to being able to conveniently log in to your various servers, you will now also be able to use Transmit for your regular web development file transfers.
It’s tempting to think that setting a password for your key negates the whole point of this exercise. After all, if you have to enter a password to authenticate with the key file, you might as well keep the existing model of password authentication to the server, right? Not quite and here’s why: the ssh key is a cryptographically secure way of authenticating to your server and is exactly what you want for something accessible to the open internet. While manually typing in the key itself every time you want to open a connection isn’t practical, SSH key-based authentication handles key exchange automatically.
The key password protects against a different threat. It prevents unauthorised use of the key itself. This has a lower threat profile because it’s stored on your own private workstation. It therefore can be something that’s easier to remember and type.
Remember to backup your keys and store the backups in a secure location. If you lose your keys and have also disabled password authentication, you won’t be able to access the server without physical access or help from your hosting technical support.
I’ve found that editing a saved connection sometimes doesn’t work. This might be a bug in Transmit. Deleting the old connection and creating a new one seems to always work.
From time-to-time I get clients who ask me to only export the content to a WordPress database, after which they’ll complete the remaining setup themselves. If this applies to your project, you can use these migration notes to help get your new WordPress site running properly.
Import the database dump file
Please see these notes for importing the WordPress dump file.
Administrator credentials and email address
I will have changed your content management system (CMS) administrator password and email address to help with debugging. It’s important that you change these to your own as soon as possible.
Drupal and WordPress user passwords are encrypted so I won’t be able to view them. However, for your peace of mind, I recommend that you ask all your users to reset their passwords after your new WordPress site is live.
Please remember to change any database, (S)FTP, SSH server and control panel credentials you may have given me.
Migrating to a live server
I perform most Drupal to WordPress migrations on a development server. For help on how to move WordPress to your live server, please see: WordPress Codex: Moving WordPress.
Common errors after moving to a live server
Please see below for some common errors you may experience after migrating your new WordPress site to a new server.
Incorrect domain in URLs
WordPress stores domains in the database. If you performed the migration on a local or development server, there’s a good chance that the links will be incorrect after migrating to your live server. Use the Interconnect IT utility to run a search and replace on your database. This will also correct changed database prefixes.
“You do not have sufficient permissions to access this page”
If you receive this error after logging in to your new WordPress installation, it’s possible that the database prefix on your new WordPress site is not set correctly. This may happen if you move your WordPress installation to a host that uses a different database prefix.
Try running one of the queries below. Replace wp_new_usermeta, oldprefix_ and newprefix_ as appropriate.
UPDATE wp_new_usermeta SET meta_key = REPLACE(meta_key,’oldprefix_’,’newprefix_’);
UPDATE wp_new_options SET option_name = REPLACE(option_name,’oldprefix_’,’newprefix_’);
update wp_new_usermeta set meta_key = ‘newprefix_usermeta’ where meta_key = ‘wp_capabilities’;
update wp_new_usermeta set meta_key = ‘newprefix_user_level’ where meta_key = ‘wp_user_level’;
update wp_new_usermeta set meta_key = ‘newprefix_autosave_draft_ids’ where meta_key = ‘wp_autosave_draft_ids’;
update wp_new_options set option_name = ‘newprefix_user_roles’ where option_name = ‘wp_user_roles’;
Please note that these queries may not work for you. Success depends on your specific setup.
For more information, please see the following pages: