Documentation is not one of the H5P project’s strengths. This is true of H5P Group‘s H5P plugin for Moodle as well. It does not explain many of the tweaks you can use to customize your setup. You won’t find them all in one place. Let’s close that gap.
All the custom settings are controlled by setting configuration variables in Moodle’s config.php file. Just add them with appropriate values as needed.
Example: $CFG->mod_hvp_crossorigin = "anonymous";
Asset aggregation
H5P content usually builds on various H5P libraries. Each library comes with at least one JavaScript file and, usually, at least one CSS file. Older libraries often contain more than one of these files. In total, that’s a lot of files for the server to load, and each file request adds a little overhead to the loading process. In other words: This can result in slow performance.
H5P integrations, such as the H5P plugin for Moodle, therefore contain a method to aggregate assets. H5P bundles all the JavaScript and CSS files a content type needs into one file each. Consequently, servers only have to handle two files to deliver the code to your browser. This usually results in a significant speed improvement, but more storage space is required to host all the cachedassets.
Side note #1: This mechanism was more important back in the days when H5P was built and HTTP/1 was kicking. Meanwhile, HTTP/2 changed the calculus significantly, of course.
Side note #2: Moodle itself normally does the same for all JavaScript files by default, too (“cachejs” option).
$CFG->mod_hvp_aggregate_assets
This settings allows you to deliberately turn off asset aggregation, so H5P will load each and every JavaScript and CSS file separately without any caching.
Set mod_hvp_aggregate_assets to "0" to deactivate the cached assets.
Deactivating asset aggregation should rarely be necessary, but it can be useful for debugging if something fails. For example, there may be cases where H5P libraries refuse to work due to developer error or ignorance.
Backup behavior
When you back up a Moodle course containing H5P content, the plugin ensures that all necessary files for restoring the H5P content are included in the backup file.
By default, every backup of a course containing H5P content includes copies of every used library and all its dependencies and related database tables, even if the same library is used in 50 courses. While this is very safe, it significantly increases the size of the backups.
$CFG->mod_hvp_backup_libraries
The mod_hvp_backup_libraries setting can be set to "0" in order to not backup the library files at all. H5P contents will still contain a reference to something like “H5P.CoursePresentation 1.26”, but the respective library will not be stored. That will make the backups much smaller (and the process will run muuuch faster, but that’s a separate topic).
However, the trade-off is that you will need to ensure all the required H5P library in the expected version are installed when restoring a backup file. It’s not usually enough to only ensure that the latest H5P libraries are installed. If H5P content cannot be served with the necessary H5P library version, it will not work. Some people have gotten themselves into trouble because they were unaware of this fact.
Cross-Origin-Resource-Sharing (CORS)
There are three different variables related to cross-origin serving. They control whether media that H5P content types use (images, audio, video) loaded from other Moodle sites in a multisite network are served with the Cross-Origin-Resource-Policy header. This matters because browsers block cross-origin media if the remote server doesn’t explicitly allow it.
$CFG->mod_hvp_crossorigin
With this setting you can tell the plugin to add the crossorigin attribute to all local H5P media requests. This is needed when the Moodle site serves H5P assets over HTTP but embeds them on an HTTPS page (mixed content), or when a reverse proxy / CDN strips or rewrites the Cross-Origin-Resource-Policy header.
By default, nothing will be set here. That means, the browser relies on the remote server’s CORS headers. If you want to change this, you can use the following values:
"anonymous": By setting this value, the attributecrossoriginwill be set toanonymouson<img>,<audio>, and<video>elements. The browser send the request without any credentials, and the remote server must respond withAccess-Control-Allow-Origin: *(or the requesting site’s origin)."use-credentials": Same as above, but the browser includes credentials (cookies, auth). I’d say this will rarely ever be used.
$CFG->mod_hvp_crossoriginRegex
This setting allows you to whitelist specific domains that need crossorigin handling. If crossorigin is set but crossoriginRegex is not, the attribute is applied to all local media. That is usually fine, but unnecessary overhead if only a few external sources need it.
By default, nothing will be set. You can use any valid JavaScript regular expression string here, such as "example\.com" or "subdomain\.example\.com". If set, the plugin only adds the crossorigin attribute to media whose source URL matches this regular expression. This lets you target specific external sites, for instance a file server or another Moodle site, without affecting all media.
$CFG->mod_hvp_crossoriginCacheBuster
This setting can be used to ensure that crossorigin and non-crossorigin requests for the same file don’t collide in the browser cache. Without this, users might see outdated media after a site update.
The setting should be set to a regular query-string fragment that changes as needed for your use case. Only if it’s different to what was cached, the cache will be busted. So, a value to set it to could be "cachebuster=" . time(). Of course, using the current time to bust the cache essentialls defeats the purpose of caching to begin with, so adjust this to your use case.
Development
H5P Group built a dedicated development environment for H5P content types, the H5P CLI that is very useful. Some people (still) prefer to develop content types on a Moodle instance though. And that’s painful, normally. Won’t go into detail here, you’ll see why not in just a second. But there’s this one setting …
$CFG->mod_hvp_dev
You could set mod_hvp_dev to "1". That would have activated a development mode that would have made H5P ignore the patch version when uploading a library – you could have installed a library with the same major/minor/patch version over and over again and with changes. I am using modal verbs here, because this feature does not work here anymore. H5P Group (accidentally?) removed support for it in H5P core. It’s not thaaat important. As mentioned, you can develop using the H5P CLI much better anyway. But sometimes having this option would be handy when you need to test or repair things …
Side note: The H5P plugin for WordPress suffers from the same problem
Export file control
H5P contents can usually be downloaded via the “Reuse” button in the action bar underneath the content – unless the content author deactivates that option. To support this feature, H5P will store a ready-to-download export file instead of generating it on-the-fly per request. Faster, but uses more storage.
You can set something similar in Moodle’s site administration settings for the H5P plugin. That’s where you have an “Allow download” option that lets you control if the download option will be offered. Instead, the configuration variable controls whether the export file that is supposed to be downloaded will be generated in the first place. And you could use the variable to only allow downloads to certain Moodle user roles or to come up with other guards.
In case you want to change that …
$CFG->mod_hvp_export
The mod_hvp_export setting can be set to "0" or false or left unset.
"0": Export files will not be generated for newly saved content. Existing export files will not be deleted though. That’s what you’d choose if no H5P content should be downloadable and if you wanted to save storage space.false: Export file will be put into storage, so there still is an export URL that you could use to download the content even if you forbid users to have the download option. Maybe you have a use case for that …- If not set, export files will be generated and the download behavior will depend on the “Allow download” setting (mod_hvp/export) in Moodle’s site administration.
File storage
H5P needs to store files somewhere: for JavaScript, for CSS, for assets such as fonts, and for media that authors add to their H5P contents. The core of H5P does not do so directly, but leaves that job to the H5P integration (e.g. the H5P plugin for Moodle) that implements storage management for the underlying platform (e.g. Moodle). See “What was that thing again? An H5P achitecture overview”.
By default, the H5P plugin for Moodle uses Moodle’s File API to write files to your server’s hard disk. There’s a dedicated class for that job. But what if you wanted to use something else? An S3 bucket, Google Cloud, or a Redis layer on top of your storage?
$CFG->mod_hvp_file_storage_class
With the mod_hvp_file_storage_class variable, you can specify a string with the PHP name of the class that implements H5P’s file storage interface. By default that is "\mod_hvp\file_storage". Of course, your custom class must implement the same interface methods to read files, write files, delete files, list files, etc.
Library configuration
H5P content types all come with their set of options that are defined in a semantics.json file. If you for instance don’t like the default values or if you want to hide one of the settings, you can use H5P’s alter_semantics hook (worth a post of its own including its siblings). This way, you can change the options in the H5P editor interface where authors edits their content.
But what if you wanted to change that (dynamically) without an author setting something? Or if you wanted to override the authors settings without actually changing them in the parameters? Then, there’s a theoretical way at least. Again, I’ll use modal verbs …
$CFG->mod_hvp_library_config
With the mod_hvp_library_config setting, you could override or extend the default behavior of specific H5P libraries without modifying the library code itself. The value would need to be a nested associative array with H5P machine names as the top level keys, followed by the semantics structure that you’d want to override.
For instance, you could use ['H5P.Video' => ['playback' => ['autoplay' => true]]] to enable autoplay for all videos. If you computed the value server side, you could also make things dynamical and e.g. change the number of questions shown from a QuestionSet pool based on criteria that you define.
BUT … Alas, in order for that to work, H5P libraries would need to use the H5P.getLibraryConfig function. Only does, MathDisplay which is used to render LaTeX code.
The MathJax library expects an object at renderer.mathjax.config holding MathJax configuration that would then override the default settings. For instance, this will enable the context menu that will appear if you right-click math (disabled by default):
$CFG->mod_hvp_library_config = [
'H5P.MathDisplay' => [
'renderer' => [
'mathjax' => [
'config' => [
'options' => [
'enableMenu' => true,
],
],
],
],
],
];
So, effectively, mod_hvp_library_config only serves to customize LaTeX rendering with MathJax for now.