Shared publicly  - 
New blog post: Using SSL in WordPress admin ...
PixoPoint. Home; Products. Code Comments; PixoPoint Menu Plugin; Dropdown Menu CSS Generator; Theme Generator; Multi-level Navigation Plugin for WordPress; Simple CMS plugin for WordPress; Simple CMS ...
Daniel Baines's profile photoPauli Price's profile photoRyan Hellyer's profile photo
I didn't even realise this was possible until reading Mika's post last week. I don't think it had ever dawned on me that I could use a self-signed certificate without any real problems.
With a self signed certificate, if you're running admin under SSL, when you add an image to a post with "Insert into post", the <img src> will be an HTTPS URL because wp_get_attachment_url returns HTTPS when called in an SSL context.

The public then viewing the site over HTTP will encounter HTTPS image links. Since your self-signed SSL certificate isn't trusted they'll get broken images in most browsers.

The fix (only for images, I can't find anything that works for all media tags, unfortunately) is a get_image_tag filter:

function force_http_image_tag($html){
$html = str_replace( 'https://', 'http://', $html );
return $html;

You'll get mixed content warnings in IE while editing the post when the editor is in 'visual' mode, but I can live with that.

The alternative, if you needed to 'insert into post' media types other than images, would be to add a content filter to convert link source URI's before rendering the posts. (or remembering to manually edit the src attribute of any links in HTTP mode after inserting)
Thanks for the heads up +Pauli Price. A solution to that problem would be to use a filter on the_content() for the URLs to your uploads folder. That would ensure it worked no matter what the file type.
+Pauli Price That doesn't seem to be happening on my install. The images are outputting as http, not https.
Ah - I see the problem. I fixed wp_get_attachment_url because it was broken -- with this:

function fix_ssl_siteurl($url) {
if ( 0 === strpos($url, 'http') ) {
if ( is_ssl() )
$url = str_replace( 'http://', 'https://', $url );
$url = str_replace( 'https://', 'http://', $url );
return $url;
add_filter('option_siteurl' , 'fix_ssl_siteurl');
add_filter('option_home' , 'fix_ssl_siteurl');
add_filter('option_url' , 'fix_ssl_siteurl');
add_filter('option_wpurl' , 'fix_ssl_siteurl');
add_filter('option_stylesheet_url' , 'fix_ssl_siteurl');
add_filter('option_template_url' , 'fix_ssl_siteurl');
add_filter('wp_get_attachment_url' , 'fix_ssl_siteurl');

This fix was so that viewing the media library wouldn't generate 'mixed content' errors. However, that then lead to the 'insert into post' issue I described. It's kind of like I shot myself in the foot -- but I'm probably the only person in the company that doesn't use IE as their primary browser - so the 'mixed content' errors where a real problem for people. Especially as their default option was to opt not to render the insecure objects -- which then broke the admin panel based on some javascript and css .

As for the broader solution to inserting media other than images - I'd hook content_save_pre and content_edit_pre rather than the_content - it's a lower overhead solution, and one that lets me get rid of the mixed content errors even when editing in visual mode.
Good point on using a those other hooks instead of the_content(). That does make a lot more sense.

I'm confused as to how you needed to change all those other URL's though. Mine all worked just fine straight out of the box. I didn't need to change anything and it just seemed to work fine.
Are you using IE and not getting 'mixed content' warnings in admin? If so, I'm confused. 
I don't think I've ever visited the WordPress admin panel in IE. I thought your issue was with https being added to the image URLs instead of just http. I guess I misunderstood.

Would you get the same problem if you paid for a certificate? I don't really care if it spits out errors to IE users right now, although I would if I end up putting paying customers onto it (which would require me paying for an SSL certificate).
If you're using a commercial ssl certificate, I don't believe having the odd https served image in a post will be a problem. As long as the certificate correctly matches your domain.

I guess.

I'm not an expert in all things SSL - just the bits I've had the opportunity to bang my head against.

For our company's internal use, we're fine with a self-signed certificate. But, as I said, the rest of the staff use IE pretty exclusively. And if you use IE, you'll see that various assets are served http even when your site is set to force ssl in the admin, because you'll get an annoying popup warning on every page telling you so, and offering you the option (by default) to block insecure items.

Some of those items are served http because plugin authors are not following current recommendations for building URIs passed to wp_enqueue_script() or wp_enqueue_style(). Too many are still using constants now reserved to core, rather than the functions that return URIs correctly set as http or https. ( See: ) - these are the ones that will break your admin when the user opts to block insecure content, and jQuery libraries are blocked.

In addition, there's a bug, where attachments are always served http - see: - so anything on the post editor, like post thumbnails, or the media library, or certain plugins - that depend on wp_get_attachment_url - will generate 'mixed content' errors when viewed securely in IE.

My fix was (perhaps overkill) to ensure that anything that depended on those functions would behave correctly. That and fixing several plugins so they enqueued scripts and css properly took care of all the mixed content warnings. I thought I was done. Until I found the 'insert into post' issue.

Again - sorry for the false alarm. I hadn't realized I wouldn't have had the issue without having first worked around the wp_get_attachment_url bug.
Thanks for pointing all this out. It doesn't matter to me right now, but it will in future so it is good to know I need to deal with this sort of thing at some point.

To be honest I don't know what httpd is. I'd seen it elsewhere recently, but assumed it was a typo and was meant to say https ... off to Google it now.
I don't see that I typed httpd anywhere in this exchange.

BTW: httpd is your web server - the actual name of the apache binary program on some linux installations. Stands for http daemon.
Oh this is really weird, lol. I went to check what you wrote as it just didn't make sense. And httpd was nowhere to be seen, so I edited my post and scratched my head.

Then I scrolled up and hit "expand comment" and your httpd stuff returned, so I edited my comment, and then your httpd stuff disappeard. I think Google is having a little fit and punching content in out of nowhere. It's like it's somehow shunting content from one notification (I'm on the notifications box right now) into another notification. Very odd ....
And yeah, I thought httpd was a web server, but in the context of your post, it sounded like you were referring to it being a URL. It seems that another notification (about httpd) is being sporadically injected into your comments here.

Sheesh! That gets REALLY confusing when the stuff getting mixed up is sort of similar, but not quite, so they don't look out of place!

Anyhows, thanks for pointing out the limitations of self-signing certificates so I know to be wary of it.
Add a comment...