Since I’ve had a WordPress blog for quite some time, and since I actually ended up writing both of my previous responses into my WordPress blog here and then using a nice copy+paste to get the content into HTML, there wasn’t a process to document for this week’s assignment. However, simply saying so seemed as if it would be something of a cop-out, and besides, there was some documentation I could do anyway!
See, due to the roadtrip I took this summer, the blog went un-administrated and un-updated for about four months. This meant that I fell behind a number of WordPress versions, and it was time to get that fixed. Since I didn’t have to install WordPress itself, I figured I’d run the upgrade process and document that.
At some point everyone using WordPress (and not using the “shut up and don’t tell me about updates” plugin) will notice at the top of their management page a notice that they’re out of date and that they should update. When it comes to WordPress it is extremely important that you do this in a timely manner because, unfortunately, WordPress is one of the most poorly secured widely used software packages on the net. There’s so much PHP, and there is absolutely no plugin vetting process. These two things combine to create any number of security loopholes that can be used by Bad People to hack your site. So when WordPress asks to be updated, it’s worth listening.
The process is pretty painless. In fact, it’s very similar to doing a WordPress installation. You download the latest version of the software package. You edit your config.php file (more on this later). You upload everything to the target directory. Then, instead of going to …/wp-admin/install.php you simply go to …/wp-admin/upgrade.php
Finally, you go have yourself a milkshake. (This is an important step, and not to be ignored.)
The main reason you can download the entire software package again and not worry about overwriting the existing files is that WordPress keeps everything you actually care about in the MySQL database that it connects to. All those files you upload to the internet when installing WordPress are just interface: they tell the system how to read and display information in the database and how to put new information there. Once you understand this, then the re-uploading the WordPress files thing makes sense.
What might not make sense is re-creating a config.php file. You did that once already, right? That’s how you made the site work the first time. Your database is the same, so is your username and password. Why can’t you just use that file? The answer is that the people developing WordPress keep changing what’s in that file. For instance, I was upgrading from a pre-2.5 version of the package so my original config.php file didn’t have any of the pass-phrase stuff entered in. WordPress will throw some funky errors if you try to upgrade without first fixing your config file. More interesting, to me at least, than the addition of new options in the config file, is the removal of old options. While I had to add three lines of config to upgrade, I had to removed two old ones. Apparently the WordPress team has someone making sure that they don’t just keep adding stuff, and in my book that’s entirely a good thing.
I went to the upgrade page, clicked a button, and WordPress conveniently checked all my files and then reformatted my database to the new information schema. This is important because many features the system adds requires information to be organized in a different way. Back in version *mumble*, where they introduced tags and categories to the software, the entire organizational structure had to be rebuilt from the ground up because the original design just couldn’t handle the things.
Anyway, all went well, my blog is updated and running smoothly (though I did have to re-install one of my plugins). Now I’m off to get a milkshake.
Thomas
Tags: comm lab
Hello,
I am, David
overall pretty good
check my site:
http://kJtsEnnE.spaces.live.com/