staze

resolving

confirmed fixed. Thanks!

Can confirm this workaround fixes issue. for “safety” sake I added an “index.html” into blogs.dir/1/files.

Thanks for posting the workaround. Trying to think if this potentially has downsides…

Hi @wfmattr Any update on this?

Ahh… okay. will be curious to know how it is fixed. Not sure if just adding an “is_dir”, or even if($dir) to see if the string is null makes sense in this case.

Thanks much!

Understood, thanks @wfmattr.

And yes, certainly not wanting to give access, but I work in tech, and sometimes you need to get get eyes on the actual problem when you can’t reproduce internally. =)

So I assume the reality here is I converted a standalone install to multisite, so my “blog.1” just stayed using uploads, and the others converted over to using blog.X as I imported them into the multisite. tbh, I’m now curious how modern multisite handles this as if they all use uploads, that could lead to naming collisions (two sites uploading the same file in the same month).

I’m honestly not sure where WF is getting blog.1 as it doesn’t seem to be defined anywhere. I’m also not sure how it’s looping back out to think stuff in wp-admin is in wp-contents/uploads unless it’s part of wordpress handling non-existent URLs and WF isn’t checking for a redirect.

Glad to hear a fix is on the way. No rush on this. I can ignore the warnings for now. I’d rather not exclude directories from scanning since that would potentially hide actual threats.

Thanks again!

Okay, emailed that info.

I don’t believe I started with multisite way back in 3.5 days, but I definitely had this wordpress install back then and converted to multisite from that same install. I am on PHP 7.2.

If you all are able/willing, I can give you access to my install. Not sure how much it would help, but I’m willing if you are.

One thing of note, possibly, is I’m set up for mutiisite, and subdomain installs, but I don’t have the domain specified because all of the sites have full domains, rather than being subdomains. Also of interest is there are some WAF statements in my .htaccess, not sure if that’s for everyone, or might be from some older install. Looks like statement for litespeed (which my hosting provider uses).

Thanks!

@wfmattr,

1. UPLOAD isn’t defined in WP-Config.php.
2. blogs.dir does exist in wp-content, but /1/ doesn’t exist within that. Looking in All Sites, Edit (for “Upload Path” and “Upload Url Path”), my first site is site 2, and my primary site is set to use wp-content/uploads.
3. There’s no rewrite for blogs in my .htaccess.

Because it’s multisite, WF runs from Network dashboard, which might be issue?

Not sure what else to look at. Happy to look in DB if needed.

Hi @wfmattr,

Find is not turning up anything. This broke with the latest update. I’ve had WF installed for years at this point. =/

find . -type l -ls

results in nothing found when in my WP root, or in WP-Content.

I don’t have anything non-standard other than being Multisite. Where does diagnostics think my custom uploads folder is?

Uploads are in wp-content as expected. So it must be getting “lost” somewhere else. =/

Yup. It’s multisite.

@gothickgothickorguk you might do the same, and send in logs in case mine are inconclusive…

done. emailed both diagnostic (including forum username) and the scan log.

Thanks.

Correct. So if I have multiple sites within my multisite, one dedicated to say, artwork, and another dedicated to music, and both are called “Staze”, in the multisite list, both just show as “Staze”. If I change the site name, that’s reflected in the public site… so was thinking an “internal only” name so it was possible to (easily) tell the difference. =)

Thanks!

Gotcha! Thanks!

Not a problem @yannick. Just glad the fix was easy. Was expecting to have to rename some DB tables or change some config properties. =)

So that old DB table can be deleted?