Why is blogs.dir/1/files/ visible in file URLs?

On a hunch, I instead opted to change Upload Url Path (of the main site) to point to where Fileupload Url already was pointing, and lo and behold, now the uploads get url’s with a /files/ base (which I feel is best).

Funnily, despite this same setting on the testing site, the url’s there have the wp-content/uploads base (like I mentioned in the previous comment), as if Upload Url Path didn’t have an effect. There doesn’t seem to be a Fileupload Url setting there — perhaps it’s deprecated? (The testing site runs trunk, whereas the main site runs latest stable.)

(Usually it’s the other way round: something that works in testing won’t work on the production site.)

Funnily, despite this same setting on the testing site, the url’s there have the wp-content/uploads base

because it was a wordpress install which then had multsite turned on. ?? WordPress knows if it’s an upgraded mu install or not. That one was not.

Jani, your hunch was amazing ??

This actually fixed the issue on all of the secondary main sites (no idea how else to describe the main sites of secondary networks created with the Networks for WordPress plugin) but not in the main site of the main network… There it did indeed change the URL from using /wp-content/uploads/ to /files/ but from then on, images where not visible anymore, returning a 404.

This is actually fairly logical since the /files/ url forces the files to be handled by WP instead of being requested and served directly. WP then searches inside the /blogs.dir/1/files/ subdir while the uploaded files reside in /wp-content/uploads/ …

On another WPMS installation (without Networks for WordPress) that I had installed straight as a Multi-site, not as a regular install first and then activating multi-site capabilities, the main site was using /blogs.dir/1/files/ as upload path and displaying that in the urls too. Here, your hunch saved the day again!

Thanks for sharing ??

On another WPMS installation that I had installed straight as a Multi-site,

How on earth did you do this? put the multsite declaration in the config file right when you installed it?

becasue this:

a regular install first and then activating multi-site capabilities

is how you’re supposed to do it.

How on earth did you do this? put the multsite declaration in the config file right when you installed it?

As far as I remember, yes. This resulted in the main site using /blogs.dir/1/ instead of /wp-content/uploads/

But I actually see it as an advantage now with the fix from Jani Uusitalo, as now the main site also uses /files/ which looks better than /wp-content/uploads/ to me… but that’s a personal thing ??

Maybe this might be a little improvement for WP’s installation routine? A little check for right after network activation, something like: “when the main site uses Upload Path: wp-content/blogs.dir/1/files” (instead of wp-content/uploads then “set Fileupload Url: https://domain.ext/files”

Ehh….. nah, I think this is more because you were doing a non-standard install routine. They’d have to add too much logic in WP to check if someone was enabling multsite during the main install process, when you really should install first, enable multiste second.

Well, clearly I’m not the only one making this ‘mistake’ of going for multi-site from the start… and it seems to have no other downside than this visibility of blogs.dir in media urls. The fix sounds easy enough and allows for more flexibility in the installation process.

Anyway, my second issue remains: on the multi-site installation where I did follow the correct installation procedure, and where I am using the Multi-network plugin, all secondary networks need to have this fix (setting the Upload Url Path option) applied manually to replace the /wp-content/blogs.dir/X/files/ with /files/ in all media urls. I’ll open a new thread about it to not confuse the original issue further.

Thanks guys & galls, I’ve marked this as solved ??

Np, @ravanh, glad my contribution turned out helpful!