Tag: ClearDB

How to Migrate a WordPress site to Azure Using In-App MySQL

Published October 25, 2016

Did this site load a little faster than it normally does? You may not have a basis of comparison, but I have noticed that pages load between 2x and 5x faster since I moved the site to Azure hosted WordPress using an In-App MySQL database. Previously I was running it on Azure as well, but it was using the 3^rd party ClearDB database server. The performance increase is therefore entirely due to the difference in the database engines.

I have been running this blog as a web app on Azure for the last couple of years, ever since it became available. In fact, I wrote about how to enable hosting for multiple users on the same database when I first set it up. At the time, setting up a WordPress web app involved also provisioning a MySQL database through a third-party hosting provider, Clear DB. The initial offering was free, but as I quickly found out, the initial offering also doesn’t provide much, and I needed to upgrade it through the third party. This arrangement was fraught with difficulty. Aside from the unwelcome additional costs, managing the billing cycle was difficult. In addition, all my WordPress sites were a little to a lot sluggish, and increasing Azure resources didn’t seem to help much.

Over time, I learned that I wasn’t the only one, and the performance problems seemed to be with latency between Azure and the third-party provider. However, I didn’t want to start messing around with standing up my own, and it was usable if a tad expensive. However, a month or so ago I was listening to my friends Andrew Connell and Chris Johnson on the Microsoft Cloud Show, and they mentioned that Azure had put out a preview of a native MySQL implementation. This was of course music to my ears, so I tried it out, and it appears to work quite well.

I have since moved all our WordPress properties over to this new architecture, and documented the procedure. The approach that I tool should work for any WordPress site, whether it is hosted on Azure or not, but the examples I use will of course be going from Azure to Azure. I essentially create a new WordPress site, migrate the site assets to it, configure the new site to match the old one, then point the address to the new web app. There are quite likely third party add-ons that facilitate this process, but this process is manual. I am in no way saying that this approach is a best practice, only that it worked for me. Finally, as noted above, the In-App MySQL is in Preview, not production, so if your WordPress site is critical, it would likely be a good idea to hang on for a bit. I however like to live dangerously, and if my blog goes offline for a few hours, it’s not the end of the world.

Here are the steps required to accomplish this.

1. Upgrade the existing site

The new site that will be created will use the latest version of WordPress, and any plugins that get installed will also be the most recent. To avoid any version mismatches, it’s a good idea to make sure that your WordPress version, and all your plugins are up to date.

2. Retrieve the WordPress Assets from the existing Site

You can use the built-in export feature in WordPress to retrieve all the database assets. Open the tools section, select “Export”, and choose “All Content”.

The types of content will vary depending on your WordPress installation, plugins, etc., but make sure that you select all of them. When ready, select “Download Export File”. You’ll get prompted to download an XML file – put it somewhere safe – you’ll need it later.

Next up, you’ll want to retrieve your file system based assets. These will be all your uploaded files, unless you currently use and externally hosted provider, your WordPress themes, and your plugins. Strictly speaking, this step isn’t necessary. You should be able to re-download your themes and plugins, but I have found that they aren’t always available, and that this process is faster. However, if you don’t have access to the file system of the existing site, you may not be able to do this. The upload files can be gathered through the import process later as well, but this approach provides an added level of safety.

For Azure, you’ll use FTP to connect to the file system and copy the files locally. For Azure hosted sites, you can set the FTP credentials by logging into the “new” Azure portal, selecting the web app for your site, then navigating to “Deployment Credentials”. You then enter a user name and a password, and save them.

Next, scroll down to “Properties” for the web app, and take note of the “FTP Host Name” and the “FTP/Deployment user”. You will use these values to connect to the file system.

Now open Explorer on a Windows PC, right click in the “This PC” node, and select “Add a network location”.

Follow the prompts entering the FTP host and the user name when prompted. Do not attempt to log in anonymously. Also, take note – the user name has the form web app name\username. When the node opens, enter the password, and you should see 4 folders. Open “site”, then “wwwroot”, and finally “wp-content”. The folders that you need are here.

Specifically, you are looking for the plugins, themes and uploads folders. Copy these folders locally and keep them handy.

3. Create the new WordPress Site

From the Azure admin portal, select “Create New”, and search for “WordPress”. There are several WordPress options to choose from, but the one we’re pursuing is published by WordPress.

Once selected, you will be prompted to fill out the details. Give the new app a name, select the Resource Group, and most importantly, the Database Provider. ClearDB is the one that we are moving away from, so “MySQL In App” is the one that we want to select.

Once you click OK, the App will be created, and WordPress will be deployed to it. The App creation happens almost immediately, but it takes a few minutes for WordPress to be fully deployed. Don’t be alarmed if there’s nothing there for a little while.

Once deployment is complete, you can simply click on the URL of the app in the “Overview” section. The URL will take the form of http://webappname.azurewebsites.net.

