WordPress, and linking it to a VLE as a blogging tool, using LTI. Please don’t hit me with a barrage of comments about why I don’t just use WordPress *instead* of a VLE (I’m looking at you in particular Lockley). There are reasons. About 4,500 of them per academic year.

I started thinking about this last year, but for a couple of reasons I’m picking it up again now and will very likely be pushing it on through into working code over the next few months (not alone I hasten to add, genius colleagues of mine will be very much involved in the actual coding of things). This is a good example of the kind of write-it-all-out-to-think-it-through I typically do offline and that I don’t tend to share. For fear of being found foolish, dull, or both. Please just ignore me if this is drivel – you don’t need to tell me. Very grateful for useful comments about things I’ve overlooked though 🙂

How I normally work is to map out the kinds of use cases I can see, and identify the high level problems and areas that might be straightforward. Then I’ll dive into exploring what actually exists and see how well it matches. Sometimes it reveals I’m way off-base. Sometimes I get lucky and exactly what I want already exists or can be easily supported. Sometimes it reveals that we need to move on and do some more requirements analysis to map out the processes and workflows, and then code it up, or get into some significant amount of system configuration. So this is the start of that process – the mapping out bit where I work out what sort of shape of thing I’m dealing with.

When I looked at this a while back I identified a few different use cases and a few plugins that looked like they might provide a good starter for ten.

LTI Starters for Ten

At a brief glance (and I haven’t done more than download some zip files from GitHub and fork a repo) these are plugins that allow you to connect WordPress (as a tool provider) to a VLE (as a tool consumer).

• http://www.spvsoftwareproducts.com/php/wordpress-lti/ (this is the Oscelot one by Simon B – on Stephen Vickers site)
• http://sourceforge.net/apps/mediawiki/learningapps/index.php?title=LTI4Wordpress (used by Dearborn Schools – Michigan)
• https://sourceforge.net/projects/learningapps/files/Files/Basic%20LTI%20Integrations/Wordpress/wordpressLTIPlugin.zip/download (developed by Universitat Oberta de Catalunya for WP3.3.X and seems to be pretty out of date?)

Use Cases

A few up-front assumptions:

1. We have a single WordPress Multisite instance supporting all these use cases. Let’s see how far I can push that before it breaks down…
2. All users have an institutional identity which is used consistently in the VLE.

There are a number of use cases I think we might need to support.

Use Case 1: WordPress as a blog tool for a course (one per student)

• For each course there is a WP site per student. Ideally created upon first login by the student from the VLE to WP.
• Students are set up as admin users on the WP site, based on user data from the VLE.
• Teaching staff have viewing/commenting rights?
• There could be more than one course using blogs so each WPMU site needs to be in the context of the course and the student.

Since we will likely be connecting Learn and Moodle to the same WP instance, a little bit of thought about multi-tenancy is useful. It’s very unlikely that the same course would be in both platforms and also try connect to the same WPMU site, but I like things to be neat and tidy from the start. Tucker’s Law is a thing (don’t follow the link, it’s very sweary).

“…the primary key for a context should be the oauth_consumer_key concatenated with the Consumer- provided context_id value.” (https://www.imsglobal.org/basic-overview-how-lti-works)

Use Case 2(a): WordPress as collaborative blog tool for a course (whole course)

• For each course there is a single WP site, ideally created upon instantiating the tool link in the VLE for the first time?
• All students in the course are assigned as authors, based on user data from the VLE.
• Teaching staff have admin rights?
• There could be more than one course using blogs, so each WP site needs to be in the context of the course.

Use Case 2(b): WordPress as collaborative blog tool for a course (small groups)

• For each course number of blog sites = students / group size e.g. 40 students, group size of 4 = 10 blog sites.
• All students in the course are assigned as admins(?), based on user data from the VLE.
• Teaching staff have viewing/commenting rights?
• There could be more than one course using small group blogs, so each WP site needs to be in the context of the course and group.

This one will be a bit of a pain. VLE’s typically have some sort of tool for creating groups within course, but at present there is very little support for the LTI Names and Roles Provisioning Service (formerly known as the Membership service and now part of the set of extensions known as LTI Advantage) which does syncing of groups. We have Stephen Vickers’ custom Blackboard building block which provides us this functionality but that doesn’t solve the problem on other VLE platforms.

Need to mull this one some more. No way of specifying how many blogs to create as part of the LTI instance config in the VLE and no way of easy syncing specific students to specific blogs. In the short term, probably some horrible fudge using a CSV upload directly into WP to create blogs and create/assign users is required. URLs to each blog stuck in the VLE and some reliance on a separate SSO capability to make it hang together in terms of authorisation.

Use Case 3: WordPress as content repository for a course

• For each course there is a single WP site, ideally created upon instantiating the tool link in the VLE for the first time?
• Teaching staff have admin rights.
• Students can view.

Not sure that LTI is required unless the blog as content repository is a closed space. Can just be a public URL added into the VLE otherwise.

This is where the LTI Deep Linking extension might be useful if it is a walled garden and you want to link to specific WP pages. Again it’s part of LTI Advantage and so doesn’t yet have good support in any VLE platform that I’m aware of.

Have I missed any obvious use cases?

I could write about using WP as the front end, syncing data back to the VLE, but it’s late and that’s not my primary interest. Maybe later, because Moodle in particular does have both LTI consumer and provider support and we have already done something pretty cool around using a stripped back version of Moodle as a Maths assessment platform to take advantage of STACK. Another time, another blog post.

Tidying up

And here we get to one of my big bug-bears with LTI. It’s great for provisioning data, and on paper the spec doesn’t insist on requiring personally identifying data:

“Any fields that contain user identifiable information such as the user’s name or e-mail address are optional and may or may not be included in launch data at the discretion of the administrator, instructor, or even student. Tool Providers should be prepared to handle situations where this data is not provided. In particular, the user’s E-Mail address is considered optional and should not be used as a primary key for a user record in the Tool Provider.” (https://www.imsglobal.org/basic-overview-how-lti-works)

In practice too many implementations do require name, or email address information in order to set up an account in the tool provider. I can think of at least one main-stream tool that has made email the primary key for a user record even. Aaargh.

So we need to clean up. In the case of blogs there’s a very high likelihood of personally identifying information being included in the body of posts. So we need to be able to remove old blogs.

There are a couple of options for doing this. If one has an identity management system (I do) you can push information about accounts that are ageing out and remove them from the blog. There are some obvious questions about content that come with blogs though.

• Do we delete all student content? I’d say yes in general, but then there will be courses where we have to keep copies of student work for professional accreditation purposes for a set number of years (Medical students – 7 year retention period I think). Options might include printing to PDF, or making an HTML copy which is zipped up and stored offline. Also need to think about what happens when you need to remove a single student in a shared site?
• Do we delete all staff content? I’d say probably not if it’s in the context of teaching and the course is still active. But then other sites will be appropriate to remove completely upon leaving the institution. How do we determine this programmatically? Not easily.

One immediate thought I had a while ago (see the Temporary Autonomous Zones bit of this rant) was that we could set an expiry date on every blog at the point of creation. By default it could be set to 12 months from the point of creation. A plugin with an associated data table holding the blog ID and the expiry date would do the trick, plus a cron job that blows the site away come the expiry date. We’d need a nice big warning on the dashboard too – “Your blog will auto-destruct on <insert date>” and an option to renew your site for another <whatever the appropriate period is>. I like this option for a few reasons:

• It’s how the real world does work if you buy your own hosting.
• You are in control, or at least someone has to be. Sites could change hands reasonably comfortably and persist even as VLE courses fall away (again this implies having an SSO front door as well – and hence a consistent use of username that works across the institution – which is why identity management is so fundamentally important imho).
• It makes you think about how long you actually want to keep the site for. Thinking about how long you want “stuff” on the web is a good thing to think about.