Hello @bobjgarrett,
Thanks for reaching out to us!
It appears that the issue is related to the server’s open_basedir setting, which is a security feature that restricts access to files outside specified directories. The message indicates that the required file is not within the allowed paths.
To resolve this, please either adjust the open_basedir settings in your cPanel, contact your hosting provider to disable open_basedir restrictions, or add the necessary paths to the allowed list.
Please try it and let me know!
Warmly,
Beatrice.
I understand what you are saying but the newly added files do not show this warning.
So the file
/wp-content/uploads/dlm_uploads/2024/08/XXXXX-129.pdf does show this error in the Dashboard but
wp-content/uploads/dlm_uploads/2024/12/xxxx-130.pdf does not
I doubt the access level controls for openbasedir go to this level
Hello @bobjgarrett,
It looks like the older files are being affected by the server’s open_basedir settings because of where they were saved. The new files are probably stored differently, which is why they don’t show the same warning.
I recommend contacting your hosting provider to find out why the older files in the /2024/08/ folder are restricted while the newer ones in /2024/12/ are not. They should be able to check the server settings and help fix it.
Warm regards,
Beatrice.
The full warning message is
Warning: file_exists(): open_basedir restriction in effect. File(/wp-content/uploads/dlm_uploads/2024/08/Dufour-News-129.pdf) is not within the allowed path(s): (/home:/home2:/home3:/usr/local/apache/htdocs:/tmp:/usr/local/php80/lib/php:/usr/local/lib/php:/usr/share:/etc/xml:/etc/pki:/usr/bin-safe:/dev/urandom:/dev/null:/proc/version) in /home/dufour/P4ML4XO9/htdocs/wp-content/plugins/download-monitor/src/FileManager.php on line 87
So the paths set by the server do not go down to that level of folder such that the different folders in the dlm_uploads folder would be different. Could there be some other explanation?
I have now added some debug instructions to your code and identified the following:
For the file which does not produce the error the $parsed_file_path[‘scheme’] includes “https” but for the file which gives the warning the https is missing (ignore the | which was my separators.
debug:|https|/wp-content/uploads/dlm_uploads/2024/12/Dufour-News-130.pdf|
debug:||/wp-content/uploads/dlm_uploads/2024/08/Dufour-News-129.pdf|
So why would the https be different and how to fix this?
Now having looked in the database I find that in postmeta table the meta_key values for the older downloads are shortened paths while the new ones include the full file reference inc. the https and domain name.
So why would this have changed, and how do I fix it?
Hello @bobjgarrett,
Apologies for the late reply!
The issue you’re experiencing seems to be related to calling file_exists() on a relative path, which can sometimes conflict with open_basedir() restrictions on certain servers.
A potential solution would be to change all the relative paths in your downloads to absolute ones. For example, instead of using /wp-content/uploads/dlm_uploads/2025/01/file.txt, you would use the full URL: https://your-site-domain.com/wp-content/uploads/dlm_uploads/2025/01/file.txt.
If you prefer not to handle this manually, we will be releasing a fix in the next update to address the issue.
Warm regards,
Beatrice.
Thanks for the response. It seems strange that it affects the Dashboard view but not users’ views. I will probably await the fix.
This topic will be marked as resolved as we have an open ticket on GitHub regarding this. Please keep in mind that the ‘resolved’ status is only for this support thread, not the issue on GitHub.
