I posted a question in the Fediverse this week. I had learned something about moodle’s custom H5P integration and wanted to know how people who use it in practice deal with it. The question was:
“Question to all #moodle users/admins who use #H5P with moodle’s custom H5P integration (aka blue H5P): How do you handle upgrading existing content to newer library versions when a minor version update of a content type is released?”
and I allowed the answer options:
- What?
- I don’t care to upgrade existing content.
- I edit/save each existing content to upgrade.
- Something else, I’ll add a reply with details.
I am now explaining what this was about by commenting on the answers (summing up to more than 100 %? So one can vote multiple times somehow on Mastodon?).
What? (36 %)
You have created content with a content type. Let’s assume it’s version 1.3.6. From time to time, there may be a newer version of the content type library. It could a small patch, and the new version would be 1.3.7. Then updating the content type will overwrite the existing content type library with this new patch version.
So far so good. There may be more severe updates, so called minor updates. Those change more things. In particular, the structure of the content type patameter may have been altered (new option here, some other option moved, etc.). Let’s say this is version 1.4.0. This new version will be installed in addition to the 1.3.7 library. Your existing content will still use 1.3.7. Only newly created content will use 1.4.0.
In order to benefit from new features or bug fixes that came with 1.4.0 or later, your existing content needs to be upgraded – in particular the structure of the parameters may need to be altered. H5P will upgrade existing content to the latest available local version automatically if you edit it and then save it. Same goes for when you upload content to a platform that already runs a newer library version. This needs to be done for every content, one by one. This can be tedious, so H5P integrations usually have a batch upgrade process that allows you to upgrade all instances of a content type at once.
moodle’s custom H5P integration, however, does not have that batch upgrade feature. So unless you take care of your contents one by one, at some point you’ll host lots of contents with potential issues.
I don’t care to upgrade existing content. (36 %)
This is actually the most interesting answer. Does it mean that you are not aware why upgrades are useful? Or do you not care about potential bugs in your content that might be fixed in later versions? Are you the admin or responsible person for the platform yourself or doesn’t she/he care either?
I edit/save each existing content to upgrade (27 %)
Well, what else should you do. But how many contents are we talking about? 5? 10? 100? More? This could (should) be automated. Unless you need some boring and inefficient but surely meditative phases, of course. Have you ever wondered why it is that way? Have you ever requested a change somewhere
Something else, I’ll add a reply with details (9 %)
There was one comment, hinting to the cron job that can update H5P libraries automatically. However, updating libraries (by minor version jumps) does not upgrade existing content!
Why is this relevant?
I have had to deal with numerous questions and complaints from different people about why something was supposedly broken or not working properly. It turned out that an outdated content type version was used (sometimes severely outdated). The bugs had been fixed years ago, but the contents had never been upgraded.
That may sound like a nuisance only, but if, for instance, you gave money to an organization that was supposed to assess the accessibility of H5P and they assessed outdated content type versions, then you might be a little frustrated. If there were some serious bugs that hid in the dark, you’d probably also not be too delighted if they surfaced.
A minor issue is having dozens of libraries that are outdated and which in theory could be deleted, but the old contents are still using them – so they are still required and take up storage space.
Also, H5P compound content types like Column or Course Presentation usually allow to use subcontents. Instead of creating everything from scratch, you can paste your existing contents into the compound content type. However, a compound content type can only handle one specific minor version of each subcontent. If Column, for instance, requires Fill in the Blanks 1.14, you cannot paste content that was created with Fill in the Blanks 1.6 or Fill in the Blanks 1.13. You’d want to upgrade these existing contents to version 1.14.
Conclusion
At least for me, having some batch upgrade mechanism (that H5P Group’s H5P integrations have – even though it could be improved) feels essential for admins. You’d not want known and fixed bugs haunt your platform, do you? If that poll had been representative, then I’d be led to believe that this topic is not yet understood as well as it probably should be.
Hope this post helped you a little.
If you want to help: Vote for this ticket on the moodle tracker (https://tracker.moodle.org/browse/MDL-70918) that is close to 3 years old now and didn’t seem to catch much attention at moodle HQ so far.