Skip to content Skip to sidebar

Home › Support › English Support › [Resolved] Warning: file_exists(): open_basedir restriction in effect.

[Resolved] Warning: file_exists(): open_basedir restriction in effect.

This thread is resolved. Here is a description of the problem and solution.

Problem:
If you're experiencing warnings on your website related to 'open_basedir restriction' after updating to WordPress 6.9 with WPML String Translation, it's due to the plugin sometimes requesting the folder of a translation file and receiving an empty path from WordPress. This results in PHP checking the filename in the current working directory, which is outside the allowed 'open_basedir' paths, thus triggering the warning.

Solution:
We recommend two temporary workarounds:
1. Modify the code in 

wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LoadTranslationFile.php

. After the line:

$defaultPathDirectory = $wp_textdomain_registry->get( $domain, $locale );

Add:

/** temporary safeguard */<br />if ( ! is_string( $defaultPathDirectory ) || '' === trim( $defaultPathDirectory ) ) {<br />    return null;<br />}

This prevents the 'open_basedir' warning by stopping the function if no real path is provided.

2. Hide the notice from your site visitors by modifying the 'wp-config.php' file as follows:

define( 'WP_DEBUG', true );<br />define( 'WP_DEBUG_LOG', true );<br />define( 'WP_DEBUG_DISPLAY', false );<br />@ini_set( 'display_errors', 0 );

This configuration logs the warnings without displaying them on the front end. For more details, visit Debugging WPML.

Please note that these are temporary solutions. Our developers are preparing an official fix to be included in a future WPML release.

If this solution does not resolve your issue or seems irrelevant due to different configurations or outdated information, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If the problem persists, please open a new support ticket.

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: 

This topic contains 9 replies, has 0 voices.

Last updated by Otto 3 weeks, 5 days ago.

Assisted by: Otto.

Author Posts
December 3, 2025 at 4:56 pm #17631806

josG-3

Good afternoon,

I had all the WPML updates actualized before I upgraded to WP6.9 as per your advice.
However, I now get the following warning at the bottom of every page I load:

Warning: file_exists(): open_basedir restriction in effect. File(action-scheduler-nl_NL.mo) is not within the allowed path(s): (/home/u125144p121218/:/tmp:/var/tmp:/opt/alt/php83/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php83/lib/php/) in /home/u125144p121218/domains/wingsforanimals.org/public_html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LoadTranslationFile.php on line 82

Warning: file_exists(): open_basedir restriction in effect. File(action-scheduler-nl_NL.l10n.php) is not within the allowed path(s): (/home/u125144p121218/:/tmp:/var/tmp:/opt/alt/php83/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php83/lib/php/) in /home/u125144p121218/domains/wingsforanimals.org/public_html/wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LoadTranslationFile.php on line 85

Please note that I have a staging website at staging.wingsforanimals.org that still is at WP6.8.3, but also with all WPML modules up-to-date, and this website does not show this error.
I have also emptied the WPML and Lite speed caches.
December 3, 2025 at 5:44 pm #17631946

josG-3

Scan is now completed but the warnings still present
December 3, 2025 at 6:23 pm #17632005

Otto
WPML Supporter since 09/2015

Languages: English (English ) Spanish (Español )

Timezone: America/Argentina/Buenos_Aires (GMT-03:00)

Hello,

Thanks for all the testing you've done so far.

We need to discard different server configurations.

Can you please check with the hosting provider whether both environments share the same open_basedir configuration or not? Ask them for the current open_basedir value on the live domain and the staging subdomain.

The warning shows that only these paths are allowed on production:
/home/u125144p121218/:/tmp:/var/tmp:/opt/alt/php83/usr/share/pear/:/dev/urandom:/usr/local/lib/php/:/usr/local/php83/lib/php/ (from the error message).

Check that the full WordPress path (/home/u125144p121218/domains/wingsforanimals.org/public_html/) and the standard language directories (wp-content/languages/, wp-content/languages/plugins/, and plugin directories) are all under one of the allowed base paths.

Ask the host to adjust open_basedir for the live domain, using one of these options (depending on their policy):

Preferred: ensure that the allowed path includes at least the whole account root (/home/u125144p121218/) and the PHP temp directory (/tmp) and any other internal temp paths used by PHP and OPCache.

Alternative: disable open_basedir for this vhost (set to none) if they consider the environment secure enough; this is what several WPML threads end up recommending when translation files and WordPress’s new translation subsystem must freely access temp and language directories.

After the host adjusts open_basedir, clear caches (again):
WPML → Support → Troubleshooting → Clear the cache in WPML (already done before, but should be repeated after a config change).
Flush any server-side cache (LiteSpeed, OPCache) if available.

Finally, reload a frontend and backend page with WP_DEBUG enabled and confirm whether the open_basedir warnings are gone.

Let me know how this goes, please.

Best Regards,
Otto
December 3, 2025 at 10:52 pm #17632334

josG-3

Hello Otto,

Just a quick question, because its getting late here and I want to continue tomorrow.

At first glance all the correct basedir paths are there. But I suspect the files action-scheduler-nl_NL.mo and action-scheduler-nl_NL.l10n.php are missing.
Where should I look for them?

Thanks
December 4, 2025 at 11:32 am #17633769

josG-3

Good morning Otto,

In addition to my reply of yester day evening I searched to server and could not find the files mentioned above.

In response to your questions:

