What a relief! For the past few months I’ve been running WordPress 2.5 on three of the four WordPress blogs my family and I currently use (Learning Signs, Eyes Right and Talking Science) but I’ve held off upgrading my main Speed of Creativity blog because I’ve been burned before with WordPress upgrades. They SHOULD go off without a hitch, but there CAN be problems. As I reported back in April, I’ve been fairly happy with the new interface which was introduced with WordPress 2.5 overall, but have been hesitant to make the switch on my main blog because I thought I preferred the “old” dashboard, and because I haven’t wanted to risk the upgrade YET if it wasn’t absolutely necessary. Familiarity breeds loyalty, I suppose, and upgrades CAN be stressful. Yet for security reasons, upgrading a blog installation is as important as installing new operating system patches when they come out. The release of the iPhone WordPress application this last week is what finally pushed me over the edge, I think, along with the release of WordPress 2.6. The iPhone WordPress application requires that you run at least version 2.5, so to have any chance of following in the footsteps of others like Bob Sprankle experimenting this summer with mobile blogging, I certainly needed to install this WordPress update. 🙂
Upgrading my first three WordPress blogs was VERY quick and easy: Plug-ins deactivated, new WP files uploaded quickly, updated the database with the upgrade URL, and re-activated the plug-ins. Quick, fast, easy. The way a WordPress upgrade should be.
With this blog, however, things were not quite so smooth and fast.
I started by downloading a full backup of my mySQL database for my blog using pHpMyAdmin. I always feel better right after downloading a full backup of my blog. How many hours of work does this single file represent? I have no idea, but it would be a serious blow to lose all this data. My WordPress mySQL database is currently 37.2 MB in size. Not overly huge by current video file standards, but still pretty large for a text file.
After making the local backup of my database, I downloaded and uploaded/installed three plug-ins for which new versions are available. No problems there.
I next deactivated all my WordPress plug-ins. When I started to upload the new WordPress 2.6 files to my server, however, I ran into some trouble. For some reason, the upload was VERY slow, and then it timed out! Ouch! It took three attempts before FINALLY I saw this screen… What a relief!
I’m not sure if the slow upload was due to hits on my site or local access issues. Whatever the case, I am relieved the update was successful. I did have to run the database upgrade URL command several times before it “took,” and I freely admit I was holding my breath when it appeared there might be a glitch. Now, however, it appears all is well:
I’m amazed that Akismet has “protected my site from 71,557 spam comments” to date. Good grief. That statistic is the reason I included the suggestion in my last post that educators select a blogging tool with EXCELLENT anti-blog spam comment functionality. I am delighted that the anti-spam commenting functionality in WordPress is good enough at this point that I do NOT have to moderate all comments to my blog. This certainly permits the conversations here to be more free flowing and dynamic.
I am also relieved that the PodPress plugin seems to be working fine without problems under the new installation. This was also one of the reasons I delayed my WordPress blog upgrade– I’ve been using the Podpress-generated podcast URL’s in my podcast feed (which I create and publish with FeedForAll Mac) since podcast 176, I think, and if that plug-in failed I’d end up spending hours re-creating that podcast feed with corrected URLs. I am soooooo glad I won’t have to do that!
My last upgrade step this evening was copying my full mySQL WordPress database up to my Mobile Me “iDisk” site for backup purposes. As a zipped file, it was just 7 MB. I will be able to sleep well tonight!
Have you had good or bad experiences with WordPress upgrades, or specifically WordPress 2.6 and plug-in incompatabilities? My main “bad experience” with a WordPress upgrade happened when I forgot to first deactivate my plug-ins before upgrading one time. That is certainly a no-no to avoid at all costs. Migrating my Wordpres blogs to a new webhost was also a bit of a nightmare. Hopefully I won’t have to ever do that again.
wordpress, blog, upgrade, ftp
If you enjoyed this post and found it useful, subscribe to Wes' free newsletter. Check out Wes' video tutorial library, "Playing with Media." Information about more ways to learn with Dr. Wesley Fryer are available on wesfryer.com/after.
On this day..
- Creatively Saying with Video: Grandchild #10 is Coming! - 2011
- How important are these digital skills for you as an educator? (poll) - 2010
- Transformative power of flash-based video cameras - 2008
- links for 2008-07-26 - 2008
- Let's work together, shall we?! - 2007
- A digital playground of dreams? - 2007
- Podguides and virtual field trips - 2006
- Track MTI 2006! - 2006
- Prescriptions for 21st Century Intentional Living - 2005
- Living in an Attention Economy - 2005
Congratulations on making the leap! So far, I’ve had good luck with my WordPress and WordPress MU upgrades. One thing I do a little differently is that I download both the database and ALL the whole WordPress folder I’m updating. That way, if disaster strikes, I can more easily go back to the old version. Haven’t needed to do it, but I like having that “security blanket” there!
I run 2 WP sites on my own domain and about 6 at NMC and have done scads of updates w/o any hitches, though sentences like that don’t really help. I’ve moved CogDogBlog three times from hosts with out a hassle, and am getting ready to upgrade my WPMu site– which starts to make tons of sense once you find yourself looking at a number of blogs that you cannot count on your fingers of one hand.
The ones on my DreamHost hosted sites are easy and a dream- they have one click install/updates. I just click and wait a few minutes. I was wary at first, but there has not been a hitch in 2 years.
For the ones I do manually, I stick to the recommended steps. Some suggestions:
* WordPress Data Backup plugin makes it easy from your WP dashboard to run a backup, can have it saved to your wp-content directory or emailed (not a great idea with a 37 Mb db). It also can do it on a schedule basis (I think)
* Maintenance Mode plugin – When you are updating you are missing/adding files and who knows what happens when people access your site? This puts up a splash “come back soon” page for visitors, but as an admin you can log in and do stuff / check. When you disable all plugins, just activate this one. When things are done, I de-activate this one.
* At first I thought 37 Mb was oversized for a WP database, but that within reason, especially as PodPress creates tables, and if you run Spam Karma 2 that creates big log tables, plus you have lots of long blog posts and comments 😉 Mine is about 20. I good habit to do maybe monthly is to go to phpMyAdmin for your database and click the little link below your tables “Check Tables Having Overhead” – overhead is wasted space, and this selects the ones with this (amounts listed in right most column) and then select “Optimize Table” from the menu to the right. This can clamp down a lot of space, plus will make your database run more happily.
* A simpler way to backup for update purposes is to do a copy in place of database and files rather than downloading (although I recommend downloading on occasion). In phpMyAdmin, got to your database, and under the “Operations” tab, look for the “Copy Database to” field and just give it a name like “wordpress.old” with the default options. This makes a copy right on your server. If something goes swry with an update in the database, you can delete your original, and then rename this copy back to its first name.
At the same time, downloading your entire WP directory can take a long time for file transfer. Actually, all you really need is the wp-content directory and your wp-config file (I keep the htaccess one too) as everything else is what you replace. An easier way during upgrade when you want just an “in case of disaster” copy, is to make a copy in place on the server. This means you have to be able to log in to your server on command line (telnet, terminal) and not all hosts allow that. If it does, you just need to navigate to the directory that contains your entire wordpress install, which may be a folder named “blog” or “wordpress” or even “jellybean” and then just do a unix cp command
cp -r blog blog.old
The “-r” tells it to copy all of the internal folders recursively so you get everything.
This way you have an emergency backup w/o needing to ftp down and back.
Lastly, I heard Matt Mullenweg say in a speech in February that on the roadmap is an ability to upgrade WP in place without this manual mumbo jumbo, the way plugins can be done in the 2.5 version. There is a plugin that sounds like it does it, tho I tried a while last night with one of my minor blogs and could not make it go: