WordPress LTI Testing: Part 3

This follows on from:

The code I am working with is in a GitHub repo here: https://github.com/ammienoot/wordpress-lti

After exploring what’s going on under the bonnet in the messaging, my shopping list now is to change the WordPress LTI plugin code to make the following happen:

  1. Reliably send our UUN – what is going to work across our VLEs best?
  2. Include the email address in WordPress if it has been sent from the VLE*
  3. Add some options to the WordPress plugin to allow configuration of role mappings between a VLE and WordPress as part of the Consumer configuration (mainly to choose whether to default to Author or Subscriber for the Student / read-only role) **
  4. Set the slug of the WP site based on the value of context_id (with an increment to allow for multiple blogs per course). If this can’t be done so easily then I want to amend the title of the site to include context_id – I need the unique course instance code embedded somewhere so that I can find it programmatically later for audit / clean up purposes.

If I can do all of this, I’ll have met Use Case 2(a) and Use Case 3 here: https://ammienoot.com/ngdle/laying-it-all-out-in-order-to-begin/

The other two use cases need a bit more thought, so this will also get me up to speed and think them through.

*A thought – possibly email address isn’t being included because this plugin allows multiple WP accounts to be set up for the same user and WordPress doesn’t like 2 users to have the same email account. There are plugins that work around this (https://wordpress.org/plugins/allow-multiple-accounts/) so there must be a sensible solution available. At the very least it should be possible to add it when the ‘Global’ username option is being used in the Consumer configuration in WP as this will use the user_id value from the VLE which should be the same for all connections from that VLE.

** The building block we use in Learn allows this mapping to be set at the VLE side of things, but that isn’t going to be extensible. My ideal is to have the mapping in the LTI definition on the WordPress side of things as I suspect few people will be able to tinker with the core LTI functionality of their VLEs. Hopefully this will work.

WordPress roles

  • Administrator
  • Author
  • Contributor
  • Editor
  • Subscriber


“Some of the commonly used roles from LIS include Learner, Instructor, Administrator, TeachingAssistant, ContentDeveloper, and Mentor.  Multiple roles can be included, separated by commas.  TC systems should include as many roles as appropriate for the user (i.e., more roles are better).  TC systems should be aware that simple TPs will key off the presence or absence of the Instructor role and group users into those with the Instructor role (read-write-configure) and those without the Instructor role (read).” (https://www.imsglobal.org/specs/ltiv1p1p1/implementation-guide#toc-11)


2 thoughts on “WordPress LTI Testing: Part 3

  1. Hi Anne-Marie, it has taken me longer to sink my teeth into your LTI work, but I’m sinking them now. The 3 (well possibly 4 if 2a and 2b turn out not to be very amiable companions as sub-cases) nicely capture the

    The email address issue that you raise is an interesting one. At first glance it seems that one way through the issue would be to check for an existing user account and create the account if not, attach the new site to the account if it does exist already. However, this is not the first time the first time we’ve seen this issue at our institution. We use the NS Cloner plugin which provides interface to create a new site admin when cloning, but chokes if you feed it an existing site admin.

    I have a feature request in to the NS Cloner devs about this, if they find a solution it may be usable here as well. Or vice-versa.

    Something in the back of my mind makes me a little uneasy about the multiple account route. I’m not sure what though, the back of my mind is full of rubish and hasn’t been tidied in years. Can’t find a thing there.

    1. Thanks for your comments Troy – I tend to agree with your thinking regarding multiple accounts. One of my big concerns is being able to reliably delete users and content to be compliant with EU Data Protection law and so being able to identify users easily is pretty important. Also feels a wee bit weird to have a fragmented digital identity. I think some more testing to see if we can figure out the email behaviour is required and as you say, a check and add to existing user would be the right logic.

Leave a Reply to admin Cancel reply

Your email address will not be published. Required fields are marked *