Tag: maintenance

I’ve owned domains for a long time now.  My first domain net-marks.com comes from a time when there was only one domain registrar, and the yearly cost for a domain was more than three times what it is now.  For almost as long as I’ve had a site where software that I’ve written was readily available. In the pre-CMS days, I used to do all pages by hand, because that’s all we had – and we liked it.  Later, on a suggestion from Cheryl, I started using FrontPage – also known as “the land of an insane amount of garbage tags in your code“.

And then a friend introduced me to Drupal – he suggested we use it as the backbone for our City of Heroes supergroup website.  For those that don’t know, Drupal is a CMS that is both amazingly powerful and amazingly complex – sometimes too much for its own good.  So I set about learning Drupal, and getting our site up and running under it.  It went pretty well, and for the few years that we were active it served us well.

At the same time I also converted the content for my old FrontPage software site to Drupal.  Thus embracing it as much as possible.  The idea was that the more I used it the more I learned.  And what I learned is that as great as Drupal is, it is also not without it’s fair share of problems.  Most of these extend from it’s tendency towards complexity.

For one, it’s extremely difficult to update the core software.  Or more to the point to update all your content tied up in Drupal to the latest version of Drupal.  I always found this to be a chore.  It was definitely a one step forward, two steps back ordeal.  Sometimes you had to completely abandon an update, restore what you had, and walk away.  It always took several days to do.  But I toughed through it all.  Over time, I discovered and figured out how to do multi-site Drupal, thus moving to a single codebase install.

Drupal: 2; WordPress: 0

Over the years, the supergroup faded and I got a bit frustrated with MMO gaming (long story, though many know it – you need only look for the gamer tag Circeus).  As such I’ve not coded for games in a bit now.  I want the areas of my expertise to be elsewhere now (note: I do still game).

More recently, Cheryl decided she wanted a blog.  We discussed it, and concluded that WordPress would best suit her needs. So we made a folder for her at our site, and I installed WordPress into it, and she was off and running in her space.

Drupal: 2; WordPress: 1

Not long after, some friends and relatives decided they wanted websites.  I’ve already got hosting, and can host unlimited domains,  I offered that if they purchased domains I’d host the domains for them.  They registered their sites, and I installed WordPress for them.  And they too are off running in their own spaces.

Drupal: 2; WordPress: 3

At this point I discovered WordPress-Mu (a.k.a. Multi-Site WordPress). This allows for a single code-base for multiple blogs across multiple domains.  This makes everything incredibly easy; one source for themes and plugins, and one codebase.  This is exactly what I needed to move forward.

And that brings me to the present.  I’ve finally started my own WordPress blog here at perlmutter.me, and while it’s still in its infancy, to me it feels right.  It’s much easier to get through, find what I need to manage, upgrade, etc.  It’s in PHP – I know PHP.  It relies heavily on CSS – I’m learning CSS.  It’s hooked based, so I can easily extend and write my own themes.  Upgrading is not a chore.  I’ve been through a few versions now, and each has been on the order of minutes, not days.  In general, I’m happier using WordPress, and my Drupal sites have stagnated.

Drupal: 2; WordPress: 4

So here I am.  I have two basically dead Drupal sites, and 4 WordPress blogs, where do I go from there?  I’ve come to a decision.  Over time, I plan to phase out my use of Drupal.  It’s served me well enough, but I’m not in sync with it anymore.  As with gaming, I’m elsewhere now.  The goal will be:

Drupal: 0; WordPress: 6

But for now, for transition, it’s:

Drupal: 2; WordPress: 6

The transition, etc. and my plans surrounding it will be discussed in my next post.  In there I’ll talk about what it takes to host Drupal and WordPress side-by-side and how to do it.  I’ll talk about moving hosting providers.  Backing up and restoring both Drupal and WordPress.  And relocating Drupal sites to new homes.  And some simple things you can do to make two WordPress Blogs seem like one.  I hope you’ll come back to read about it.

So part of what’s going on here is that my “grand plan”^TM included moving from a few single site installs of WordPress to instead using WordPress MU.  This step is now officially complete.  It’s not that I’m hosting a lot of blogs here, but rather that I’m more the sort who prefers “one stop shopping” – especially for maintenance.  If there’s too many steps to a thing I’ll avoid doing it.

Moving a WordPress blog isn’t rocket science, but there are some considerations to be made.  And I recommend 3 precursor steps to any WP blog move:

1. Use FTP to back up your WP Install.  This way you’ll pick up themes, plugins, and media that have been uploaded.
2. Use something like phpMyAdmin to do an export of your Blog’s database.
3. Use the WordPress “Export” function to export your blog data to an XML file.

Then assuming the old site is still active, and once you have the new site set up, you can just use the WordPress “Import” function to read everything back in.  When the old site is active all media will be copied into the new install.   I highly recommend that you install any themes and plugins that were in use before you do the “Import” – it’ll make life easier.

Now, what if you’re moving a domain along with the blog?

Well that is a sticky situation because the old site will not be available for the import – which means media will not be available for the import process.  This leaves you with two choices:

1. Suck it up.  The old media is in your FTP backup.  So do the import, ignore all the errors because the media was not found, and then manually add the media back.  If you have no media – this is always the right choice.
2. Stage the blog at an intermediary first.  Before shutting down the old site, import it into a temporary blog.  Shut down the old domain site, and then move the temporary blog (Export & Import) to it’s final resting place.

Last night, I was moving two blogs (one belonging to a friend, and the other belonging to a relative) along with their domains.  Because they were small and under-utilized, I went the suck it up route – there were only 3 media files to be found between the two blogs.