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. If you haven’t already read my Drupal to WordPress Migration Guide, I recommend you first head over there to get an idea of what’s involved. It can be tempting to get straight to setting up WordPress, trying out new themes and experimenting with plugins. Nevertheless, some basic preparation beforehand will save you lots of work.
Website owners and administrators know their content is important but it’s often treated as 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.
Avoid problems by planning 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:
If you haven’t already put together a migration requirements document, go ahead and create one now. I go through this migration requirements checklist with my own clients and it might help you too.
Step 2: Decide on your approach to building the WordPress theme
Just as in Drupal, the WordPress theme 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.
When looking for an SEO specialist, keep in mind that the techniques for migrations aren’t that much different from SEO considerations during a site redesign. At a minimum, you should be looking for someone who has good grounding in:
Technical SEO auditing: This is to give you a baseline of how the current Drupal installation looks from an SEO standpoint. These audits will help figure out how to recover if you see a drop in traffic after the migration to WordPress.
User experience (UX) optimisation: User experience is a big factor in SEO. A change in the site structure will almost certainly affect user experience.
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. My Drupal content audit checklist should get you started.
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.
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:
If you hired me to run a content export only, you’ll be responsible for setting up WordPress on your own server. Here are some notes to help you with importing the migrated WordPress database.
Import the database dump file
I will deliver either a MySQL database dump file or login credentials to the phpMyAdmin control panel for your project. The first thing you’ll need to do is import the WordPress database into your hosting environment.
Update the database for your domain
WordPress stores domain settings in the database. Since we run the migration and testing on a development server with a temporary sub-domain, you’ll need to update the settings to match your live domain. The easiest way to do this is to use a search and replace utility by Interconnect IT.
It’s pretty straight forward and only takes a few minutes. In the search and replace section:
Search for: the domain for your test server
Replace with: the domain for your live server
Change the login credentials
I use my own admin email address and password during the migration. For security, please change the administrator user details for your live site. After updating the domains, go directly to the login page to make additional adjustments.
username: [Your username]
password: [Your password]
Your temporary administrator username and password will be sent separately.
Set your WordPress theme
Set the WordPress theme to one that you have installed. I use one of the standard WordPress themes for the migration. However, if the new WordPress site isn’t set to use to a theme you have installed and configured, you may get a blank screen while browsing the site.
After logging in as admin, go to Dashboard > Appearance > Themes.
When migrating Drupal terms into WordPress, it’s important to understand exactly what terms are and how the two systems handle categorising information.
A primer on Drupal taxonomies
One of Drupal’s most powerful features is its ability to organise content with taxonomies. Unfortunately, the taxonomy system is also notorious as one of the trickiest things about Drupal for beginners to understand. You can find a more detailed explanation here but essentially, a taxonomy is the practice and science of classifying things. In content management terms, you would mostly use taxonomies to organise and categorise articles or posts.
Taxonomies in Drupal uses the concept of vocabularies and terms. Terms are just a list of words that describe a particular type of content. They’re grouped together into vocabularies, which can be thought of as ‘containers’ for a set of terms. Vocabularies may be assigned to any content type. Drupal allows you to arrange the terms within a vocabulary using a parent-and-child hierarchical structure or they can be a flat list, with each term being on the same level as the others.
You can have many vocabularies in Drupal, each containing any number of terms. Vocabulary names must be unique and you cannot have duplicate term names within a vocabulary. It’s possible, however, to have the same term name appear in different vocabularies. Fig. 1 shows an example Drupal taxonomy with three vocabularies, Music, Movies and Books. The Movies and Books vocabularies both have the term Sci-Fi.
WordPress’ system for organising content is simpler. You have the option of categories–which can be hierarchical–and tags which are flat, or non-hierarchical. In general, categories in WordPress are used as a way of broadly organising posts and tags are used for more detailed descriptions.
Unlike Drupal, where you can have many containers in the form of vocabularies, a standard WordPress installation offers one container for categories and one for tags. Also as standard, categories and tags can only be assigned to the WordPress post content type. A WordPress developer can extend this by creating custom content types with their own categories and tags.
Fig. 2 shows show you’d organise the Music, Movies and Books categorisation in WordPress.
Migrating Drupal terms as WordPress categories and tags
When running a Drupal to WordPress migration, we need to map Drupal’s more complex multi-vocabulary taxonomy system into the simpler WordPress model of categories and tags. How we do this depends on how you want to organise your new WordPress site. For example, we can:
convert Drupal vocabulary names into WordPress categories and Drupal term names into WordPress tags;
convert Drupal terms into WordPress categories and sub-categories;
vocabularies and their associated terms.
It’s all up to you and we figure this out during the requirements gathering stage of the project. For many sites, converting Drupal vocabulary names into WordPress categories and Drupal term names into WordPress tags, as shown in Fig. 3, seems to be the most sensible option. The important thing to know is that the migration may require us to ‘collapse’ or combine your taxonomies.
Since WordPress doesn’t support duplicate category or tag names, another thing to consider is how to handle any duplicate Drupal terms. Normally, the easiest solution is to append a unique number so that you can filter them out post-migration. We can do some clever merging and re-assigning of terms to posts but frankly, it’s probably not worth incurring the extra fees. Unless you have a great number of duplicates, you can probably do the job yourself quite easily via the WordPress Dashboard controls.
Organising your categories and tags in WordPress
Now that we know what’s involved in converting Drupal’s taxonomy over to WordPress, the next obvious question would be, “What’s the best way to structure categories and tags in WordPress?” While I cannot prescribe exactly how you should organise your site, I can point you to this excellent article so you can decide for yourself: Categories vs Tags – SEO Best Practices for Sorting your Content. Generally you should only have a few categories, maybe five or ten in total. Any more and they can become unwieldy and difficult to manage. These categories will reflect the main themes of your site. Tags can then further describe the details of each post and link specific topics together. You can have any number of tags.
The chances are that you probably want to avoid any drastic changes to the site structure when migrating from Drupal to WordPress. A simple mapping of vocabularies to categories and terms to tags is usually the closest equivalent in WordPress.
Privacy & Cookies Policy
Traffic analytics cookies help me improve my website. They don't give me any personal information about you but feel free to opt-out by adjusting the settings below.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.