Best way to avoid mixed http/https content

[David Anderson]

Hi,

I'm aware that there are *lots* of ways to avoid mixed http/https
content warnings, but I'm looking for any insight into the best way of
doing this. The use case is for a site that is intended to be available
over both http and https.

In particular, I'm talking about content inside posts. (Not about the
admin area, or plugin resources (e.g. JavaScript, CSS)).

The WordPress editor always inserts full links for media. i.e. It
includes the uploads URL setting (which can of course be set in
different ways). This is good, because it means that you can move the
site from one place to another, and you just need to search/replace the
URLs. However, that doesn't work well if the site is meant to be
available via both http and https. It'll cause mixed content warnings.

So, you could manually edit the links to remove the protocol. i.e.
change your image links from
Loading Image... to
//example.com/wp-content/uploads. That's rather cumbersome, though - and
makes the search/replace (slightly) more complex when moving from live
to staging/dev, etc. If you change to relative links,
/wp-content/uploads, then that's also cumbersome, and makes any
search/replace very dangerous.

So, I think the best solution to this is probably a plugin that
dynamically filters the post output, depending on whether is_ssl() is true.

Does this seem right? If so, any suggested plugins?
http://wordpress.org/plugins/wordpress-https/ looks like the "big beast"
in the area, but to my mind a plugin author who can't be bothered to
update his readme.txt beyond " Compatible up to: 3.5.2" isn't committed,
so you're setting yourself up for future trouble by ignoring that red
flag. Presumably this simple use case could be done with just a quick
filter on the content and I should do that. Again, I'm wondering if
anyone has experience/advice on this.

Best wishes,
David

[Leho Kraav]

Post by David Anderson
Hi,
I'm aware that there are *lots* of ways to avoid mixed http/https
content warnings, but I'm looking for any insight into the best way of
doing this. The use case is for a site that is intended to be available
over both http and https.
*snip*

Been wondering about this for a while :) Thanks for taking the thoughts
out of my head and posting them word for word!

[Nicholas Ciske]

This just came up in a recent thread, I think, but I can't find it in the archive.

The gist was:

Either filter post content to switch http:// to https:// (or vice versa) or use protocol relative urls:
http://www.paulirish.com/2010/the-protocol-relative-url/

Ideally you'd switch to protocol relative URLs on save_post instead on display for maximum performance (i.e. then you're only filtering the content once).

_________________________
Nick Ciske
http://thoughtrefinery.com/
@nciske

Hi,
I'm aware that there are *lots* of ways to avoid mixed http/https content warnings, but I'm looking for any insight into the best way of doing this. The use case is for a site that is intended to be available over both http and https.
In particular, I'm talking about content inside posts. (Not about the admin area, or plugin resources (e.g. JavaScript, CSS)).
The WordPress editor always inserts full links for media. i.e. It includes the uploads URL setting (which can of course be set in different ways). This is good, because it means that you can move the site from one place to another, and you just need to search/replace the URLs. However, that doesn't work well if the site is meant to be available via both http and https. It'll cause mixed content warnings.

[Dave McHale]

There are two "best" methods for avoiding content mismatch errors.
Personally I would argue that you should enforce AlwaysOn SSL, but that is
another conversation entirely and not what you asked about :)

1) Always reference over https. When you're in https mode, you obviously
won't get content mismatch errors. When you're in http mode, you can safely
reference https content. This ensures safety no matter how a site visitor
asks for a page.

2) The beginning of your absolute path does not HAVE to include the
protocol. RFC's many many years ago implemented the standard where you can
safely remove the http: or https: and just start from the double-slashes.
When you do this, the site visitor's browser will load the resource over
whatever protocol it is currently in... HTTP requests will load all of
those referenced resources over HTTP, and HTTPS requests will do so over
HTTPS.

My guess is you will want/need a plugin to enforce one of these rules on
output, but hopefully this knowledge helps get you where you need to go!

Dave