A browser will open and you will be prompted to complete the initial WordPress installation. One that complete, you will be able to login to the WordPress administration portal.

4. Upload the Older Assets to the new WordPress Site

The next thing that we want to do is to upload the assets that we downloaded in step #2 to the new site. To do this, simply connect to the new file system via FTP by following the same steps that were used to connect to the old site in step #2. Once connected, upload the 3 folders to the wp-content folder of the new site. If there are folders that already exist, or that you don’t want to use in the new site, simply omit them from the upload. Once uploaded, we can activate the features.

5. Activate Assets in the New Site

It is important to activate and configure the plugins before the content from the existing site is imported. This is because some plugins extend the schema of the WordPress database, and any content that depends on those schema extensions will fail to import if they are not present.

Login to the administrative portal in the new site, and activate all the required plugins. If you don’t know which plugins should be activate, simply login to the administrative portal of the old site for reference. It’s a good idea to have these portals open side by side as you complete the next few actions. Once the plugins are active, go to the appearance section, and select the same theme as the original. Once the theme is selected, it needs to be configured. Walk through all the configuration options for your theme matching with the original site. Any options that depends on content will need to be set after the content is imported. Once the theme is configured, the plugins should all be configured. This is a very manual process of going through all the configuration screens and comparing the settings to those of the existing site.

Finally, recreate all necessary users from the old system. You will need to match blog posts with authors during the import step. The import step will offer another opportunity to add new users, but it’s a good idea to do this prior so that complete information is added for each user.

6. Imports Content from the Existing System

From the administration portal of the new WordPress site, navigate to the Tools section, and select import. A number of options will be presented, the option that you’re interested in is “WordPress”. If you don’t already have the WordPress Import Plugin, you’ll need to select “Install Now” and allow the plugin to install and activate. Once activated, select “Run Importer”, and the Import dialog will appear. Select the export file that was downloaded in Step #2 above, and then click the “Upload file and import” button to see the Import WordPress dialog.

WordPress Import is author aware, and will automatically assign posts to users that exist in the new environment based on who they were in the old, you simply need to map them at this point. If you forgot to add a user in Step #5, you can do so here as well. Once authorship is assigned, the only other decision is whether to select the “Download and import file attachments”. Strictly speaking, if all assets were brought across in step #2, this shouldn’t be necessary. What this option does is to download all referenced assets from the existing blog during the import process. This doesn’t always work, particularly on larger blogs, which is why step #2 is so important.

In addition, if the content of the site results in a particularly large export file (as was the case with this one), you’ll need to increase the upload limit for your WordPress site. This can be done by creating a “.user.ini” file in the root of your WordPress installation as described here. Additionally, you may also need to increase some of the application timeout values.

7. Test

Test the new site to ensure that it works. This cannot be stressed enough. Open all the sections to ensure that everything looks right. Ideally, use browser windows open side by side with the new and the existing sites

8. Make URL Changes to the Existing WordPress Site

It is important to follow these steps to avoid being locked out of the existing site. There are ways to correct it if it happens, but the situation is beast avoided.

Open the administration portal of the existing site, and navigate to “Settings”, General. If the WordPress Address (URL) and the “Site Address (URL)” values do not match the default URL for the Azure Web App, they will need to be changed to that value here.

The address will take the form http://azurewebappname.azurewebsites.net. It’s also a good idea to navigate to that URL to ensure that it works before saving.

8. Make URL Changes to Azure

If your existing site isn’t running on the default Azure address, you’ll need to repoint it to the new site. This will cause your site to be unavailable for a few moments. To begin, you need to remove your custom domain from the existing (now “old”) site. Navigate to the Web App for the old site in the Azure portal, and select “Custom domains”. Your custom domain should appear there along with the default address (that was used in step 8).

Click on the ellipsis beside the domain, and select “Unassign”. This will remove the custom address from the old site, freeing it up to be used by the new site.

At this point, you will need to make changes to your domain with your domain registrar. You will need to change any references (A records and/or CNAME records) that you currently have for your custom address to point to the new Azure Web App. Details for those settings can be found under “Custom domains” for your new Azure Web App. Once complete, navigate to “Custom domains” in the new Web App and click on the “+” button beside “Add hostname”. Enter your custom address and the click the “Validate” button. The custom address will be tested, and if there are any issues with it, remediation steps will be provided. The Azure portal is quite good at helping to manage this step.

Once the new URL has been registered, it should be tested to ensure that it is accessible from the outside environment. Prior to testing, the old site should be stopped (but not deleted!) to ensure that it is not responding to any requests.

If SSL was used on the old site, at this point they should be brought in to the new Web App and bound to the site.

9. Make URL Changes to the New WordPress Site

If the custom domain is working, follow the steps in step 7, but on the new WordPress site, and use the custom address for the URL values. Save, and login again.