- I checked with a phpinfo() command in the public_html directory of the main domain and the open_basedir was exactly the same as in the warning.
- All websites operate under the same directory /home/u125144p121218/
- the full WP path (/home/u125144p121218/domains/wingsforanimals.org/public_html/) is also under that directory as are the wp-content/languages/, wp-content/languages/plugins/, and plugin directories.
- staging.wingsforanimals.org is in a directory under /home/u125144p121218/domains/wingsforanimals.org/public_html/ and it does not produce the php error. But remember!!! this site still operates WP 6.8.3 while at the same time it uses exactly the same version of WPML as the main site. All updated.
- I updated WPML to version 4.8.6 before updating to WP 6.9

So, the main difference between staging.wingsforanimals.org and wingsforanimals.org is that the latter uses WP6.9 which point to a problem there in conjunction with WPML
Also, the files that are supposed to be blocked because they are not in the open_basedir list (action-scheduler-nl_NL.mo and action-scheduler-nl_NL.l10n.php) are not to be found in the directories upt to the / directory. I don't know what the significance of this is, but it might be a cause for all this trouble?

Best regards,

Jos
December 4, 2025 at 1:29 pm #17634500

Otto
WPML Supporter since 09/2015

Languages: English (English ) Spanish (Español )

Timezone: America/Argentina/Buenos_Aires (GMT-03:00)

Hello Jos,

Thanks for checking this and the extra information.

Root cause of the problem

On servers with `open_basedir` (like yours), WPML String Translation sometimes asks WordPress for the folder of a translation file.
In some cases WordPress returns an empty path, so WPML ends up checking just the filename, e.g.: "action-scheduler-nl_NL.mo" with no directory. PHP then looks in the current working directory, which is **outside** the allowed `open_basedir` paths, so it throws the warning.
It’s only a warning, not a fatal error, and it doesn’t break translations.

There are two workarounds meanwhile

Workaround 1 – Small code change

❌ Please make a full website backup before proceeding ❌

In `wp-content/plugins/wpml-string-translation/classes/MO/Hooks/LoadTranslationFile.php`, inside the function that calls:

$defaultPathDirectory = $wp_textdomain_registry->get( $domain, $locale );

add this check immediately after:

$defaultPathDirectory = $wp_textdomain_registry->get( $domain, $locale );

/** temporary safeguard */
if ( ! is_string( $defaultPathDirectory ) || '' === trim( $defaultPathDirectory ) ) {
    return null;
}

This simply says:
“If WordPress doesn’t give us a real path, stop here and don’t call `file_exists()`.”

That prevents the `open_basedir` warning.

Note: this change is safe, but it can be overwritten on a future String Translation update (once the official fix is included, it won’t be needed anymore).

Workaround 2 – Hide the notice from visitors

❌ Please make a full website backup before proceeding ❌

If you prefer to leave the code untouched for now, you can at least keep the warning out of the front-end and only in the log editing the wp-config.php file this way:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Here you have a deeper explanation:
https://wpml.org/documentation/support/debugging-wpml/

This way:
* The warning is still logged (useful for us),
* But your visitors won’t see it on the site.

Our developers are aware of this `open_basedir + WordPress 6.9 + String Translation` issue and have already prepared a proper fix.

It will be included in a future WPML release, so this manual workaround should only be temporary.

Let me know if this helps, please.

Best Regards,
Otto
December 4, 2025 at 1:40 pm #17634552

josG-3

Hello Otto,

Thanks for your reply.
In the meantime I have rolled back my core to 6.8.3 and the warning have disappeared! So I think it is safe to say that there is an issue with WP 6.9 and WPML.
I am thinking of testing your code change on a staging website with WP 6.9 installed, but what about updates to WPML. Can you confirm that this will become a permanent fix?

Thanks a lot,

Jos
December 4, 2025 at 2:05 pm #17634745

Otto
WPML Supporter since 09/2015

Languages: English (English ) Spanish (Español )

Timezone: America/Argentina/Buenos_Aires (GMT-03:00)

Hello Jos,

Thanks!

Yes, the issue is escalated to our devs and planned for WPML4.10. I can't promise it will make it, but it's in our backlog, and we aim for that. You'll need to re-apply the workaround until the fix is included.

In any case, I do suggest removing the PHP errors and warnings from the front end and log them into the debug.log file.

Let me know how it goes when you manage to test it in the staging environment.

Best Regards,
Otto
December 4, 2025 at 3:19 pm #17635136
josG-3

Hello Otto,

An update on this issue:

I installed a brand new staging site, copied from the main site which now runs WP 6.8.3 without issues.
I upgraded WP to 6.9 om the staging website (staging.wingsforanimals.org) and the issue re-appeared as expected.
I applied the PHP fix suggested by you above, and now the issue with the warning about open_basedir at the bottom of every page disappeared.

However... On all English language pages there is now a warning at the top of the page:

Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the feeds-for-youtube domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later. Please see Debugging in WordPress for more information. (This message was added in version 6.7.0.) in /home/u125144p121218/domains/staging.wingsforanimals.org/public_html/wp-includes/functions.php on line 6131

On the Dutch language pages there are no warnings. Dutch is the base language.

I'll stick to WP 6.8.3 for the production site for the moment!

Best regards,

Jos

New threads created by Otto and linked to this one are listed below:

https://wpml.org/forums/topic/notice-function-_load_textdomain_just_in_time-was-called-incorrectly-2/
December 4, 2025 at 3:49 pm #17635261

Otto
WPML Supporter since 09/2015

Languages: English (English ) Spanish (Español )

Timezone: America/Argentina/Buenos_Aires (GMT-03:00)

Hello Jos,

Thanks for confirming that the workaround works. I don't think the new issue is related to it. The permanent fix will be included in a next release.

Regarding the new problem, in our experience is better to handle one problem per ticket, so I created a new one for this new issue.

I'll follow up here:
https://wpml.org/forums/topic/notice-function-_load_textdomain_just_in_time-was-called-incorrectly-2/

Best Regards,
Otto