Media filter should not generate absolute URLs

Can we get media to insert protocol-relative urls?

As much as I'd love to use protocol-relative URLs, the use cases of displaying data not on the same domain (in e-mails, RSS feeds, etc.) is a big reason we can't really use it universally.

Also, we would need to patch core's file_create_url() function to allow non-absolute paths because that's the API function which is universally used.

I have the same issue. on https:// pages I see absolute image paths with http://
which is a problem because chrome throws warning icon.

The site uses SSL, but Google Chrome has detected insecure content on the page. Be careful if you’re entering sensitive information on this page. Insecure content can provide a loophole for someone to change the look of the page.

https://support.google.com/chrome/bin/answer.py?hl=en&answer=95617&p=ui_...

Ok - is there a workaround or something? This is a total disaster for me - I'm working on Pantheon and Acquia Dev Cloud and my local plus all my developers' locals, so now all these content references are spread out all over the place with absolute URLs, and it's 2 days before we launch. I'm in BIG trouble here.

Does anyone have any ideas for some kind of global patch or fix or some way of fixing all these absolute image URLs so I can launch my client's web site? Any help vastly appreciated.

Thank you,
Kelly

Have you tried using something like Pathologic which could be applied after the media filter runs.

No, but I guess we will. Thanks for the tip, Dave. If you think of anything else, please let me know?

Please tell me this will be solved in Drupal 8?

Thank you again,
-Kelly

I totally get that not using a complete url will break images and things showing up in emails. We had a very similar issue with the Forward module. However, I guess I'm confused as to why the full path of the image is getting stored in the database. If I add an image to the content with a stream wrapper, I would expect Drupal to dynamically propogate that with the $base_url on output, not store the wrong path in the database because it makes migrating that content impossible. I would imagine that it also breaks being able to use the sites.php alias for multi-sites. It should be output with // instead of http or https so that it doesn't break mixed mode.

We're using multi-sites as our default install because it makes it very easy to move stuff from dev to prod. We really like this module, but this issue basically puts us back to the D6 days of having to reserialize strings in the db or manually editing every node. Yuck to both scenarios.

We are checking out the Pathlogic module, thanks for the suggestion. Though really considering how popular media is, that maybe a more site-agnostic solution would be a good idea.

The items that are being stored in the database that we're talking about *is rendered output*. The text fields raw values reference the files by ID, not by URL. What we probably need to do is disable caching for the media filter which would disable any filter pre-caching for text fields that have an text format with the media filter, forcing it to be rendered not when a node is loaded, but rather only when a node is actually viewed. This has performance concerns, but the benefits might outweigh the problems here.

When it's processing those paths, would it be possible to make what is output configurable? Like let the site owner choose if absolute urls or relative ones are output? What would be really useful would be to handle the output by content type though I realize that's more complex.

Forcing it not to cache every time someone has a node with the media filter on it is going to make caching effectively useless. We have a high traffic site that was pushing 70MB of traffic a second to our DB server. When we turned on anonymous caching it went down to 7. We can't afford to have caching take that big of a hit.

Nothing like a catch-22 to make your day. :)

This is a duplicate of #1352182: Media assets should have relative paths for wysiwyg editors.