We’re in the midst of a church survey for our strategic planning council.  This is something we do about every five years, and we ask a ton of questions to our church members and regular attenders.  It helps us to discover the pulse of the church, what we’re doing right, and what needs improvement.  It also gives us massive insight into who we are reaching.

Previously, it has been done completely on paper.  The paper surveys would be turned in to the office and everything transcribed.  When looking at 1,000+ surveys at about 8 pages, this comes at considerable cost.  With some help, I finally convinced the church to put the survey online.  We are offering paper copies to anyone who absolutely cannot use the World Wide Web.

I’m hoping that everything is going well with the process.  See, I’m on a cruise ship right now and I’m disconnected from what is going on with the survey.  I hope that the members and visitors are finding it easy to use and navigate, that we haven’t crashed the Web server or database server with all the traffic we’re sending, and that we’ll have as many people complete it by this method as we used to on our all paper method.

After we’ve tabulated all of our results, I’ll post the URL so that you can play around.

As part of moving from one Web site to another, our link structure changed massively.  With our previous provider, links were not SEO-friendly.  In fact, the previous provider didn’t allow us any control over meta data at all.  This means that all our pages pretty much looked the same to search engines.

Well, I didn’t want to loose the little what we had built with search engines and other publicity pieces that linked to old pages.  I also didn’t want users to be welcomed to the site with 404s, so I needed to get all of the old site redirected to the new one.

The first step that was necessary for this task was to search which URL’s Google had indexed.  So, I searched site:www.fbcbelton.org.  This showed me 92 pages that Google had spidered.

The problem with our old URLs is that they only included an ID in a query string (ie: www.fbcbelton.org/sites/document.asp?did=1610), a very unfriendly method for people and search engines.  This also creates issues in redirection because an .htaccess redirect can’t redirect document.asp?did=1610 to another location unless the new location understands the query string.  For instance, if I wanted that 1610 to go to http://www.fbcbelton.org/meet-our-staff/, there’s not a simple way to do it with an .htaccess redirect (it is possible with mod_rewrite).

However, I’m accomplishing the redirect in two steps, first redirecting to a Perl script that correlates the old ID to the new page and redirects to the new page.  So, I edited .htaccess with these three rules:

Redirect 301 /sites/calendar.asp http://www.fbcbelton.org/calendar/
Redirect 301 /sites/division.asp http://www.fbcbelton.org/cgi-bin/redirector.cgi
Redirect 301 /sites/document.asp http://www.fbcbelton.org/cgi-bin/redirector.cgi


The first rule says, I don’t care which calendar page you were going to, you’re just getting the current month from now on.  (Sad, I know, but I am working on a calendar solution.)  The second and third take the majority of the URLs and redirect them to a very simple Perl script that devours the query string and runs another 301 redirect to the actual page.  The script is very rude, but the old IDs are hard-coded in as are the new URLs.  (I’m hoping David will comment here and tell me an easier way to do all this, but I’m thinking there may not be one, at least short of using mod_rewrite)

Then I took the short URLs that our old provider gave to us and redirected them as well.  So, before when you entered http://www.fbcbelton.org/memberconnect, their server would send you to /sites/document.asp?did=8291.  Now, the short URL goes to the new location with one line:

Redirect 301 /memberconnect      http://www.fbcbelton.org/member-connect-faq/

When using .htaccess redirects to redirect a page to a new location, always use 301.  301 means that the page is moving permanently.  It is generally accepted that using that type of redirect is the best way to preserve your search engine rankings.

I’ve been having a lot of “fun” in the past few weeks with cloning a hard drive on a server. Let me tell you up front that I am a major penny pincher. You might remember my series on simple ways for the church to save money on operational expenditures. Some say that I’m cheap, but I prefer to be considered committed to missions and wise spending. That’s who I am. So, I end up using a lot of open source software.

I love Clonezilla. It’s an open source title comparable to Norton Ghost. Clonezilla has done some excellent things for me on a number of machines. It can really save a ton of time deploying new machines or replacing failing hard drives. Well, for some reason, it wouldn’t clone one of the partitions on Caleb’s hard drive. I did everything I knew how to do to make it work. I fixed the bad sectors, I ran tons of maintenance utilities, and I even got into the inner workings of Clonezilla and changed some of the script settings (scary, yes!).

Tonight, I bit the bullet and bought Paragon’s Drive Copy 8.5 Professional. It’s actually running right now, so I don’t have the final results, but it’s past the point that Clonezilla always crapped out. I’ve got to tell you that it looks like it’s going to be worth every penny of it’s $129 price tag. I have been pulling my hair out for weeks with this problem, and this thing looks like it’s going to do the trick. (I’ll know for sure in half an hour.)

