Last year, Alex and I redeveloped the website for a campaign group close to the town where I live. Even though the design was pretty plain (neither of us are designers), from a web development standpoint the site was pretty good – written in semantically correct XHTML and CSS, using PHP for server-side scripting. Alex even wrote a neat navigation bar system and all in all it was a pretty good site.
Unfortunately, I ran out of time for updating the site content and handing it over to a non-technical person to produce new content was never going to be straightforward. I needed something with a user-friendly content management system and so I rewrote the site to use WordPress with pages for the static content and blog posts for the front page news.
Moving all of the content to WordPress didn’t take too long – I still need to sort out a few dead links and develop a decent template, but one of the beauty of WordPress is the ability to customise a site on-the-fly so I can keep on working on those after making the site live – the important thing for me was to let other people create new content without needing any code.
Even so, when the time came to launch the new site, I did need to move my WordPress database from the /dev subdirectory to the root (it is possible to install WordPress in a subdirectory and still let it be accessed from the site root; however I chose not to take that path).
Although WordPress includes an export/import function that would let me export all of the posts via an XML file, then import them to a new WordPress installation, it doesn’t handle all of the database changes (new users, configuration, etc.) and it seems that the best way is to back up the database and then restore it to a new location. Whilst the WordPress Codex provides various methods for backing up a database, the clearest instructions are actually found in a link at the bottom of the Codex article to the Clearpoint Systems blog post on how to backup and restore a WordPress database (using phpMyAdmin). Then, because the database tables will refer to the old location, it is necessary to update the siteurl and home entries in the wp_options table.
It took just a few seconds to backup the database, restore it to a new WordPress installation, and make the changes necessary to make the site accessible again. Finally, all that was required then was to upload any edited theme files and plugins to the appropriate locations in the WordPress folder structure.
So, what you’re saying, in a nutshell, is that I was right and you were wrong. Cool.
Why didn’t you go with the running-from-its-own-directory option?
Also, when the new ascomi site goes live, we’ll see who isn’t a designer… :)
I don’t think it’s really a case of right and wrong… just that the WordPress administration site reads as though an XML import/export should be all that’s required to move the content of a site to another installation. (You want me to admit publicly that I was wrong and you were right! Yeah, like that’s gonna happen ;-) )
Running from its own directory would have been good, but I was trying to sort this in as little time as possible and installing in the root was simple (if not very elegant). I can always make changes later.
I’m sure the new ascomi site will be fantastic ;-) Certainly long overdue :-)