Comments

I guess some modifications would be nessecary. It says at the bottom of the article you linked to that if you point the player to a local source, it would solve the issues. That would mean that you edit video_filter.codecs.inc to fetch each player (usually .swf) from a local soource instead, and point mod_proxy there. I have no idea if this works though, so if you solve it, please do a write-up so others can benefit!

I had this issue come up as well and although it does seem like not all sites have to deal with this, more and more sites are going all SSL. Given that, it was fairly simple to just rewrite the http in the theme function in our custom theme. But it would be much easier for most as an option in the settings! :)

As I've stated, I'd be happy to look at a patch that adds settings for this. Also, if anyone can add a sub page here http://drupal.org/node/402796 to explain how this is done in the meantime, that'd be great.

thank your for your input. Did what you said and made a new file "template.php" that starts with a < ? php and ends with a ? > (sorry for the spaces, this editor was showing code) in between there is the pasted code from the book page.

I changed the owner and the permissions like the other files: root:www-data, 640.

Put it in "/var/www/mydomain/htdocs/sites/all/themes/mytheme/", refreshed the page and still I have a mixed warning (padlock with a little triangle).

Put a copy in "/var/www/mydomain/htdocs/sites/all/themes/mytheme/templates/", refreshed the page and still I have a mixed warning (padlock with a little triangle).

Restarted the webserver, still noch change.

After that I maually changed the links in all the videoplayers from http to https, still no change.

The only pages I get the mixed warning are the pages with the video filter. All other pages display a green padlock.

Do I need to reference that template from somwhere?

Best wishes,
Paul

Update: puting the template.php in the bartik theme produces the following fatal error:

no success yet - did everything the way you wrote. Still not secure :-(

My fatal error earlier on produced an interesting side effect: my custom theme color is back to the standard bartik blue and no amount of changing, de-installing and reinstalling will convince my drupal to change back to my custom color or any other color for that matter. Seems that the color module is broken now.

Another problem, another night.

Best wishes,
Paul

P.S. My site uses a combination of User Realationships and content access to achieve something like facebook. Maybe that's srewing up the fix.

thought about possible reasons why the fix on the bookpage (http://drupal.org/node/1443168) did not work on my site. I use plaintext with wysiwyg editors for my users to post their videolinks and their articles:

IMCE Wysiwyg API bridge

Wysiwyg

CKEditor

Could it be, that the above mentioned fix does not work due to these modules?
Just taking wild stabs in the dark here :-)

By the way, my messing around with the template.php really messed up my system for good. I have some errors that don't even go away after a complete drupal update and a re-installation of the bartik theme (http://drupal.org/node/1731382). I've no idea how I managed that, since I made *.bak files of erverything I changed and restored them in SSH when things went wild.

Bumping up to latest stable version, and opening again as this is still unresolved. Also renaming and turning into a bug as SSL support is a given for Drupal modules.

A theme level fix, such as #9, is not a good or permanent solution. A schema-less approach to URLs, like #10 suggests, is tried and true and used in all sorts of other Drupal modules, let alone outside the Drupal community.

Proposed Solution

For video services that support SSL, such as YouTube, use schema-less URLs. For services that this is unknown, use http.

And to get us started, here is a patch to 7.x-3.1 that turns all Vimeo and YouTube links schema agnostic.

@pianomansam, Thanks. I used changes similar to the patch in #21 for 6.x-3.1 and it seems to work fine.
Essentially in video_filter.codecs.inc doing a search for "$video['source'] = 'http:" and removing the "http:"
I'll have to see how further testing goes.

ollu, by removing "http" or https" from the beginning of a url and simply starting with "//", the URL will pick up whatever the current protocol is. This is referred to as making the code protocol agnostic. This way if they Drupal page is being served up securely, the video will be served securely as well.

ultimateboy, which services did you try? I'm afraid of making everything schema agnostic because some services might not support both http and https. If a service doesn't support https and you attempt to connect via https you'll get no response from the server. I think it'll be much safer to only make agnostic the services we are sure support both.

I simply tested youtube. However, in my opinion, modern browsers wont display the video anyways because of mis-matched content. But I see your point. I just dont have the bandwidth to test this patch against all the services.

Since there are a number of video services that don't support SSL, an scheme agnostic approach does not seem like it will work, unfortunately. I'm setting this back to Needs Work as it looks like we need to hash this out more.

Personally, I believe that waiting for each provider to be reviewed is the exact opposite approach that should be taken. We *know* that because of mixed content warnings, an http video will simply *not* show on an https site. We know that switching the url to be protocol agnostic will fix this issue for any provider that supports https. If they don't support https then it doesn't matter what we do, their videos won't show on sites with https because of mixed content.

IMO, the right approach is to apply the patch that's provided and let any services that don't support https fail... cause even today, those same videos fail anyways due to mixed content.