What got me writing early on this, other than having nothing else to do but watch a progress bar, is that the rescue CD is very user friendly. It doesn’t look thrown together like so many other Linux-type rescue CD’s. It properly recognized the RAID, named the drives in easy human readable format (making it real hard to mess up the source and destination), and even lets me use the mouse. If this works, I don’t know if I’ll even install the Windows software that came with it.

So, hopefully my adventure with the Attack of the Clones is coming to an end. I’ll let you know how this thing pans out.

* UPDATE *

Drive Copy 8.5 worked like a champ!  The single drive has been successfully cloned to the RAID.  Now I’m a definite fan of Paragon Software!

Caleb is one of our servers (and just for added clarification - server in this instance means a computer, not a waiter).  Sometimes I love Caleb.  He works hard and fast.  He typically does everything that I ask of him.  He’s a super-server in so many situations.  But, like any toddler, sometimes he throws temper tantrums.  This week he started routing users’ e-mails into never never land, and if you put your ear up to his hard drive, you could almost hear him laughing.

I have to choose my punishments wisely for Caleb, since punishing him also punishes all my users.  I typically don’t put him in time-out, though I’d like to.  I do, however, verbally threaten him.  I’ll say things to him like, “You better act right mister, or I’m installing Linux on you,” or “I’m going to block your favorite sites.”  These threats usually don’t work too well for him.

In this last string of issues with Caleb, namely the development of bad sectors on his drive, I’ve found the need to clone his disk and move on.  Apparently he’s rather attached to this drive and doesn’t want a new one because every time I try to clone it, the process fails.  So, I’ve used every tool that I know of to fix the bad sectors to let the cloning commence, and I’m at a dead end right now.  I’ve used chkdsk, Seagate tools, and today I even purchased Spin Rite for the job.  All to no avail.

So, if anyone has good punishment ideas for Caleb, please let me know.  Or, if you know how to get drives with bad sectors cloned, that’d be good to know too.

I was watching a guy install WordPress a few days ago, and I couldn’t believe what I saw. He downloaded the zip file from WordPress.org, unzipped it, and uploaded all the files to his Web server by FTP. Sure, it works, but why do it that way when you can go SO much quicker? Let’s talk about SSH. While this stuff is pretty technical, once you’ve got a grip on it, you have some real power on your hands.

Prerequisites:

• You’ve got to have a Linux hosting package that allows you access to the shell (SSH). If you don’t have one I recommend the Linux Business Package from 1and1 which includes 3 domains (Disclaimer: I profit from sales generated from that link). By the way, their lower packages are cheaper but do not have shell access.
• You need a client to access the Shell. I suggest PuTTY (it’s free)

How to Install WordPress quickly with SSH:

1. Log-in to the shell with an SSH client, like PuTTY
2. cd (Change Directory) to the directory you want to install WordPress in. If you’re on 1and1, you will be in the root of your public Web site when you log-in. With other providers, you may have to use the command:

       cd public_html

   or something similar. You need to know which directory you are in. Are you in a directory that is accessed by http://example.com or by http://example.com/some_directory? Where you are now is where WordPress will be located.

3. Now you’re ready to rock and roll, simply use the following commands to make it happen.

       wget http://wordpress.org/latest.tar.gz
       tar -xzvf latest.tar.gz
       mv wordpress/* .
       rm -rf wordpress

   So, wget downloads the latest release of WordPress to your server, tar unzips it, move takes it out of the wordpress sub-directory into the current directory and rm removes the empty sub-directory.

4. Now, go to the place you put it on the Web. If you dumped all of those files into the public_html folder of example.com, just head over to http://example.com. If you put them into the folder wordpress, head over to http://example.com/wordpress. The on-screen instructions will lead you from here.

This works for upgrading to new versions as well. When updating, I personally like to remove the wp-content directory before overwriting the files because I don’t want the new files to mess with my plugins or themes.

Use caution with SSH as you are entering commands directly into your Web host’s server. They probably won’t let you run dangerous stuff and mess up their machine, but you could mess up your stuff. For instance, rm -rf * would wipe out everything in the directory you’re in. If you’re in public_html, you’ve just wiped your entire site. Read up before proceeding, but I wanted you to know that there is an easier way to install WordPress and other Web apps.

By the way, if you’re using a host that doesn’t give you shell access, you can sometimes still accomplish this by creating a simple Perl script. I make a Perl script that runs system(); calls if I need to do this. You get to figure that one out on your own.