How to fix a ‘Object of class WP_Error could not be converted to string’ error in WordPress

If you see a blank page while trying to log in to your WordPress site, check your web server’s error logs. You may get the following error:

stderr: PHP Catchable fatal error:  Object of class WP_Error
could not be converted to string in
/var/[PATH TO YOUR DOCUMENT ROOT]/wp-includes/default-constants.php on line 139

Note that the line number may be different depending on your version of WordPress but the code generating the error is as follows:

function wp_plugin_directory_constants() {
    if ( !defined('WP_CONTENT_URL') )
        define( 'WP_CONTENT_URL', get_option('siteurl') . '/wp-content');

Do not be tempted to debug by editing the code as it’s not the source of the error. Your problem will very likely be that the siteurl option value in your WordPress database does not contain a valid entry. In this case, the error message is telling you that get_option() receives a WP_Error object rather than a string that it’s expecting.

To fix this:

  1. First check the siteurl option to verify that the value is indeed incorrect. Run the following SQL:
    SELECT * FROM `wp_options` WHERE option_name = 'siteurl';

    You will likely find a serialized array containing a WP_Error object.

  2. Correct the option value by setting it with your domain’s URL:
    UPDATE wp_options SET option_value = '[YOUR URL]' WHERE option_name = 'siteurl';

I’m not sure what overwrites the siteurl option value. Most likely there is a misbehaving plugin installed or malware has infected your installation. Be sure to run a scan on your server.

How to fix https version of a site redirecting to the wrong domain

Some hosting providers restrict customers to a single SSL/TLS certificate per socket. (In simple terms, a socket is the combination of IP address and port number.) Since Apache listens to port 80 for non-SSL connections and port 443 for SSL connections on the same IP address, customers usually need a separate IP address for each certificate.

At the same time, you can configure Apache for multiple domains to share a single IP address using virtual hosts. Each virtual host gets its own port and Apache listens to this port, redirecting connections to the appropriate domain.

The combination of the above behaviours can sometimes cause complications when you install a single SSL Certificate on a shared IP address. Secure connections to port 443 of an IP address will be directed to the virtual host and domain assigned to that port. Thus, if you try to make a secure connection to a domain on a shared IP address, Apache will create a socket to the actual domain listening to port 443. Depending on your configuration, this domain may be a default virtual host or one that is explicitly set to listen to port 443.

The possible solutions depend on the types of configurations supported by your hosting provider. These include:

  1. Moving each domain with SSL certificates to its own IP address.
  2. Use Server Name Indication (SNI) to define separate SSL virtual hosts.
  3. Creating a default virtual host in your SSL file that does nothing but redirect to non-SSL connection.
  4. Installing a self-signed certificate on each domain name on that IP address.
  5. Making a different SSL host the primary certificate for the IP address.

Resources

How to fix ‘Error Code: 2013 Lost connection to MySQL server during query’

Content migrations usually involve running complex MySQL queries that take a long time to complete. I’ve found the WordPress wp_postmeta table especially troublesome because a site with tens of thousands of posts can easily have several hundred thousand postmeta entries.

If your query ends up taking more than a few minutes to complete, you may encounter the following error:

Error Code: 2013. Lost connection to MySQL server during query

This happens because the connection between your MySQL client and database server times out. Essentially, it took too long for the query to return data so the connection gets dropped. The MySQL documentation suggests increasing the net_read_timeout or connect_timeout values on the server. If this doesn’t solve the problem, you may need to increase your MySQL client’s timeout values.

MySQL Workbench

You can edit the SQL Editor preferences in MySQL Workbench:

  1. In the application menu, select Edit > Preferences > SQL Editor.
  2. Look for the MySQL Session section and increase the DBMS connection read time out value.
  3. Save the settings, quite MySQL Workbench and reopen the connection.

Navicat

How to edit Navicat preferences:

  1. Control-click on a connection item and select Connection Properties > Edit Connection.
  2. Select the Advanced tab and increase the Socket Timeout value.

Command line

On the command line, use the connect_timeout variable.

Python script

If you’re running a query from a Python script, use the connection argument:
con.query('SET GLOBAL connect_timeout=6000')

Drupal to WordPress migration consulting

Any Drupal version · All content · Custom content types · SEO · Plugins

Migrating a site from Drupal to WordPress and need a specialist? Please contact me for a quotation. Whether you’re a media agency who needs a database expert or a site owner looking for advice, I’ll save you time and ensure accurate content exports.

Get a quote

Post-migration troubleshooting: Gateway timeout when enabling plugins

Here’s one that caught me out on a recent Drupal to WordPress migration. As is common with my projects, there were three parties involved: the client, an external development team and myself. The WordPress site was first built on the development team’s server, after which it was migrated to my local environment. When everything was ready for beta testing, we moved the site over to the client’s staging server on a newly activated account over at Kinsta. Eventually, we’d move it over to a live server, also hosted on Kinsta.

Diagram of Drupal to WordPress migration workflow for this project

After some initial tests on staging, I found that deactivating and reactivating plugins would cause the site to hang and show a ‘504 Gateway Time-out’ error. This happened when re-enabling some but not all plugins.

I initially suspected some misconfiguration at the hosting end because there were some hitches with the newly create account. At the outset, the account’s server had an issue which Kinsta support needed to fix. For convenience, we’d also made use of Kinsta’s free site migration service. This is where they’ll migrate an existing WordPress site into their environment. Though it would have been easy enough for me to do, we thought to give it a try. In hindsight, this was a bit of a mistake. The site migration service itself was fine but it did end up causing some confusion. First, a miscommunication in the migration request caused them to create a temporary domain we didn’t want. They helpfully solved this by giving us a second temporary domain. However, they’d also upgraded everything to PHP 7 in the process. All of these issues were possible suspects for the time-out error but turned out to be red-herrings.

It took some time to pinpoint the cause behind the Gateway Time-out error. I do have to say that Kinsta support were very responsive throughout the troubleshooting process. They eventually put a senior engineer on the case who found the problem. It turned out the problem wasn’t to do with Kinsta at all. There was a leftover setting from the original development team’s server server. It was a valid format so didn’t cause an issue on either my local server or my staging server. However, it apparently can cause issues with plugins and did on the Kinsta environment.

What was the setting? The WordPress upload path directory was set to the development team’s server path e.g. /home/dev/public_html/sitename. Throughout the migration, I’d been doing a database search-and-replace looking for their development domain. Somehow, as the site moved from different servers, that server path string remained in the database, only to cause a problem when the site landed in the destination server on Kinsta.

I’m not sure if there would have been any way to have caught this problem earlier. It’s one of those obscure errors that are easy to overlook and take time to resolve. There’s also no practical way to do a database search-and-replace for every imaginable string. I’ll have to rack this one up to experience.

Post-migration troubleshooting: WordPress redirects to old site after updating database

If you’ve ever migrated a WordPress site, either to another URL or for a Drupal to WordPress migration project, you’ll know that WordPress stores the domain name in its database. This means you’ll have to jump through some hoops when moving WordPress to another environment. A critical step is to update the database to reflect the new domain. My favourite tool for this used to be the database search and replace script from interconnect/it. The script is PHP-based so runs on all environments that host WordPress. I now prefer WP-CLI’s wp search-replace command when on my own development environment, or for client hosting that supports it. Nevertheless, interconnect/it’s tool is still my fall-back option for clients of my Drupal to WordPress migration service since many use hosts that don’t offer command-line access.

In nearly all cases, updating the siteurl and home fields in the wp_options database table achieves the bare minimum to get the site working after migration. Running a search-and-replace across the WordPress database (in particular, the wp_posts table) will resolve broken links containing absolute URLs.

wp-admin still redirects to the old site after updating wp_options?

Once-in-a-while, I’ll encounter a migration project where wp-admin still redirects to the old site even after running through the obvious steps of:

  1. updating the database;
  2. clearing the browser cache;
  3. clearing the server cache.

It happens very rarely so I have yet to discover the cause. I suspect it’s something to do with sites that had a caching plugin installed, such as W3 Total Cache.

If you ever find yourself in this situation, the best workaround is to add the following two constants in wp-config.php:

define('WP_HOME', 'http://' . $_SERVER['SERVER_NAME']);
define('WP_SITEURL', WP_HOME . '/');

This isn’t a nice long-term solution but it should at least enable you to log in for some basic site administration. Once you’re able to log in to the WordPress Dashboard, disable any caching plugins after first clearing their cache.

Importing a WordPress database: How to fix the Unknown collation: ‘utf8mb4_unicode_ci’ error

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

  1. Log in to your database server using phpMyAdmin
  2. Make sure you select your database and go to the “Export” tab
  3. Select the “Custom” radio button
  4. Go the section “Format-specific options” and in the setting for “Database system or older MySQL server to maximize output compatibility with:” select MYSQL40.
  5. Scroll to the bottom and click GO.

phpMyAdmin format specific options to fix the Unknown collation: 'utf8mb4_unicode_ci' error

Other possible solutions include:

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 older utf8 Drupal database to a newer utf8mb4-supported WordPress database. In this case, your old content will not have characters that will cause a problem after an encoding downgrade.

Post-migration steps: what to do after a Drupal to WordPress migration project

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.

Server credentials

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.

More information can be found on the interconnect/it Search Replace DB page.

“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.

Option 1:

UPDATE wp_new_usermeta SET meta_key = REPLACE(meta_key,’oldprefix_’,’newprefix_’);

UPDATE wp_new_options SET option_name = REPLACE(option_name,’oldprefix_’,’newprefix_’);

Option 2:

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:

Further help

I’ll be very happy to provide support you if have difficulties after migration. For a quotation, please contact me. I also offer customised hosting and maintenance packages. Please ask for details.

Handling Drupal terms during a Drupal to WordPress migration

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.

An example of Drupal vocabularies and terms
Fig 1: Drupal vocabularies and terms

For more information about the Drupal taxonomy system, please see Organizing content with taxonomies.

WordPress categories and tags

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.

WordPress categories and tags
Fig. 2: WordPress categories and tags

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.

Merging Drupal and WordPress taxonomies
Fig 3: Merging Drupal taxonomies into WordPress

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.

Why is the Drupal term_node table missing?

In a Drupal to WordPress migration post by Sam Michel, reader Jean-Philippe commented that why he couldn’t find the tables mentioned. I started composing my reply but for some reason the page wouldn’t let me post.

Rather than waste the time it took to compose the reply, I thought it would be good to post it here instead.


Hi Jean-Philippe,

This probably isn’t relevant to you anymore but I’m posting this for the benefit of anyone else who stumbles across your comment.

The tables names have changed in Drupal 7. ‘taxonomy_term_data’ and ‘taxonomy_term_hierarchy’ are all Drupal 7 tables. If you don’t see the tables mentioned in this post, it’s almost certainly because you don’t have Drupal 6 installed.

In Drupal 7, ‘term_node’ has been replaced with ‘taxonomy_index’.

I’ve started documenting the table mapping between Drupal and WordPress in a series of posts here: https://anothercoffee.net/drupal-to-wordpress-migration-posts-table-mapping/

Since I also used Scott Anderson’s SQL, anyone reading Sam Michel’s series might find it useful too. (Thanks to Sam and Scott!)

Drupal to WordPress migration notes

These Drupal to WordPress migration notes are intended for clients who are handling some aspects of the migration themselves. Users of the Drupal to WordPress Migration Tool or MySQL queries might also find information here to resolve some problems.

Admin account password and email address

Your content management system (CMS) administrator password and email address may have changed during the migration to help with debugging. Please update them as soon as possible.

Drupal and WordPress user passwords are encrypted and I do not have access to them in plaintext. However, for your peace of mind, I recommend that you also ask all your users to reset their passwords.

Server credentials

Please remember to change any database, (S)FTP, SSH server and control panel credentials you may have given me.

Working tables

During the migration process, I may create some working tables to hold temporary data. My naming convention for the working tables are as follows:

  • acc_ prefix: these are working tables created to help with migrating data.
  • backup_ prefix: these are backups of existing tables prior to migration, for example from a previous installation of your CMS. These will not be altered during the migration process.
  • _copy postfix: duplicates of WordPress tables copied for debugging will have a _copy postfix. These are different from the backup_ tables in that they may have been manually altered.

These working tables are not used by WordPress so you may safely delete them. However, it’s advisable to keep them for a short while as they may be useful in case we need to debug any issues that crop up.

Migrating to a live server

Most Drupal to WordPress migrations are performed on a test or development server. For help on how to move WordPress to your live server, please see: WordPress Codex: Moving WordPress.

Troubleshooting common errors after a site migration

Please see below for some common problems you may experience after migrating your Drupal content to a new WordPress site.

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.

More information can be found on the interconnect/it Search Replace DB page.

“Sorry, you are not allowed to access this page”

If you try to log in via wp-admin and receive this error, you may have overwritten the administrator user’s wp_capabilities or wp_user_level.

Set the correct meta_value using the following SQL:

UPDATE wp_usermeta 
    SET meta_value = 'a:1:{s:13:"administrator";s:1:"1";}'
    WHERE user_id = 1 AND meta_key = 'wp_capabilities';

UPDATE wp_usermeta 
    SET meta_value = '10'
    WHERE user_id  = 1 AND meta_key = 'wp_user_level';

Remember to use the appropriate the user_id.

“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.

Option 1:

UPDATE wp_new_usermeta SET meta_key = REPLACE(meta_key,’oldprefix_’,’newprefix_’);

UPDATE wp_new_options SET option_name = REPLACE(option_name,’oldprefix_’,’newprefix_’);

Option 2:

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:

“Unable to establish database connection”

The database credentials are correct but you see an “Unable to establish database connection” error. Check that wp_options table is not empty.

Allowed memory size exhausted

  1. Increase php.ini memory size
  2. Increase WP settings memory limit with:
    define(‘WP_MEMORY_LIMIT’, ‘128M’);

Post migrated but navigating to post shows blank page

The post is visible in the dashboard but viewing it displays a blank (but themed) page. Manually saving it on the dashboard makes it appear.

It’s possible that the problem posts need to be assigned to a category.

Post migrated but navigating to post shows ‘Not found’ error

The post is visible in the dashboard but viewing it displays a ‘not found’ error. Manually saving it on the dashboard makes it appear.

  1. Check that the url contains valid characters for a WordPress slug.
  2. Check that .htaccess is enabled in your Apache configuration

Link to author 404

Posts exist but link to the author’s post listing page is broken.

Check user_nicename in wp_users WordPress table. Make sure the nicename doesn’t contain invalid characters such as spaces, periods.

Dashboard controls not visible after logging in

If you are able to log in as an administrator user but do not see the Dashboard controls, check your table prefixes. If the table prefixes changed during the migration, you may have forgotten to update the options and usermeta tables.

Check where the old prefixes have been set:

SELECT * FROM `wpnew_options` WHERE `option_name` LIKE '%wp_%';
SELECT * FROM `wpnew_usermeta` WHERE `meta_key` LIKE '%wp_%';

Updated the prefixes. For example:

UPDATE `wpnew_options` SET `option_name` = 'wpnew_user_roles' WHERE `option_name` = 'wp_user_roles';
UPDATE `wpnew_usermeta` SET `meta_key` = 'wpnew_capabilities' WHERE `meta_key` = 'wp_capabilities';
UPDATE `wpnew_usermeta` SET `meta_key` = 'wpnew_user_level' WHERE `meta_key` = 'wp_user_level';

UPDATE `wpnew_usermeta` SET `meta_key` = 'wpnew_user-settings-time' WHERE `meta_key` = 'wp_user-settings-time';
UPDATE `wpnew_usermeta` SET `meta_key` = 'wpnew_user-settings' WHERE `meta_key` = 'wp_user-settings';

Further help

We’ll be very happy to provide support you if have difficulties after migration. For a quotation, please contact us. We also offer customised hosting and maintenance packages. Please ask for details.