Port to new HTML5 Player?

I see from that blog post it's currently in beta; and surely at any rate this needs to be an option so sites that don't or can't output HTML5 can use the old player.

I'm only doing maintenance fixes on this module, as it's no longer used on any of my active projects. Hence this is not a feature I have free time to work on. However, if you can write a patch and get it reviewed, I'll commit it and make a new release :)

if you can write a patch and get it reviewed, I'll commit it and make a new release :)

Any volunteers or other people who might be intrested in this?

Hi everyone,

I too am very interested in this. I have a technology podcast site that has the Soundcloud flash player embedded for each episode. I am using this module which has been working flawlessly up to this point. I am terrified that I'll wake up one morning and everything will just stop working. Soundcloud has said that they will be switching over to the HTML5 player soon. Is there a way I can go in and change the PHP of the module to simply point to the new player or can someone release an update to this module (I usually use drush to update my modules)? This is something I've been wanting for a while also because the flash players do not work on iPad and iPhone. It would be nice for everyone to listen to the podcasts I work hard to produce.

Thank you to all drupal developers. People such as myself would never have been able to launch a decent drupal site without all of the modules you guys work hard to create.

KB

> Is there a way I can go in and change the PHP of the module to simply point to the new player

That would be the work needed to resolve this issue -- please file a patch if you can spare the time to work on this :)

Unfortunately, I don't have the technical chops to do this. I'm not very knowledgeable with PHP. Is there someone who can create a patch or instruct on which lines in the PHP code to modify?

Thanks

Hi,

I've added a 'Use HTML 5' option to the D7 version.

This will send the iframe = true parameter to SoundCloud, which on its oEmbed doc page is described as:

(optional) Whether the new HTML5 Iframe-based Widget or the old Adobe Flash Widget will be returned. The default will be set to true end of January 2012.

I suspect if we don't do anything, this will eventually just automatically use the HTML5 widget since that will be the new default for the iFrame parameter. But it is nice to have that option. And when I checked today, it was still returning the Flash player by default.

This is a screenshot of the admin/config/media/file-types/manage/audio/file-display/media_original page:

I have merely added this as a clone of the 'autoplay' option. Unlike the 'autoplay' option, I have set this as true by default, since most people will want to use it. The HTML5 version looks much better!

You can test this by using the 'original' format. The 'large' format is broken somehow, it was broken before I started. Will add a ticket for that.

Cheers,
Victoria

Looks good overall, just a few comments and tweaks:

+++ b/includes/media_soundcloud.formatters.inc
@@ -63,6 +64,11 @@ function media_soundcloud_file_formatter_audio_settings($form, &$form_state, $se
+  $element['iframe'] = array(
+    '#title' => t('Use HTML5 player'),
+    '#type' => 'checkbox',
+    '#default_value' => $settings['iframe'],

I'm a bit disturbed by the mismatch between the label and the setting name. Will the HTML5 always be in an iframe? Does the setting name accurately reflect its meaning now, and will it still in the future, say when output in an html5 theme, or on D8?

+++ b/includes/MediaSoundCloudStreamWrapper.inc
@@ -74,9 +74,9 @@ class MediaSoundCloudStreamWrapper extends MediaReadOnlyStreamWrapper {
+  public function getOEmbed($url, $iframe = 'false') {

Is this likely to have more params in the future? If so, I'd be inclined to pass in an $options array with named keys.

Also, check whitespace changes in the patch please :)

I don't have a soundcloud test setup, so could users of this please test the patch? Only way it's going to get in is with actual testing :)

Hi Joachim,

Thanks for looking at this so quickly. Regarding the parameter name, I named it iframe, because that is what it is called on SoundCloud's api. It seems on SoundCloud that means you want to use the HTML 5 player (see my quote and link to SoundCloud's documentation above). Perhaps to make it clearer, the option's label could say 'Use HTML5 Iframe-based widget'.

Good idea about using an $options array for the parameters. I am thinking of adding a 'show comments' option some time soon too.

Regarding the whitespace git warnings in the patch, I had the same problems when testing it too. But annoyingly the error message isn't clear on where the white space error occurred. Do you have any tips on how to debug this other than manually typing in my changes again?

Thanks,
Victoria

Hi,

I've fixed the whitespace issue using this, and then re-rolled the patch:

git apply -v --whitespace=fix [patch-name.patch]

I'm attaching a new patch with the whitespace issue fixed, as well as using the $options array as you have suggested, and also I have rephrased the HTML 5 option label as 'Use HTML5 iframe-based widget'.

I can rename the field name if you still think it should be renamed.

Cheers,
Victoria

> Regarding the parameter name, I named it iframe, because that is what it is called on SoundCloud's api.

That's a good enough reason for me :)

Note that I don't have a D7 install of this -- it's up to other users to try the patch and report back their findings.

I tried media_soundcloud-use_html5_player-7.x-1.x-1355902-9.patch and it works good, only got a small problem with a Views page display listing a song content type containing soundcloud embeds in the body. Don't know if any more work already has been done, but i guessed: report it, so i can learn if anybody already fixed this. Rendering on nodes works fine, also in blocks works fine, it's just the Views page that is the problem.

Thanks for testing, ClusterFCK.

It seems like Soundcloud is now returning the HTML5 player to oembed requests regardless of request parameters. Can someone confirm this?

I have re-written the patch to make it work with any parameters so site admins can use all the params supported by oembed, and we won't have to constantly update this when Soundcloud change their params. And if Soundcloud isn't returning HTML5 players by default as I had thought, you could use this to specify the iframe=true param to get the HTML 5 widget.

Also I noticed that WYSIWYG embeds seem to be broken and is loading the entire soundcloud page in an iframe instead. And hence in my new patch, I have also cleaned up the old JavaScript Flash embed stuff in media_soundcloud_preprocess_media_soundcloud_audio().

Sorry for including so many issues in this one patch. But they all seem to be related.

Can someone please test this to let me know if it works in both WYSIWYG and media field?

I have tested using both WYSIWYG media browser and media field with Media 7.x-1.2:

projects[media][version] = 1.2
projects[media_soundcloud][version] = 1.0-alpha1

and also Media 7.x-2.0-unstable6:

projects[media][version] = 2.0-unstable6
projects[file_entity][version] = 2.0-unstable6
projects[media_soundcloud][version] = 1.0-alpha1

So to summarise, this new patch will clean up the theming code, and add a new 'Extra parameters' field (extra_params) to the file display configuration page under the width and autoplay options (I'm keeping the two fields to make it backwards compatible).

Please test, and thanks!

Committed patch in comment #13 to 7.x-1.x-dev branch

Hi,

One month ago, all was working with the 7.x-1.0+6-dev version. Now, I'm not able to change the color properties and also, the HTML5 player not working. Is it possible that Soundcloud has made changes in its source code? Am I alone with this problem?

I can't change the HTML5 player's properties... and what I see it's a huge image of the player...

Here a link to a screen shot with those properties: "iframe: true, color: 2582fa, show_artwork: true, show_playcount: false, show_comments: false, show_user: false, sharing: false"

@Ludovik Yep...Same happens for me too.

Dhamub & Ludovik, I have the same annoying problem and created a new issue. Hopefully a solution will be found in the near future.