I thought I’d posted this already but can’t find it now, so this setting:
Access Settings > When user is not allowed to download > Hide Everything
really isn’t working for me.
If turned OFF I can see all files have “Access Denied” unless I’ve added user to the category, which is fine, working as intended.
But when I set it to Hide Everything, EVERYTHING disappears, including the files I’m supposed to be able to see. The archive file tree still shows most categories but nothing in them. The categories that the user is supposed to be able to view become hidden. So basically it’s hiding categories it’s supposed to be showing, and showing all other categories that it’s not supposed to, but they’re all empty (the opposite of how it’s supposed to work).
The way I have it set is only users specified for each category can view those files (no group or individual file access level settings specified, it’s category only). If I go directly to those file URL’s with hidden on, they do show properly, so maybe the hide everything feature just isn’t working correctly for the archive tree?
We’ve tried to apply updates on our installation website this morning and found the Download Manager plugin failed to update again. It was the same as last time where the downloaded “zip” file was HTML text with an “Invalid Access!” error. I’m sure it would have worked if I clicked update in the admin UI which did work last time, but as I’d mentioned our process is to apply all updates with “wp-cli” so this needs to work.
Our Developer comments:
I dug into things a bit and saw an error being logged:
PHP Notice: Undefined index: HTTP_HOST in <local path>/wp-content/plugins/download-manager/src/__/Updater.php on line 147
I had a look at line 147 of that file, and it’s as follows:
$domain = strtolower(str_replace(“www.”, “”, $_SERVER[‘HTTP_HOST’]));
The issue here is that “$_SERVER[‘HTTP_HOST’]” is not valid when called by wp-cli as this is not a web server. I backed up the file, edited the line and replaced “$_SERVER[‘HTTP_HOST’]” with “our-website.com”. After that “wp plugin update download-manager” worked and successfully updated the plugin to the latest version. That’s only a one-time fix though.
I’m sure when they see the problem, they’ll understand how to fix it. There are other ways they can get this URL, e.g. via WP’s “siteurl” option, etc. There’s already a base64 encoded string being added to the download URL which has “our-website.com” embedded in it, so that must have been worked out somehow without needing to look at the $_SERVER variable.
Please advise solution/fix, thanks