10. Final Testing

At this point the site is live, but it is worthwhile to do another round of testing with the old Web App in a stopped state. This will identify any URLs hardcoded with the old Web App default URL, and missing assets, etc.

At this point, the new WordPress site is set up and working with the In-App MySQL database. I would recommend waiting a week or so before going back and deleting the old site and its assets, just in case.

8 Comments

Using Multiple WordPress Blogs with Azure Web Sites

Published January 23, 2014

This will be one of my more “meta” posts. Blogging on WordPress discussing blogging on WordPress.

In addition to this blog, my company, UnlimitedViz has a number of active bloggers, The Data Queen, and The Data Model chief among them. We all use WordPress for this purpose, primarily because of its ease of use, and ecosystem of useful add-ins. It’s a PHP application that is (normally) backed by MySQL. UnlimitedViz is a Microsoft shop, so these tools are relatively foreign to us, and Azure is Microsoft’s cloud platform. Notwithstanding that, Azure is an excellent platform choice for us to deploy WordPress, due to its low cost, its WordPress support, and our existing investment in the platform.

I had originally deployed my WordPress blog on Azure back in early 2011 when Azure was really just a rudimentary Platform as a Service product, and wrote about it here. However, I was cheating a little bit, customizing a stateless worker role in as stateless a manner as I could, but it still came back to bite me, and ultimately, I moved my blog over to Rackspace, and then back to Azure, but in an Azure Virtual Machine (IAAS).

When Azure web sites were announced, with direct support for WordPress, I was intrigued. Creating one allows you to create a corresponding, hosted MySQL database (hosted by ClearDB). Unfortunately, each Azure subscription is restricted to a single MySQL DB, and I needed to host multiple blogs with one subscription. I finally got around to looking into this recently, with happy results.

WordPress supports multisite blogs, and the Azure team has some good guidance on how to enable this. However, upon trying this, I quickly determined that this would be a non-starter for us. The WordPress multisite option isn’t supported by some plugins, requires a single master administrator, and requires that all blog owners use the same set of plug ins. Now if there is one word that could describe every UnlimitedViz team member, it’s independent.

What I needed was a way to support multiple WordPress instances with one subscription, one database, and a minimum of administrative overhead. Luckily it’s relatively easy. The trick is to use different table names in the MySQL database for each blog. Below is a step by step example of how to do this.

To begin, all of our blogs are domain oriented, not path oriented. As an example whitepages.unlimitedviz.com vs blogs.unlimitedviz.com/whitepages. In this example we’ll add a new blog with the URL newblog1.unlimitedviz.com to our Azure subscription. The process for creating the first blog is identical to the addition of a new one, with the exception that a new database is created instead of connecting to an existing one.

Step 1 – Add a new Azure Web Site

From the Azure management portal, navigate to Web Sites, select New, Web Site, From Gallery.

Scroll down to the bottom of he gallery, and find WordPress. Select it, and press the next arrow.

Next, fill in the information about your new blog. The deployment settings will be used by PHP to communicate with MySQL, and will be largely invisible after initial setup. Your new blog will also have a .azurewebsites.net domain. We will substitute (or add) our own later. For now, our new blog will be newblog1.azurewebsites.net, will use an existing database, live in the North Central US data center, and use our corporate subscription.

When ready, click the next arrow. If I was creating the first (and only) database, I would be able to give it a name and create it here. As it is, we can select our existing database, agree to ClearDB’s terms of service, and select the “done” check mark.

At this point, the web site will be created. Once done, it is possible to navigate to the URL, and set up WordPress, but we need to make an additional modification first.

Step 2 – Specify the Table Prefix

In order to tell this particular WordPress instance which tables to use in the database, we need to modify the wp-config.php file in the web root. How do we do this? We have a few options. We could use FTP to download the file, edit it, and send it back up (FTP settings are under the Dashboard tab for the web site).

We could also use GIT, but as I’m unfamiliar with it, I’ll let more GIT friendly folks sort that out as they wish. My preferred option is to use Webmatrix, which allows the direct editing of Azure Web Sites. Webmatrix is available from the bottom tools ribbon wherever a web site is selected.

If Webmatrix has already been installed, it will launch, and if not, you’ll need to install it first. Your first option will be its operation mode, either direct, or off-line. We will select direct.

Next, we double click on the wp-config.php file. This will open it in the editor. Now we scroll down to the line for $table_prefix, and edit it as appropriate, in our case “newblog1_”.

Finally save the file and close Webmatrix. Now when the WordPress configuration wizard is run, it will create table in the database that are prepended with “newblog1_”, and use them thereafter. The configuration wizard runs whenever WordPress can’t find the specified tables in the database

Step 3 – Configure WordPress

