I had an issue with the website, after a domain migration, not allowing me to upload any type of files with the NextGen Gallery plugin on the page.
After failed resolution attempts, I went to Imagely support for help.

After an email exchange with Imagely, they diagnosed the problem attributed to the “open_basedir” directive that did not allow the use of temporary directories for Nextgen use. Probably due to a problem with access permissions to the temporary directory.

After detecting the problem, the necessary permissions were enabled on the temporary folder, but with no positive result.

The problem was on the WEB platform in which a “script” rewritten the .ini files that included this directive. Therefore, any attempt made to resolve the necessary permissions on these folders and fix the abnormal directory was ineffective as the script rewritten the data from the open_Basedir directive to the supposedly valid values.

The purpose of this review is to thank Barsha and the Imagely team for the attention received and of course to help users of this extraordinary plugin in case they have a similar problem.

thank you all

JMCasado

WARNING: file_exists(): open_basedir restriction in effect. File(/.donotbackup) is not within the allowed path(s): (/home/domain/:/tmp/:/var/tmp/:/opt/alt/php74/usr/share/pear/:/dev/urandom:/usr/local/php80/lib/:/usr/local/php74/lib/:/usr/local/php80/lib/:/usr/local/lib/php/)

What can we do about this?

Created temp folder in /wp-content/temp, did proper 755 chmod and chown to proper user. I then updated wp-config.php and added

define(‘WP_TEMP_DIR’,dirname(FILE). ‘/wp-content/temp/’);

Added it above Happy publishing. Restarted all required services and it still doesn’t work.

What is the proper syntax for open_basedir restriction? Right now I have in my php.ini that points to my www root in

open_basedir = “/var/www/html/exa.com”

Should it be?

open_basedir = “/var/www/html/exa.com:/tmp”

Or should the path be?

the full path /var/www/html/exa.com/wp-content/temp:/tmp

wp-content/plugins/wp-asset-clean-up-pro/vendor/matthiasmullie/path-converter/src/Converter.php

Im using PHP version 8.0 with wordpress ( latest version )
my php.ini configuration :
Open_basedir none

Even if I remove the open base dir restriction I have a conflict with the mainwp install plugin. I just have to disable the plugin in all my sites to be able to use mainwp.

It seems that the Query Monitor plugin is still trying to access the staging website path after the migration.

Is there anyone who is getting the same error? How can I update the allowed path correctly?

When editing any translation, a message appears: Error: Uploaded file is not readable.

Through debug.log we found out that your plugin is trying to create a temporary file, outside the site directory – which is restricted through open_basedir.

How to solve the problem? Disabling open_basedir helps, but it’s not the right solution.

Thanks a lot.

P.S. Versions Loco Translate: 2.6.4, WordPress: 6.2.2, PHP: 7.4.29 (fpm-fcgi), Server: nginx/1.20.2

It repeatedly finds this PHP error:

Message:
is_file(): open_basedir restriction in effect. File(/en.js) is not within the allowed path(s): (/var/www/vhosts/colinwalton.co.uk/:/tmp/)

Location:
wp-includes/class-wp-editor.php:516
is_file()
wp-includes/class-wp-editor.php:516
_WP_Editors::editor_settings()
wp-includes/class-wp-editor.php:308
_WP_Editors::editor()
wp-includes/general-template.php:3812
wp_editor()
wp-admin/edit-form-advanced.php:604

I have set the Plesk open_basedir to the default setting:
{WEBSPACEROOT}{/}{:}{TMP}{/}

This would appear to be correct but no success.

Another website on the same server using identical settings does NOT have the same error messages.

Any ideas where I am going wrong?

The problem occurs in 2 PHP functions in WpFastestCache.php (delete_cache_of_term and rm_folder_recursively) on saving Menu changes for sites hosted on Windows system.
The issue is caused by the question mark embedded in the directory path as in the following example…
D:\Home\ApacheRoot\dfprof\httpdocs\wp-content/cache/all/?taxonomy=nav_menu&term=direct-xxxx-main-menu/page
The use of is_dir or file_exists on these path names generates an invalid file/open_basedir error.
My (temporary) solution was to modify the code to test for ? in the path name and bypass this part of the code.
A better, robust and more permanent handling of invalid characters in a file name needs to added to this routines. (I am fairly sure that this will fail on Linux, but the error will occur silently in this case).