Steel Wagstaff at Pressbooks has been talking to me for the past few months of a relatively new feature of Pressbooks where, when you clone a Pressbooks book it will now bring over all the H5P activities within that book.
While this feature has been available for Pressbooks network users, for us at BCcampus where we host our own instances of Pressbooks that is a bit behind the update schedule for Pressbooks network clients, we have had to wait for the feature as we worked our way through updating our Pressbooks network. Thanks to the work of the BCcampus Dev/ops team and Josie Gray, the update to our networks happened a few weeks ago and I was able to finally test out the H5P cloning feature on our instance.
Caveat: if you are self-hosting your own Pressbooks network, you need to have the H5P plugin installed and both the H5P plugin and Pressbooks plugin need to be up-to-date. At the time I write this that means H5P WordPress plugin ver 1.15.0 and PB version 5.13.0, although, as you will see below, during my testing I uncovered a bug in the H5P WordPress plugin that is scheduled to be fixed in the next release.
I tested the cloning feature using this great Body Physics textbook from Open Oregon that I knew had a lot of H5P interactions in it. Cloning the book is not that difficult (Pressbooks has a good step by step guide) and, with the exception of the issue below, worked quite well.
The cloning process itself does take some time, about 10 minutes to complete for this particular book. For testing I am focusing specifically on how the H5P content came over (as opposed to the PB content) and, for the most part, the cloning routine did a very good job of copying all the H5P content included in the book. When I went into the H5P Content section, I see all the H5P interactions there indicating that everything came over in the clone.
If I check out the H5P interactions in the book, I can see that the H5P interactions kept their original context within the book. That is, they appear in the same place in the cloned PB book as the original source book. Additionally, when I looked at the embed url for each H5P content type in the cloned book, I see that the H5P content now lives within my book separate from the cloned book. It has not simply been embedded in my book from the source book. A full copy has been created within my book so that I can modify and customize without affecting the upstream version. In the future, it might be useful to see the copy as a fork of the original with links back to the original version somehow instead of a separate and discrete copy of the element. But that would require a lot of future development work. Put that on the wishlist for the future (and, imo, low priority as I think that, while forking is an elegant way to be able to trace derivatives to/from, it would be something that very few users would ever actually use. I’d like to be proven wrong with that assumption someday, but right now I don’t think there is the level of engagement with revising OER’s that warrant the development effort).
However, all is not perfect. I notice that the author attribution in the copied H5P elements is incorrect. I am listed as the author of all of them.
One of the features I love about H5P is that you can add CC licenses to each individual H5P element, which makes the rules around sharing and attributing content much easier and, imo, is one of the big reasons why I think H5P is an OER platform as there has been care and consideration on the part of the H5P developers to add this as default functionality in H5P. But it is problematic if all the H5P content imported loses attribution information, and falsely attributes all the imported content to the person doing the importing.
At first I thought that it might be that the attributions were not set correctly in the source material, and, sure enough when I went back to the original book I did not see any visible license information where I would expect to see it.
I tested with another book with the same result – I was credited as the author with all the imported H5P elements. I contacted Steel at Pressbooks to double check that this was unexpected behaviour and we did a quick test together, creating a new book with a new H5P element with proper attribution and imported that into a new Pressbooks book. Again, the H5P element was attributed to the person importing the book and not the original author.
Steel confirmed that this was unusual behaviour and created an issue in the PB GitHub repo reporting the issue. After some BA work on the Pressbooks side it was discovered that the issue was upstream in the H5P WordPress plugin. A report was filed there and the developers of the H5P WordPress plugin have developed a fix that will be released in the next release of the plugin. So, with luck, this cloning attribution issue should be fixed soon.
Other than that issue, however, the cloning routine itself is very slick and sets the foundations to make the reuse and adaptation of H5P content in Pressbooks much easier.