I’ve bee working on setting up some backup systems in our instance of WPMu and have been struggling a bit. While I certainly appreciate that creating backups for WPMu can be fairly straightforward to setup when using tools like phpMyAdmin and gzip (as outlined nicely in a recent post at WPMU Tutorials), there really isn’t a simple way for individual site owners to do site backups from the WordPress interface.

What I would like to be able to do is allow the user to simply create a site specific backup file of all the necessary files for their site. Everything wrapped in one nice little package, with the bow on top being the ability for the user to schedule and forget their backups. Once a day/week/month it would just run, grab everything they would need to restore their site (at least their posts/pages AND uploaded files) and all is good. But I am realizing this may be a tall order without setting it up behind the scenes.

Now, each WP site does have an Export option, which is simple and straightforward, but was never intended as a backup utility, but rather a utility to move posts from one WordPress install to another. As such, it is not a comprehensive backup and doesn’t include files, images or multimedia you might have uploaded to your site.

This is a problem I have found with most community developed backup plugins as well – they all concentrate on backing up the database tables and not those extra files that will no doubt be uploaded by users looking to use the platform as a CMS. In order to backup both the database (where the posts and pages are stored), and the associated files, you need at least two separate  plugins.

The two I have been working with are WordPress Backup and WordPress Database Backup. So far I haven’t been able to get these two to do exactly what I want, and using them both makes things a tad confusing for end users.

For one, there are now 2 backup options in their site navigation, located in different sub-menus. Natural instinct for a user to ask why is there 2 backups, and anytime a question is asked there is confusion. So a bit of support is needed to explain the differences between the two to the users. Not a huge deal, but a barrier.

What is very handy is that both backup plugins let you automatically schedule backups to happen at regular intervals. These files are zipped up and can automatically be moved to archive folders on the server or, if you want, emailed directly to the users, which some users might find comforting. The downside is that there are 4 separate zipped files that go along with each site – a database files (generated by the WP Database backup) and 3 backup files generated by the second backup plugin, one with your uploaded files, themes and plugins. One packaged folder would be nicer.

But the major problem I have with using the WordPress Database plugin with WPMu is that the interface does not limit the database tables to backup to just the site requesting the backup. It exposes ALL the tables to the entire WP instance, meaning that any site owner could backup and download any other site users content. Not cool.

I do like and appreciate the work that has gone into these plugins. I use them on this blog and they work great. But in a multi-user environment, I can’t really say this is the silver backup bullet I was hoping they would be. So, I am still searching for a backup system that users can initiate that is simple and straightforward for the end user that will allow them to control their own backups.

A few weeks ago, we launched a WordPress Multi-User pilot project at Camosun.  Here are a few thoughts early on in the process.

Why are we doing this?

For the past 7 (or so) years, FrontPage has been the web authoring tool we have supported for faculty at Camosun. At the end of 2006, Microsoft discontinued FrontPage. Since then we have been experimenting with other platforms to replace FrontPage for faculty who wish to have stand alone (ie: outside our LMS Desire2Learn) websites and haven’t really been happy with the tools we have found, finding them either costly, overly complicated, or limiting. Ever since our Office 2007 rollout last year, faculty who are still using FrontPage have been reporting problems, so IT Services was also anxious to have us find another solution for faculty websites. So the main purpose for piloting WordPress for us is to see if we can use it primarily as a CMS to replace FrontPage.

Armed with some good feedback from Brian Lamb at UBC, Grant Potter at UNBC, and  Audrey Williams at Pellissippi State (who have all been involved with the UBC,  UNBC and Pellissippi State WPMu installs), I put together a pilot document for our IT Services, who agreed to support the project. At the beginning of November, the pilot began.

The journey so far…

We’ve done a lot in a few weeks. Installation was quick and smooth. The network admin I have been working with (who has also installed Drupal, Joomla, LifeRay and a few other CMS type systems) remarked that the LDAP integration with Active Directory was the easiest he has ever done. He literally had us integrated with our authentication system in 20 minutes.

For my part, I recruited a half dozen faculty for a pilot group and did some initial training. They are now set up with their own websites – and I use that term website intentionally. I’ve avoided using the word blog when I refer to these sites. I’ve found that the term blog carries with it preconceived notions, both good and bad. So, in order to avoid the whole “I don’t want a blog, I want a website” circular logic wheel that I have witnessed when people talk about WP as a CMS, I have been using the term website when talking about our pilot sites. I really want our users to focus on WP as a tool to manage a website, not a blog and try to proactively nip that semantic bud. These are just websites.

The faculty will be playing with their sites between now and January. In January when the new term starts, they will be using them as their primary website and posting whatever content it is they want their students to have access to.

Some early technical stuff

In keeping with that “website, not blog” philosophy, we launched with a minimum number of themes, trying to pick pretty simple ones that handle pages and nested pages well.

As for plugins, again, I’ve started with a small set of plugins and will be adding and testing functionality during the pilot (which runs until the end of June, 2010). Specifically, the plugins we have installed to begin with are:

• Akismet spam filter and Akismet credit inserter to automatically insert a “Spam prevention powered by Akismet”
• pageMash page management plugin which allows you to drag-and-drop the pages into the order you like.
• COinS Metadata Exposer makes your blog readable by Zotero and other COinS interpreters. As a student who is actively using citation management tools like Zotero on a daily basis, I truly appreciate when this metadata is exposed to accurately capture citations from a webite.
• Unfiltered MU to allow users to embed content from other sites.
• Smart YouTube plugin to make embedding YouTube videos even easier. Yes, even easier.
• Active Directory Integration for, uh, Active Directory integration
• New Blog Defaults lets you customize certain default settings for new blogs.
• WordPress Backup and WordPress Database Backup. I’ll have more to say about backing up WPMu sites in a separate post. Suffice to say, it is not an easy thing to do using the standard WordPress interface.
• PDF and PPT Viewer looks like an interesting plugin that I have only started to test out. It could be very useful, considering that most faculty still post a lot of  PDF and PPT files on their sites. In a nutshell this plugin leverages Google Docs Viewer to create an embeddable view of a PPT or PDF document – no additional software or plugin required.

I’ll be elaborating about these plugins, and on administering WPMu, but I’ll save that for future posts. In the meantime, we now have a WPMu install up and running at Camosun and ticking along just fine.