Help: why don’t images load in https?

For some reason, many or most of the images in this blog don’t load in some browsers. Same goes for the ProjectVRM blog as well. This is new, and I don’t know exactly why it’s happening.

So far, I gather it happens only when the URL is https and not http.

Okay, here’s an experiment. I’ll add an image here in the WordPress (4.4.2) composing window, and center it in the process, all in Visual mode. Here goes:


Now I’ll hit “Publish,” and see what we get.

When the URL starts with https, it fails to show in—

  • Firefox ((46.0.1)
  • Chrome (50.0.2661.102)
  • Brave (0.9.6)

But it does show in—

  • Opera (12.16)
  • Safari (9.1).

Now I’ll go back and edit the HTML for the image in Text mode, taking out class=”aligncenter size-full wp-image-10370 from between the img and src attributes, and bracket the whole image with the <center> and </center> tags. Here goes:


Hmm… The <center> tags don’t work, and I see why when I look at the HTML in Text mode: WordPress removes them. That’s new. Thus another old-school HTML tag gets sidelined. 🙁

Okay, I’ll try again to center it, this by time by taking out class=”aligncenter size-full wp-image-10370 in Text mode, and clicking on the centering icon in Visual mode. When I check back in Text mode, I see WordPress has put class=”aligncenter” between img and src. I suppose that attribute is understood by WordPress’ (or the theme’s) CSS while the old <center> tags are not. Am I wrong about that?

Now I’ll hit the update button, rendering this—


—and check back with the browsers.

Okay, it works with all of them now, whether the URL starts with https or http.

So the apparent culprit, at least by this experiment, is centering with anything other than class=”aligncenter”, which seems to require inserting a centered image Visual mode, editing out size-full wp-image-whatever (note: whatever is a number that’s different for every image I put in a post) in Text mode, and then going back and centering it in Visual mode, which puts class=”aligncenter” in place of what I edited out in text mode. Fun.

Here’s another interesting (and annoying) thing. When I’m editing in the composing window, the url is https. But when I “view post” after publishing or updating, I get the http version of the blog, where I can’t see what doesn’t load in the https version. But when anybody comes to the blog by way of an external link, such as a search engine or Twitter, they see the https version, where the graphics won’t load if I haven’t fixed them manually in the manner described above.

So https is clearly breaking old things, but I’m not sure if it’s https doing it, something in the way WordPress works, or something in the theme I’m using. (In WordPress it’s hard — at least for me — to know where WordPress ends and the theme begins.)

Dave Winer has written about how https breaks old sites, and here we can see it happening on a new one as well. WordPress, or at least the version provided for bloggers, may be buggy, or behind the times with the way it marks up images. But that’s a guess.

I sure hope there is some way to gang-edit all my posts going back to 2007. If not, I’ll just have to hope readers will know to take the s out of https and re-load the page. Which, of course, nearly all of them won’t.

It doesn’t help that all the browser makers now obscure the protocol, so you can’t see whether a site is http or https, unless you copy and paste it. They only show what comes after the // in the URL. This is a very unhelpful dumbing-down “feature.”

Brave is different. The location bar isn’t there unless you mouse over it. Then you see the whole URL, including the protocol to the left of the //. But if you don’t do that, you just see a little padlock (meaning https, I gather), then (with this post) “ | Doc Searls Weblog • Help: why don’t images load in https?” I can see why they do that, but it’s confusing.

By the way, I probably give the impression of being a highly technical guy. I’m not. The only code I know is Morse. The only HTML I know is vintage. I’m lost with <span> and <div> and wp-image-whatever, don’t hack CSS or PHP, and don’t understand why <em> is now preferable to <i> if you want to italicize something. (Fill me in if you like.)

So, technical folks, please tell us wtf is going on here (or give us your best guess), and point to simple and global ways of fixing it.



Some answer links, mostly from the comments below:

That last one, which is cited in two comments, says this:

Chris Cree who experienced the same problem discovered that the WP_SITEURL and WP_HOME constants in the wp-config.php file were configured to structure URLs with http instead of https. Cree suggests users check their settings to see which URL type is configured. If both the WordPress address and Site URLs don’t show https, it’s likely causing issues with responsive images in WordPress 4.4.

Two things here:

  1. I can’t see where in Settings the URL type is mentioned, much less configurable. But Settings has a load of categories and choices within categories, so I may be missing it.
  2. I wonder what will happen to old posts I edited to make images responsive. (Some background on that. “Responsive design,” an idea that seems to have started here in 2010, has since led to many permutations of complications in code that’s mostly hidden from people like me, who just want to write something on a blog or a Web page. We all seem to have forgotted that it was us for whom Tim Berners-Lee designed HTML in the first place.) My “responsive” hack went like this: a) I would place the image in Visual mode; b) go into Text mode; and c) carve out the stuff between img and src and add new attributes for width and height. Those would usually be something like width=”50%” and height=”image”. This was an orthodox thing to do in HTML 4.01, but not in HTML 5. Browsers seem tolerant of this approach, so far, at least for pages viewed with the the http protocol. I’ve checked old posts that have images marked up that way, and it’s not a problem. Yet. (Newer browser versions may not be so tolerant.) Nearly all images, however, fail to load in Firefox, Chrome and Brave when viewed through https.

