This is going to be a post that’s a little technical. It’s about the maintenance of a website (this one), and yes, we’ll soon be back to talking about puppets.
I recently upgraded to WordPress 2.7. While it shouldn’t be a complicated process, mine took some time because I was also backing up files and looking into where the site has been hacked. You see, just like PCs are more likely to be attacked than Macs because they there are more PCs, WordPress blogs are also more prone to attacks because it’s the most popular content management system for blogging. It’s very important to stay up to date. I am writing this post to share the process I went through, in case anyone needs the information.
Discovering the problem
The other day my sister noticed that my site was loading slow. I suspected an attack, but after inspecting the top level files for suspicious code (because I know iframe hacks are sometimes inserted there), I came up empty and concluded that the server just happened to be slow that day. Later, though, I suspected that the problem might be elsewhere. I decided that I shouldn’t procrastinate any longer on upgrading, so I started backing up.
While I copied the files off the server onto my hard drive, I noticed that my anti-virus software is marking quite a few files in wp-content/themes folder as potential threats. This is the folder that stores all the WordPress themes that were installed. And in every theme, header.php was marked as a threat. At this point I disabled my anti-virus software (a move that’s usually not recommended) in order to download one header.php to have a closer inspection. Note that running such a file might be bad, but I am only inspecting it as a text file, so that will do know harm. After comparing that copy of header.php with a backup copy I have, I noticed it has one extra line of script that shouldn’t be there. That was the culprit. Also, I compared folder contents, and found a file called remv.php in the wp-content/themes folder that shouldn’t have been there.
A search on the suspicious file remv.php led me to this article WordPress, remv.php and You, which confirmed my suspicions. This is a hack that exploits a hole in WordPress 2.6 and often perform DDoS (Denial of Service) attacks on sites. That is why it was running slowly. After some reading on the topic, I started taking care of the problem.
Back up your files and database
First, load up your FTP program and then download all the files. I already did that in the last step. Also I did not need to back up all files, because I already periodically back up files and I know I do have good copies of those files. And then I go into my database admin page and exported my database as SQL. I also saved it as a CSV (Comma-Seperated Values). I also tried to save it as PDF and XML but those took a long time for some reason, so I thought, never mind. It’s important to back up your files before upgrading, because there’s a possibility that something might go wrong during the process, and you’ll need your backup copy to restore the site. And also it’s simply a good habit to back up your files anyway.
Deleting old files
A good rule-of-thumb is to download the new copy of WordPress first, and unzip it to look at what files are provided to you. For example, you can delete all the files at top level, because the new copy of WordPress will provide that. Okay, maybe you will want to keep wp-config.php, because that’s where your configurations are saved. However I decided to use the fresh copy, and then just compare it to my old copy to make the changes I need. I also deleted the whole wp-admin and wp-includes folders from the server, because the new WordPress does provide them.
For wp-content, though, I am more careful with it. In this case, I did not just delete the plug-ins and themes, because I have already customized these things at some point. Also the uploads folder have the files (most likely pictures) that you uploaded that were not part of the original WordPress. You’d want to keep that. I left my plug-in folder pretty much untouched as well, except putting in the new version of Akismet. For the themes, I made sure that I deleted that remv.php file. And then I went ahead and deleted all themes that I wasn’t using. Since I wasn’t using them, and they are all available for download on the internet anyway, I am not going to miss them. This is also to be on the careful side to make sure the code that’s not supposed to be there is no longer there. I did not delete the theme that I’m currently using, because I’ve already modified it in many places. I did, however, downloaded the folder to compare each file against the original theme (ok, not the original, but a backup copy I made while switching the Feedburner feeds) to make sure the bad code is no longer there.
Installing the new version
Of course, you will need to download the new version of WordPress from WordPress.org. The file will be a zip file, and you can unzip it to your local hard drive and then upload it to your server. And then, if you had overwritten your wp-config.php, you would need to set up a few variables again, namely, information about your database set-up. At first I did not set it up correctly. I threw in the old wp-config.php from my backup and it did work. I think, in general, they would make the wp-config.php files backward compatible, but I would like to use the new one even though it’s only slightly different. I compared the old and the new, and ended up loading up a new wp-config.php based on the new wp-config-sample.php. Note that they made it a sample file so the actual configuration file will not be accidentally overwritten.
At this point, hopefully you can type in your site’s URL and then it would just work. If it did not, search the internet for whatever error message you are getting. Also compare it against your backup files for insight, and throw the old files back onto the server if necessary.
This is only an issue for people that use certain symbols and characters that’s not English. For example, I write about Taiwanese puppets, so several of my posts contain Chinese characters. I noticed that, after the update, most things look fine (none of that vanished categories problem like last time), but I noticed that the Chinese characters are showing up as garbage (sometimes just ???). The worst case scenario is, I’d have to go back to all articles that have Chinese characters and enter them again. Or maybe there’s another way to solve this. But either way, I need to figure it out, because I am planning to write more about Taiwanese puppetry and I can’t just re-type things after every single upgrade!
I looked into this Unicode problem and found this post titled WordPress, Unicode, and ?s. It said to just comment out the defines for DB_CHARSET and DB_COLLATE in wp-config.php. I did that and it worked like a charm. Now, those defines were not in the old wp-config.php either. Maybe it would’ve just worked if I didn’t bother to be such a genius and used the new one. Oh well. And later I found this documentation on the official WordPress site, which explicitly stated:
If DB_CHARSET and DB_COLLATE do not exist in your wp-config.php file, DO NOT add either definition to your wp-config.php file unless you read and understand Converting Database Character Sets. Adding DB_CHARSET and DB_COLLATE to the wp-config.php file, for an existing blog, can cause major problems.
Okay… major problems, eh? I’ve learned the hard way. Also, WordPress does have native Unicode support. It’s the php code that’s messing it up.
Wow, that was quite a technical post.
It’s time like these that I’m glad that I’m a computer programmer. Many problems popped during along the way for one reason or another, but I was able to just look up some information and then resolve all my problems. Now I am writing in WordPress 2.7 with the new shiny interface. I hope most of you never have to deal with the problem, and if you do, I hope you found this information useful.
Oh, and remember, always back up.