Sometimes you need to replace a string in your database with another string, and it can be rather tedious to plough through a large table manually. Thankfully MySQL can execute raw queries such as find and replace.
This comes in handy if you’ve moved a WordPress installation to another URL: you only need to tweak two values in the options table, but there may be countless image references and links in the posts and options table too. That’s where find and replace can come in handy.
You can execute the following statement either on the MySQL command line, or use phpMyAdmin’s Raw SQL option:
That big text field is where we’ll use the following code. Before we do however, make a backup of your database because there is NO UNDO FUNCTION in MySQL. A cute typo can break things beyond repair!
Here’s what the find and replace statement looks like in principle:
update table_name set field_name=replace(
For WordPress specifically, if you’d like to replace text strings inside posts and pages, then wp_posts would be your table, and field_name is the column of that table. So for wp_posts this will be post_content. You can see the field labels at the top of each column when you select a table.
To replace a URL in all posts and pages the statement would look like this:
update wp_posts set post_content=replace(
As soon as you hit GO, MySQL will go to work and show you a success or failure message. The above would replace all image references and links from your old domain to the new one, where WordPress is installed in a subfolder.
Make a note of your table prefix and replace it accordingly. wp_ is the default, but this can easily be changed into something else for security reasons. Be cautious of trailing slashes when you’re replacing URLs.
Also note that a small letter “l” and a capital “I” look surprisingly similar in the phpMyAdmin! If you keep getting errors like “this table does not exist”, it’s something to watch out for before questioning your sanity again 😉
Replacing URL strings in WordPress
I use this technique when I need to replace URLs across an entire WordPress installation. Those can hide not only in posts, but also in widgets and menus. Here’s a list of places to hunt for them:
wp_posts table, in the posts_content field (links inside posts and pages)
wp_links table, in the link_url field (the old Link Manager)
wp_postmeta table, in the meta_value field (URLs of Custom Menu items)
wp_options table, in the option_value field (anything saved by themes and plugins)
wp_comments table, in the comment_content field (URLs inside comments)
And while we’re talking about replacing URLs: if you need to change the root URL of a WordPress installation, this is done in wp_options too. Look for two values called siteurl and home.
You can move databases and database users between subscriptions in Plesk. There’s no web interface for this, but with a bit of manual database tweaking you’ll soon get the hang of it.
I recently split a subscription into two for a client and this trick came in handy.
Before we begin, make sure you backup the psa database – that’s what Plesk uses to keep track of internal values, anything from user names, passwords, and which service is associated with what. If you ruin psa you’ll ruin your Plesk installation. Use caution!
You can use phpMyAdmin from Plesk to edit the psa database. Head over to Tools and Settings (or the Server Tab), Database Servers and click the little wrench icon. This will open phpMyAdmin in a new window.
Find the psa database and click on the little disclosure plus icon. This will show you all its tables, similar to this:
Scroll down to find data_bases and db_users. Open either of them (with the little disclose icon again) and you’ll find a list of databases and users respectively. Note the column dom_id. This is how Plesk knows which subscription (or domain) this database belongs to. MySQL takes care of the actual database, the value here is for visual representations in Plesk only.
The difficult bit is to find out which numeric dom_id translates into which domain. There’s not an easy way to extract that info from Plesk, so we’ll use a quick workaround: create a new identifiable database (and user) in the subscription we’d like to move to and simply look at which dom_id it gets.
Creating a Dummy Database
Back in Plesk, head over to the subscription you’d like to move your database to and create a memorable user/database combo. Anything will do, we’ll delete this later. Call it “aaaaaaaaa” or “comehere” – up to you.
Once done, head back over to psa database in phpMyAdmin, refresh and look at the data_bases (and db_users) again. You’ll see something like this:
Now we know that our important_database (and important_user) need a dom_id value of 2 instead of 1. Change it in both tables – and you’re done!
Head back into Plesk and check your subscriptions: the database and user will have disappeared from subscription 1 and will now appear in subscription 2.
Sometimes you need to change some text in a MySQL table. For example, imagine you want to correct a spelling mistake or a reference in all your WordPress posts without having to change them one by one.
Here’s how to do it with a raw SQL command. This works only on a single table – repeat this for each table:
Note the use of standard ticks and back ticks here. First we’ll select the table in question (in this case wp_posts), then we’ll issue the find and replace query by selecting the column in the table (post_content), followed by the replace command.
As soon as MySQL comes back all references will have changed from “Old Text” to “New Text”.
Careful here: there is no undo function! Once executed, all changes are live instantly. Make a backup copy of your database before you do anything!
You may have noticed that there is no MySQL root user on servers running Plesk. That’s because Plesk renames this user into “admin” by default – for security reasons.
The password for the admin MySQL account is the same as for the Plesk Panel admin account.
Even so, when you try to login to MySQL – remotely or locally – you may be puzzled to find that your admin password doesn’t seem to work. Let me assure you of your sanity and your keyboard skills: it’s because Plesk encrypts the password in the database.
It is the encrypted version that you must present to MySQL, not the clear version. For example, if your password was indeed “password”, then the following command will not grant you access to MySQL:
You can check your unencrypted password by issuing the following command (on Linux servers):
In our example, it will indeed show “password” – so why doesn’t it work? It’s because that command will unencrypted the password for us. MySQL however needs the encrypted version. Here’s how we can extract this from Plesk:
Sometimes things don’t work out with replication. When I first started experimenting with it I thought this was a “setup and forget about it” kind of job.
Experience has shown though that you have to regularly triple check and see if things may have broken (despite a good and once working setup).
Let’s take a look at what you can do when your Slave isn’t replicating anymore. If you want to know more about how to setup replication, have a look at my previous article in which I explain how this works.
This is a step-by-step guide on how to replicate an existing MySQL server. The server is live and contains data and needs a constant backup companion.
Many tutorials focus on how to setup replication when no data is present on the system. That’s an ideal solution if you’re building a new setup, but in case you’ve got a server that already has data present then here’s how to accomplish the this:
setup your existing MySQL server (with data) as a Master
export all your databases and user accounts
create a slave and import all your data
I’ve done this several times and always forgot to take some notes – until today. Without further ado, let’s replicate MySQL.
Usually deleting several posts at once is not a problem thanks to the bulk delete options in WordPress. Those queries however rely on a single delete each, initiated by PHP loop. That’s fine if you’re deleting up to about 100 posts at a time.
But it’s not when you have thousands of posts to delete. I’ve come across installations with hundreds of thousands of posts which have often been created automatically – and there comes the time when you need to clean things up and prune that massive database.
Deleting 100.000 posts is impossible from within WordPress: it puts a huge load on your server, it takes forever, and besides WordPress will time out after about 200 posts.
The solution: a dedicated SQL query.
Sounds scary I know – let’s go through it step by step in this article.