So the main question remaining are:

  1. Is this something I can correct globally with a hack in my own blogs?
  2. If so, is the hack within the theme, the CSS, the PHP, or what?
  3. If not, is it something the übergeeks at Harvard blogs can fix?
  4. If it’s not something they can fix, is my only choice to go back and change every image from the blogs’ beginnings (or just live with the breakage)?
  5. If that’s required, what’s to keep some new change in HTML 5, or WordPress, or the next “best practice” from breaking everything that came before all over again?

Thanks again for all your help, folks. Much appreciated. (And please keep it coming. I’m sure I’m not alone with this problem.)

This entry was posted in Berkman, Blogging, Harvard, Internet, problems, publishing, security. Bookmark the permalink.

14 Responses to Help: why don’t images load in https?

  1. Alan says:

    Curious. The Chrome console complains about mixed http/https content. It blocks the first image “This request has been blocked; the content must be served over HTTPS.”. Subsequent images are also flagged as mixed content but not blocked: “This content should also be served over HTTPS”. Should? Why does it block the first but not the rest.

    I think WordPress may not be smart enough (or not configured) to use https for the images when the page is https.

    FYI Edge on Windows 10 shows the image.

  2. Hi Doc,

    I had the exact same issue and it dogged me for the past few months. I thought it was a desktop Firefox issue at first, then I discovered that Safari was also loading inconsistently on mobile. I spoke with my developer and found out that the issue is related to the css style sheet. Once I added the code (below) to my style sheet everything worked just fine. Hope this helps:

    .wf-loading body{
    visibility:visible !important;

    .wf-loading img,.wf-loading p, .wf-loading a, .wf-loading h1, .wf-loading h2, .wf-loading h3, .wf-loading h4, .wf-loading h5, .wf-loading h6 {
    visibility: visible !important;

  3. Jim says:

    Works fine with latest safari

  4. mikeb says:

    I believe the reason the first is blocked, and the second is not is the srcset=”…” attribute in the tag of the first. When I removed that attribute the image is displayed. Some quick google searching on https/srcset turned up these links. Looks like a common problem in recent versions of wordpress.

  5. Hi Doc,

    I read recently that WordPress Dev changed the image compression parameters to make WP faster and more responsive for mobile. I think they may have introduced a bug for image loading in the process.

    The code I provided earlier fixed the issue for me, if you can access your css editor I’m sure it will help you too. You should be able to add custom css in your Theme Editor. If you can’t find it, I’d suggest looking at the WordPress Codex for more info, or contact your hosting provider. They might even be able to do it for you, my hosting service prefers to add and modify code for me for security reasons.

  6. One more thing, if you have FTP access you could download your header css file and then add the code there and then replace it on my he server. (Or, ask a Millennial or GenXer to do it for you).

  7. Greg Falken says:

    I strongly recommend that you coordinate with someone who has knowledge of how *your* WordPress installation was set up. Several of the suggestions made here are unique to a particular install and are unlikely to work anywhere else. Do make sure that the URLs in General Settings for WordPress Address and Site Address begin with https://. In many cases, these values aren’t included in wp-config.php, so I wouldn’t go messing around in there. Good luck.

    • Doc Searls says:

      Thanks, Greg. In fact this post is meant to help the staff running the blogs at Harvard figure out and fix what’s going on. I expect they, or we, will figure out in the next few days what needs to be done, and do it.

  8. Ben Samuels says:

    Hi Doc,

    I ran into this I exact same issue over the last couple of weeks with the WordPress network I am setting up for Bishop Grosseteste University at which is hosted by WordPress Engine. I think that Harvard is also using the same host but upon a quick check I couldn’t find anything conclusive about this. In any case, my first fix was to try using a plugin that purported to mixed content errors (some part of the page being ssl and some not) which worked but caused other serious issues. Once I reported it to WordPress Engine, they sorted it for me quite easily and quickly by adding a line of code in the Netowork Admin Dashboard –> WP Engine tab –> General Settings –> HTML Post Proceesing:

    #http://sites\.bishopg\.ac\.uk# =>

    This solved it for us, maybe it will help point your support team In the right direction.

    Good luck!


  9. Ben Samuels says:

    Hi Doc,

    Strangely enough I ran across the exact same issue over the last couple of weeks with a WordPress network I am setting up for Bishop Grosseteste University at whic is hosted by WP Engine. It looks like your blog may be on the same host as it seems that Harvard is also using WP Engine but I am not certain about this.

    My first attempt to fix this involved trying a plugin specifically for resolving mixed content errors (some parts of the page being ssl and some not) but, though it did get the images to display, it was not compatible with some other plugins or something and broke a bunch of other stuff.

    Then I spoke to WP Engine and they sorted it for me right away by adding a bit of code in the Network Admin Dashboard –> WP Engine tab –> General Settings –> HTML Postprocessing:

    #http://sites\.bishopg\.ac\.uk# =>

    hope that helps if it isn’t already fixed!


  10. The srcset value is referencing a http:// version of the image on a HTTPS version of the page, causing it to fail to load.

    The fix will be to change the protocol from http:// -> //

    This will be platform agnostic.

    Example image code:

Leave a Reply

Your email address will not be published. Required fields are marked *