Next, we navigate to our URL, where the WordPress configuration wizard will go ahead and complete our setup. In our case, we navigate to newblog1.azurewebsites.net, and fill out the form.

When ready, click on the “Install WordPress” button. Once done, we log in and start building out the blog. That’s really all there is to it from the blog perspective. However, there’s likely one more important thing that we need to do.

Step 4 – Activate Your Own URL

In all likelihood, you don’t want to use azurewebsites.net in the domain of your new blog. We could use a DNS alias on our DNS to reroute traffic, but Azure won’t answer any requests that it isn’t expecting. We must first register our custom domain with the Azure web site, and this is only possible with Shared or Standard web sites. New sites get created in free mode, so we need to first switch the compute mode. Keep in mind that we’re switching away from free, so charges will accrue.

To switch modes, from the Azure Management Portal, click on the web site in question, then click the Scale tab. Under general, select on either “Shared” or “Standard” (shared is cheaper), and click save at the bottom of the screen.

Once you accept the disclaimers, the mode changes, and we can add our domain. However, before we do, we need to make a DNS change. Azure won’t allow you to add just any domain, it needs to know that you own it. To do so, you need to add an alias (CNAME) entry that points from a verification subdomain (awverify) to a verification subdomain of our web site. In our case, the entry is awverify.newblog1.unlimitedviz.com and it points to awverify.newblog1.azurewebsites.net.

Honestly, this is the biggest pain of the entire exercise. The effect of the change is not immediate, and after making the change, you may want to take a break for a while. According to the UI, there are also apparently other aliases that can be used for this purpose, but this is what works for me.

At this point, we can add the domain to the Azure web site. To do so, we open the Azure admin portal, and open the definition for the web site. Next, we click on the Configure tab, scroll down to the domain names section, and click the “manage domains” button.

In the dialog that pops up, enter your custom domain name

If your verification alias was properly set up, and all is well, you will receive a green check mark status indicator. If not, it will be a red x, and you will need to fix the problem. It could be a misspelled name or just no verification result. However, if all is well, make note of the IP address for your A records, and click the check button to save the configuration.

Finally, we add an A record to our DNS that points our custom domain newblog1.unlimitedviz.com to the IP address noted just above.

That’s it. Taking this approach, we can have multiple, independent WordPress blogs sharing a single Azure subscription and a single MySQL database.

This is the current setup for all of the UnlimitedViz blogs. There are, however a couple of caveats, that you should be aware of.

Caveat Emptor

Once you go ahead and allow WordPress to run its configuration wizard, it creates its table in the database. If you remove the web site, the underlying tables remain in the databases. This is either good or bad, depending on your perspective. If your website gets deleted, the data persists, and its simple to connect back to it, just like SharePoint. However, if you need to clean out the database, it’s pretty much impossible.

Thus far, I haven’t found any good way to manage the database directly. However, I haven’t looked very hard, as I haven’t needed to, and that’s a good thing.

The one thing that you should certainly be aware of if you’re going to be doing this to any sort of scale, is that the MySQL database that is created automatically is restricted to 20MB of total size, and that’s a limit that you will run into fairly quickly. I certainly never saw any indication of this limit while I was building the environment, but then, I never read any of the terms and conditions. Really, who does? The good news is that it can be upgraded.

The day after moving our blogs to this platform, I received an email from ClearDB stating that I was near my storage limit, and should consider upgrading. The email didn’t indicate how this could be done, so I navigated to the ClearDB site. Since there was a login button I used it, and entered the email that I use for my Azure subscription. Unfortunately my password didn’t work. Creating a MySQL database creates a ClearDB account, but I have no idea what password it uses. Using the “Lost Password” worked, but I was still unable to log in. Finally, I logged a support issue with them using the provided support form. Very quickly, my account was enabled for “direct login” which is what was necessary, and allowed me to upgrade the database to a greater capacity. The plan that I opted for was $9.99/month, and allows up to 1 GB of space, which is plenty.

There was one other bump that I had to overcome. I was migrating existing blogs, and to do so, I used the export and import features that are a part of WordPress. The export feature downloads an XML file with all of your blog content. Supporting images are not included (they are downloaded at import time), but the file can still be rather large. The first step in the import process uploads the XML file, and then brings it back into the database. The problem is that by default, the maximum upload size for WordPress is 2MB, and I had two that were larger.

The way to get past this is to increase the maximum upload size. In Azure, this can be done through the addition of a configuration file in the web root. The file needs to be named “.user.ini”.

Open your web site using WebMatrix, right click on the site name, and select “New File”. Select TXT as the type, and name it “.user.ini”. Double click on it to open, and add the following line to it:

upload_max_filesize = 50M

After saving, you should be able to upload files up to 50MB. It may be necessary to restart the site through the admin portal.

I’ve been quite liking the performance and the stability of this new setup, and I recommend it highly for this sort of requirement.

6 Comments