June 23, 2011 by Clint Lalonde on My Masters

38,944 Words

Last night at 11:55pm, I submitted my Masters thesis to my supervisor to begin the external review process. While there is still a chance that some work will need to be done as it moves through review, a sense of completion is beginning to settle in on me as I realize that, for the first time in almost a year, I am looking at a weekend that doesn’t include work on my thesis.

Well, that isn’t entirely true.

One of the things I am planning on doing is publish the thesis here on my site in something other than a PDF document. I want it open for comments and, with any luck, prompt some interesting discussion. And, quite frankly, this part actually scares the bejebsus out of me. But I do see the thesis as a start, and not the end, of the process of learning for me. Putting it out there to get feedback from my peers is where the real learning happens, and I hope others will find it interesting enough to contribute to the discussion and (gulp) pick it apart where it needs to be picked apart, and add support to where they agree. Ultimately, like anyone who has poured a lot of work into something, I want and hope that it will be useful to someone else, and to find that someone else, it needs to be out in the open and not locked away in some digital repository (although it will be there, too).

How I was going to do this wasn’t exactly clear because it had seemed like a far, far away in time project. Today – not so far away. I did have it in my head to use WordPress and the digress.it framework, which allows paragraph by paragraph commenting. Then, last night after I had clicked submit and was still too buzzed to hop into bed, I think I found the recipe on how to publish an academic paper using WordPress and digress.it, posted by Joss Winn. So, if all goes well, in the very near future this idea will become a reality.

But first, I have a very important matter that needs attending to this weekend.

Bohemia by Paulo Brabo. Used under Creative Common license.

December 2, 2009 by Clint Lalonde on Camosun, WordPress

Adventures in backing up WPMu

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.

backup 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.

November 28, 2009 by Clint Lalonde on Camosun, WordPress

Piloting WordPress Multi-user at Camosun

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.

September 24, 2009 by Clint Lalonde on EdTech, WordPress

4 Alternative Blogging Interfaces for WordPress

I’ve been a WordPress user since the b2 days, but only lately have I begun to explore different methods of posting content to a WordPress blog. In the past, I have used the standard web interface for creating posts, with the occasional foray into using the FireFox ScribeFire plugin (more on that in just a moment).

Why alternatives? Well, it’s not that I think the standard WordPress interface is bad or poorly designed – far from it. But I am looking at alternative, streamlined ways of getting content into a site that may be more familiar to non-WordPress users.

Over the past few days I’ve been playing with alternative ways to publish content to a WordPress site, and here are 4 that I have come up with.

Using Word 2007
I really like this method, not because it is the best tool in this list, but because it is the most familiar interface for the faculty I support. Everyone is comfortable using Word and, while it won’t give you all the functionality of the web interface, it gets the job done with some nice functions in an interface that users are familiar with.

Setup is easy and straightforward and you can insert text, links tables and images, including WordArt, Symbols, Shapes and SmartArt. Blog management and organizational options are pretty minimal, but include the ability to post as a draft, and choose an existing blog category for the post. You can also open previous posts from your blog to edit.

A lack of headings in the toolbar is a frustration I have with the interface, and the reason why the subheadings for this post are appearing as 14 POINT (???) headings and not h3 tags as I would prefer. Microsoft has instead decided to put bigger and smaller buttons on the interface. This is something Microsoft has done with other html editors I’ve come across (yeah SharePoint, I’m looking at you) and it is an annoyance I find maddening. Not only is this semantically incorrect (let me make a heading a heading and a paragraph a paragraph please), but it also overrides the set CSS in the WordPress themes. It would be far better if they just left the text options as standard html tags, which would be semantically correct and would also ensure consistency in design.

That said, in terms of something my faculty will find easy to use, the Word interface seems like an early winner. And anything that helps people move away from posting links to their Word documents and posting in html is a winner with me.

By Email

Another familiar interface for my users, you can post to a WordPress blog from any email client. While this does require a bit more technical work to initially set up, you again get a composing environment that is really user friendly and familiar, especially for the slightly technophobic faculty.

This is bare bones in terms of functionality. The subject line will be used as the title of the post with the body of the email as the content of the post. All html in the email will be stripped out, and it does not support uploading attachments or images. You also cannot choose what category you want your post to appear in with the post appearing in whatever the blog default category is. This does not have the functionality of Posterous, but in terms of getting content onto the web quick and painlessly, it’s a fine alternative.

ScribeFire

ScribeFire is a FireFox plugin that lets you post to your blog from within FireFox. This is a full featured alternative to the native web interface that has tons of features. I’ve used this in the past and, while I like it, I have found that the formatting sometimes goes a bit wonky when the post is published and the post doesn’t always look like I would expect it to with the underlying html code getting rewritten. Still, you can pretty well do anything with this tool that you can with the WordPress interface. It’s handy when you come across something on the web that you want to blog about quickly, or if you have no eb access but still want to compose a post to publish when you reconnect.

Google Docs

Cole Camplese sent me scurrying down this path a few days ago when he tweeted a test post (which looks like it has since been deleted). So I gave it a shot and found out that you can post directly to WordPress from Google Docs. In the example from a few days ago, I included an image pulled from my Flickr account and a drawing done in Google Docs. Connecting was pretty straightforward, however there was no specific WordPress API hook. Instead, I used the Moveable Type API, which connected, but may explain why when I posted the post showed up on the blog sans title.

Have you used any of these tools? Are there any other ways to create content outside of the WordPress user interface? If so, I’d love it if you let me know.