Add webp to supported image types for Interactive Video image

jeremydouglass's picture

Add webp to supported image types for Interactive Video image

BACKGROUND

Currently the Image (thumbnail / preview) for an Interactive Video does not allow the webp image type in the editor. Attempting to submit a webp image as a thumbnail generates the following error message in the Interactive Video editor:

  • Only files with the following extensions are allowed: json png jpg jpeg gif bmp tif tiff svg eot ttf woff woff2 otf webm mp4 ogg mp3 m4a wav txt pdf rtf doc docx xls xlsx ppt pptx odt ods odp xml csv diff patch swf md textile vtt webvtt gltf glb.

FEATURE REQUEST:

Alter the image editor dialog so that it allows image files with the .webp file extension. 

For example, YouTube videos serves webp format thumbnails automatically by default for browsing lists and inter-video navigation overlays. A person wishing to build H5P content thumbnails from public domain videos -- for example, https://www.youtube.com/channel/UCRpa0nQ2JQEh628cpyEFvtQ/videos -- must still convert each thumbnail from webp to png in order to make it compatible with H5P, even though it is supported in almost every browser (https://caniuse.com/webp). Ideally, the H5P editor would simply support this format so that conversion was unnecessary. From the error message, it *might* be as simple as adding .webp to the list of permitted extensions...?

 

Summary: 
Add webp to supported image types for Interactive Video image
Content types: 
1
0
Supporter votes Members of the Supporter Network can vote for feature requests. When the supporter network has generated sufficient funding for the top voted feature request it will normally be implemented and released. More about the H5P Supporter Network
otacke's picture

Hi Jeremy!

I don't know how common Safari 13 and below still might be and if things like editing an image work, too, but in theory this should in fact only require to allow .webp files (and to test thoroughly).

Feel free to give it a shot on a Drupal instance that allows to change the list of allowed file types in the settings. You could also add wepb to the list inside the h5p.classes.php file on your platform (cmp. https://github.com/h5p/h5p-php-library/blob/master/h5p.classes.php#L2086), but while this is a pretty straightforward thing to do, I don't recommend it if you don't feel confident to do that.

Best,

Oliver

jeremydouglass's picture

Hi otacke, thanks so much for this config advice. As I am looking at using H5P with a small team of researchers using Lumi as an interface, I may also reach out to Lumi to see if they would consider incorporating this change (if it works).

Other than valid types for image editor(s), are there any other potential problems you might anticipate from allowing webp (in core or in core extensions)? If I know what they might be, I would know how to do sanity checks to test for for them before recommending the change.

with regards,

Jeremy

 

 

otacke's picture

Hi Jeremy!

I am sure Sebastian will consider adding an option to change the list of allowed content types. However, I must correct my previous post. Adding `webp` to the list of allowed file types alone will not be enough. There are additional handlers for media in the H5P editor core.

So in total, tiny changes are needed at:

While H5P integrations can amend the list of allowed content types in general (thus overriding the first line of code that needs changing), the others will still prevent uploading webp images. So, unfortunately, Lumi alone cannot solve this. Even if Sebastian patched H5P editor core for Lumi, then you'd not be able to use webp on other H5P integrations that don't run the patch. H5P would complain that the image type is not allowed when uploading content from a patched system.

If a browser can display webp, then I don't think there will be any further issue - one should check the rudimentaty image editor for images that H5P ships, but I assume there won't be a problem with that.

Best,
Oliver

jeremydouglass's picture

Thanks so much for these webp patch details, Oliver.

If I was going to fork, commit these changes, and submit a pull request, can you recommend a test environment or build process that I might set up? I'm not sure how changes to h5p-php-library are tested, e.g. to check for regressions. Is it tested through including the feature branch of the library in a testing branch of a wordpress, drupal, or moodle h5p plugin?

jeremydouglass's picture

Thanks so much for these webp patch details, Oliver.

If I was going to fork, commit these changes, and submit a pull request, can you recommend a test environment or build process that I might set up? I'm not sure how changes to h5p-php-library are tested, e.g. to check for regressions. Is it tested through including the feature branch of the library in a testing branch of a wordpress, drupal, or moodle h5p plugin?

otacke's picture

Hi!

I usually use a Drupal system, but it should work with other platforms, too. Instead of running the core files supplied by the plugin, you can remove them and replace them by cloning the repositories to the same position and rename the cloned repository directory name as required. You can then branch, run and test your changes and create a pull request when you're satisfied.

If you replace the H5P editor core files, please note that the H5P Hub client is in a separate repository and needs to be built separately.

Given that you only need to change a couple of lines of code, you could as well just hack them into the original files from the plugin, test, and if everything works nicely, just clone the core repositories somewhere else, branch and apply your changes there. That's probably quicker here.

Best,

Oliver 

I have just posted in the H5P group.

This makes so much sense. I'm a big fan of .wepb images and will defintely keep the inerations super light.

Adding .webp, in the code base would allow users to use much lighter images. It is also a much better format than gif for animations. Having .webp implemented in the base code would allow me to create stunning animated visuals. As this format is supported by nearly all recent browsers, that would make sense to implement. Especially considering it seems to just be a matter of changing a few lines of code.