We updated (not added) SSL to the site

The media on the network admin media library works fine, but the media library for the sub-sites displays a grey box

for example: Image url looks like this: (when directly accessing this url, server 404 error, not WordPress 404 page)


breaking it down we have

https://domain.com/blog                            -> blog main url
/multisitedomain                                   -> virtual domain created by multisite
/wp-content/uploads/sites/2/2020/09/image-file.png -> relative path to image

true image path is (if you try and access the image here, it works)


this is the same as above, but missing the virtual domain

Files upload fine (into the non sub-domain folder) but the returned url is set to use the subdomain (if you remove subdomain they are there, but as given they are not)

They all have https paths, but the site is not properly locating the images when using the /subdomain pathing

I have compared the .htaccess to a different multisite that is on a different server, and compared it against the backup version, no changes to it, and they seem the same. It became broken only after the SSL updated

Is there something that needs to be done server side that we missed when updating the SSL? or could a server setting have been reset/changed during the process (I didn't do the update, so uncertain what steps were taken) that could have broken multisite, but not the "network admin" portion (or other non multisite WordPress sites on the same server)

I did create a temporary JavaScript fix to change the URL of images if not found on the front end, but as the media library is loaded via

  • No, the SSL certificate is all in your web server and should be independent of WordPress. Changing the SSL certificate should not affect anything in WordPress, no, nor need changes in the WordPress admin site. (Except maybe I suppose if it's making web requests to itself over HTTPS and no longer trusts its new certificate? But that doesn't sound like your problem here.) Can you compare the Apache / NGINX configuration before and after just to make sure whoever did the upgrade didn't break any of the WordPress-related config there too whilst they were there?
    – Rup
    Sep 22, 2020 at 12:03

1 Answer 1


The WP database for media items stores the full URL of the media file. If the media file was uploaded while the site was non-SSL, then a non-SSL URL is stored in the database.

When you upgrade to SSL, new media has the SSL address. So you need a way to go through the database and change all instances of http://www.example.com to https://www.example.com .

You can do this directly to the database, or use a search and replace plugin to do it for you. I use the Better Search and Replace plugin, which has always worked well for me. The plugin will do the necessary changes to the entire database, including the posts database where data (including the full media file URL) is stored.


Evidently, as evidenced by the first comment, my answer doesn't match the question. Not sure why that happened, but... [sigh]

I'd like to see the URL that is in the generated page. I'd also like to see the htaccess file to see if that is related to the issue. Although the question shows the URL that works, it doesn't detail the URL that is in the generated document. Or the URL that caused the 404.

I'd also be interested in the two URL in the wp-options table. And any wp-settings.php that are overriding those two wp-options URL.

You might try looking at the Network tab of the generated page (in the browser's developer tools) to see if you can determine the 'piece' of the generated page that is causing the 404. Perhaps that URL is not being built correctly.

More information, as mentioned above, would be helpful.

  • This has nothing to do with the original question. It is not ADDING SSL, it is updating SSL, the URL is correct with HTTPS and the problem is that the site is not showing images when the /subdomain/ is in use. If you had actually read the original post you would have seen that
    – Kender
    Sep 21, 2020 at 18:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.