Updating WordPress

I am writing this article at the request of a friend to help people out there who are afraid of updating WordPress for fear that they will do something that will mess up or break their site. Trust me, it’s a legitimate fear, but it can easily be conquered by this mantra, “Backup, backup, and backup.” Make sure you make a backup of everything before making any changes. That way you can restore your site to its original working condition in case something goes horribly wrong. WordPress can be backed up in 2 easy steps. First, you need to make a backup of the files, and second, you need to make a backup of the database.

Making a Backup of the Files

Backing up the WordPress files is simple. Just connect to your website using any FTP client, create a folder on your computer, and download the files into that newly created folder. You need to download all the files from the root-level of WordPress and below (i.e. sub-folders), and you can identify the root-level because it will contain files with a wp- prefix to them like wp.config.php, wp-login.php, etc. This should work in most cases. The harder part may be trying to identify which files are the production files if you’re doing this for a friend as I’ve seen multiple copies of WordPress in a hosting account and not every hosting provider has the same file structure setup. In most Linux/UNIX environments, the WordPress files should be in the public_html folder unless they’re hosting multiple websites/applications. They could also simple point it to another folder. In any case, I don’t have a sure-fire way you can tell since every hosting provider is different. You’ll have just have to check the hosting provider’s configuration settings or ask your local “geek” to help you out. It’s something that you learn to identify with experience.

Making a Backup of the Database

There are multiple ways you can backup the database, but the easiest I’ve found is to use either MySQL WorkBench or phpMyAdmin. Many hosting providers have one or the other installed, so you can just launch the application from their Control Panel, but if they don’t have one or the other for some reason, then you can install MySQL WorkBench locally on your computer or phpMyAdmin in your web hosting space. phpMyAdmin can also be installed on your local computer as well, but you’ll need to install something that can run PHP, so it will be more complicated to setup. Once installed, launch the application. You’ll also need to write down your MySQL database’s connection settings which can be found in your hosting provider’s Control Panel, noting specifically the server name, database name, username, and password. Some hosting providers don’t allow you to access your database from the outside, so if that’s the case, they should provide you with some method to backup the database using their Control Panel (most I’ve seen launch phpMyAdmin for you). The backup created is a .sql file which contains all the instructions to recreate your database. It might also be in the form of a .zip file (compressed) which contains the .sql file.

Backing Up using MySQL WorkBench

Once you’ve launched MySQL WorkBench, open a new connection using the “+” icon. In the “Setup New Connection” window, enter a Connection Name, the Hostname, and Username. The Connection Name can be anything, but the hostname and username are provided to you in your hosting provider’s Control Panel as mentioned above. Use the Test Connection button to verify that you’ve entered the correct settings and then click on OK to save the settings. Double click on the new connection to actually make a connection to the database. Now on your left, click on the Data Export link. In the new Administration – Data Export window, make sure you’ve checked the database, checked Dump Stored Procedures and Functions (and Dump Events and Triggers if your database uses them), set a location to save your backup file using the Export to Self-Contained File option, and make sure you’ve checked Create Dump in a Single Transaction (self-contained file only). Click on the Start Export button. If it doesn’t error out, then you’ve successfully backed up your database. If it does error out, and you’re a bit tech savvy, you can look on StackOverflow for help and answers, otherwise, consult your local “geek” again.

Backing Up using phpMyAdmin

Once you’ve launched phpMyAdmin, highlight the database on your left, then click on the Export button/link (different versions of phpMyAdmin have different appearances). In most cases, you can accept the default settings and just click on the Go button. Adjust them only if necessary. For example, in phpMyAdmin 2.8.0.1, I had to check Save as file before hitting to Go button so that it will download the backup to my computer. It will be saved in your “Downloads” folder unless you pointed that somewhere else.

Performing the Actual Update

Now if you’re confident enough that nothing will go wrong when you update WordPress, you can go ahead and update your live site by logging into the /wp-admin dashboard and clicking on the update links for WordPress, your plug-ins and themes. Make sure you update WordPress first before trying to update your plug-ins and themes, otherwise, we want to make a copy of your site (if possible and our hosting provider allows it) and database before trying to apply the update. There’s various ways to do this, and I can’t cover them all as I have mentioned repeatedly that different hosting providers have different environments. The best way would be to put the copy of WordPress in its own hosting space (e.g. separated from your production site, i.e. the one people see) and create a new MySQL database. If that’s not possible, you can put the copy of WordPress into a sub-directory off your main WordPress site. The important part is that you need to restore the database from the backup you made earlier into the newly created MySQL database and update the wp-config.php file to point to the newly created database by updating these lines:

