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)
.png
breaking it down we have
-> 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)
.png
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
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)
https://domain.com/blog/multisitedomain/wp-content/uploads/sites/2/2020/09/image-file.png
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)
https://domain.com/blog/wp-content/uploads/sites/2/2020/09/image-file.png
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
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.
Added
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.