Heal Your Church WebSite

Teaching, rebuking, correcting & training in righteous web design.

Seromonette: Make Backups and Test Everything!

“… but test everything; hold fast what is good.” – 1 Thessalonians 5:21

Here is something for you weekend ‘web’ warriors to think about. According to James Middleton at VnuNet.com, Websites don’t like Mondays. According to the article, “developers implementing ‘weekend inspiration’ are more dangerous than hackers.” It goes on to assert: “UK websites are more likely to crash on a Monday morning, not because this is when hackers or viruses are most active, but because this is when developers come in and implement ideas they had over the weekend.

Considering how many of us update our congregation’s Internet informational outpost on weekends and late at night, I could see where this might apply to those of us who maintain our church’s web site. I personally recall one site in which the web master had changed permissions incorrectly using FTP and the site was unavailable until I found it and emailed the host. Another instance I often see are sites that are untested where graphical images are linked to locations on the developer’s hard drive instead of the web site … so of course they test correctly on his/her machine.

So here is some sage advice from a guy who’s been doing the code-monkey thing for about 20 years:

  • Test everything
  • Make backups before you begin working
  • Protect backups by uniquely naming them
  • Make sure you know how to quickly restore from a backup
  • Test everything
  • Have someone else come along and test everything
  • If possible, test everything on a development site or subdomain
  • Make sure your backups are valid
  • Test everything

Coffee and donughts are now being served in the lobby.


  1. You make a very good point. I was recently updating my template for my Journey Inside My Mind blog, and Blogger was behaving badly at the same time. I am grateful for having a backup so that I could keep the changes instead of having to completely redo everything from scratch.

  2. I’m part of a team that manages and develops the website of a major computer manufacturer. For the past 5 years, despite all the management turmoil and turnover, we’ve had one very hard and fast rule. NEVER roll out new code on Fridays. It’s bound to break over the weekend when finding support staff (and developers) is most difficult.

    I’d doubt though if Pastors could ever be convinced NOT to roll out new church ‘programs’ on a Sunday though! :-)

  3. I’ll go one better than this, I mirror the site to my development server and do changes and testing on that, then when it works, I upload the changes back to the production server.

  4. Hey coincedental post over at Niphal about backing up, although we (at my work not Niphal) got broken into on the weekend… that’s another reason why things might break! ;)