// ** MySQL settings – You can get this info from your web host ** //
/** The name of the database for WordPress */
define(‘DB_NAME’, ‘database_name‘);

/** MySQL database username */
define(‘DB_USER’, ‘username‘);

/** MySQL database password */
define(‘DB_PASSWORD’, ‘password‘);

/** MySQL hostname */
define(‘DB_HOST’, ‘server_name‘);

You would replace the database_name, username, password, and server_name with the configuration details for your new MySQL database. The file can be edited with any text editor. Make sure you save the file and re-upload it to the new copy of WordPress. Doing so connects the new copy of WordPress with your new MySQL database so you can proceed to update it without it affecting your main site. Make sure you also restore the database by following the same instructions as you would to make a backup but instead of exporting the database, you’ll want to import it instead. Once this is all done, you can follow the instructions I mentioned above to update WordPress. Now, if something goes wrong, you can just delete the new site and database and try again, and your old site remains unaffected.

Testing and Finalizing the Update

To properly test your updated WordPress site will depend on a number of factors. For example, if you copied the WordPress site into a sub-directory, you can access it using the normal method of accessing your main site but add the sub-directory name to it. This may or may not work as WordPress has a Site URL configuration setting that can greatly affect how files are accessed such as css files which in turn can screw up the layout of the entire site. Fortunately, WordPress provides instructions on how to change it. You may want to do this temporarily to test the newly updated site, and then revert it when done. Now, if you were able to copy the site into its own hosting space, you can test it by updating your local “hosts” file. The new site should have a different IP address than your original site and the domain name on the site can be the same or different such as a sub-domain name. Add an entry for the domain/sub-domain name pointing to the new site’s IP address in your “hosts” file. This will force your computer and only your computer to connect to the new site rather than the old one. Even with this step, you might have the change the Site URL unless you’re using the same domain name in order to test the site.

Once you’ve finished testing, remember to revert the changes you made to the Site URL and hosts file since they were for testing purposes. To finalize the update is dependent upon the tools your hosting provider gives you. Some allow you to point your domain name to another folder which would be the easiest thing to do. You simply point your domain name to the “new” folder you created for updating WordPress, and you’re done. If that option is not available, then you will have to move or upload/download the files to your production work space and also backup and restore the MySQL database. If you do this, make sure the wp-config.php file’s settings for the database is pointing to the correct one.

Displaying International Characters in URL from WordPress Hosted on IIS

I was helping someone troubleshoot this problem today and had great difficulty finding a solution (modifying various elements in configuration files such as web.config, user.ini, wp-config.php, etc.), but it seems like the solution is to just add the following code at the beginning of the wp-config.php file:

if ( isset($_SERVER['UNENCODED_URL']) ) {
$_SERVER['REQUEST_URI'] = $_SERVER['UNENCODED_URL'];}

Hope this information helps someone out there and save them hours of frustration!

Error in URL Rewrite Rules for WordPress 4.6.1 Multi-site Configuration

Yesterday, one of our customers asked for help troubleshooting a 404 error he was getting every time he tried to access the dashboard (admin interface) of any sub-site he created and wondered if there was anything that needed to be changed server side to get it to work.   I informed him that if he followed the instructions on WordPress’ Official Site, it should work without additional intervention from us.  I was partially correct.  Since I’ve never configured a WordPress Multi-site before, I spent more than a couple of hours going through the steps myself and indeed ran into the same problem that our customer experienced.  I then scoured the web for a solution and knew it had something to do with the URL Rewrite rules but was unable to figure out a solution.  Fortunately, our customer was able to find the solution himself which I will now share with you.

On line 24 (WordPress Rule 4) of the web.config markup that WordPress gives you when you click on the Network Setup link under Settings, it reads:

<action type=”Rewrite” url=”{R:1}” />

It needs to be changed to:

<action type=”Rewrite” url=”{R:2}” />

Many thanks to Lucas Nieboer for pointing out the solution!