WordPress after migration: fix “open_basedir restriction in effect”

Recognize a path rejection after changing servers

After a migration, the site or a function displays “open_basedir restriction in effect.” The message names a requested file and the paths in which PHP is permitted to work. The file may be perfectly readable by the system yet remain outside that scope. Changing its permissions therefore does not necessarily fix the rejection.

The goal is access to the correct file in the new site’s context. The first approach corrects an old path left by the transfer in a setting or generated file. The second adjusts a legitimate domain permission when the resource really does need to reside elsewhere. Adding the old hosting account to the permitted paths without checking its source may conceal a faulty migration.

The checks require a private log, access to files or the hosting panel, and a copy for testing. On WordPress.com, users cannot edit php.ini; support must check the need and a platform-compatible solution. On a managed plan, access depends on the contract. In self-hosted multisite, the same PHP configuration may affect several subsites: check its scope before changing it. This guide does not replace the procedure for a missing temporary directory during an upload.

Read the requested file, allowed list, and caller separately

A warning often contains three different pieces of information: the path PHP is trying to read, the list of permitted paths, and the code file and line that triggered the request. Keep them together with the time. The last file mentioned is not automatically the one with incorrect permissions; it may simply call an old location.

Fictional example: code executes under /var/www/vhosts/exemple.test/ but still requests /home/anciencompte/public_html/ressource.php. The priority is to understand why the old path is being constructed. If it no longer exists and corresponds to no intended resource, broadening the restriction will not recover the missing file.

In Plesk, open Domains > the domain > Logs to find the entry. With another host, use the private PHP log provided for this site and its error period. If the log is empty, have the administrator confirm its destination instead of exposing errors publicly. When sharing, mask account names and secrets while retaining the useful structure of the paths.

1. Record the exact requested path without publishing private account names.
2. Separately copy the list of permitted paths displayed in the message.
3. Note the calling file, its line, and the component owning it.
4. Compare this information with the site’s current root in the panel.
5. Keep a single dated example to compare the result after the fix.

Preserve configuration before changing a path

Keep a private copy of the relevant file and the PHP setting’s current value. Prepare a data backup if the path is stored in a component. Restoring files does not replace recovering a setting stored in the database. Use a recent copy with outbound messages and sensitive integrations disabled to reproduce the case.

Keep panel or SFTP access independent of WordPress administration. An early-loaded file may prevent the dashboard from starting after a syntax error. Therefore prepare a way to restore the previous version immediately. Do not move wp-config.php into a public directory to bypass the error.

The reference case should demonstrate the affected function without starting an important operation. A simple page or settings view may suffice. Stop retries if the message comes from an already-started process: a visible error does not prove that no partial writes occurred. Record what changed during migration, including the account path, document root, and PHP engine used.

Check the domain’s PHP instead of a terminal’s PHP

In the hosting panel, identify the PHP version and handler associated with the domain. The site may use PHP-FPM with a configuration different from the PHP command available over SSH. A reading taken on another domain or an old copy does not necessarily describe the failing request.

With Plesk, open Domains > your domain > Dashboard > PHP, or PHP Settings in the other layout. Record open_basedir in the current settings and the PHP handler. If available in this authenticated screen, View the phpinfo() page lets you compare Local Value, Master Value, and the loaded file. This view contains private information: do not publish it or create a phpinfo file accessible to visitors.

A value displayed in a file does not prove that the domain loads it. If the message cites another list, have the PHP administrator check the context, including a directive imposed at service level. Keep the evidence before editing anything. Multiplying .user.ini files and panel settings would make the effective value harder to identify.

First correct an old path in the component’s settings

This first approach is appropriate when the requested path clearly belongs to the old hosting environment. Identify the calling component from the log and view its configuration screen on the copy. It may retain an export directory, local resource, or path calculated during installation. Use its migration or path-change procedure if it provides one.

Check that the expected resource actually exists in the new environment. Do not mechanically replace every occurrence of /home/ with a new prefix: different services may not have moved in the same way. A setting may also expect a private directory rather than the site’s public root. If the value comes from a configuration file, open its private copy in the file manager’s editor or your local editor and search for the exact path from the log. Examine only occurrences belonging to the identified component; avoid global replacement across the database or all files.

1. Keep the component’s initial setting and original path.
2. Choose the confirmed new location for this resource on the copy.
3. Save through the component’s documented screen or mechanism.
4. Repeat the reference case and check the path cited in the new log.
5. If the correction is unhelpful or targets the wrong resource, restore the initial setting before another comparison.

Have startup files regenerated by their owner

A component may generate a startup file containing an absolute path. Copying that file to the new server then preserves an obsolete reference. It may load before ordinary plugins, for example through PHP configuration or a platform mechanism. Deactivating a plugin from WordPress does not guarantee that this early loading has stopped. An inherited auto_prepend_file in PHP configuration can notably load a file before WordPress core. Record the directive and its origin without automatically deleting it.

Find the file’s owner and its official migration or integration-reinstallation procedure. Preserve the file and the configuration loading it before requesting regeneration. Do not randomly remove a startup line providing protection or a necessary function. The operation should produce a new path consistent with the current domain.

For personal code, the maintainer can correct only the incorrect definition in a controlled copy, with syntax checking and a restoration option. Do not edit a generated file if the next deployment will overwrite it. The expected result is a lasting reference to the correct location, not the message temporarily disappearing after deletion of a still-required file.

Confirm that an external path is actually necessary

If the requested path does belong to the new server, check its function and owner. A shared private resource may legitimately remain outside the public root. Conversely, access to another account or an old copy directory is not necessary merely because a script attempts it.

Choose between moving the resource into the intended scope and authorizing its exact location. Moving it must preserve the expected properties: a private file must not become downloadable from the web. Other applications using that resource may also depend on its path; do not move a shared directory without checking their usage.

Have the file’s real path and intended authorization scope confirmed. PHP resolves symbolic links: placing a link in an allowed directory does not automatically permit its external target. If no need is established, correct the component’s request. If the need is confirmed, prepare an adjustment limited to the domain and useful directory, preserving the initial state. The list authorizes a directory tree, not any name beginning with the same prefix. It does not replace account isolation and system permissions.

Compare a component after startup with optional assistance

On a copy that still starts, you can compare the suspect component without a new tool through Plugins, Installed Plugins. Deactivate only that component if the reference function remains meaningful, then restore it after recording the result. If the error occurs before WordPress or originates from a file imposed at startup, this comparison may be insufficient.

Troubleshooting, by Marius L. J., provides optional assistance for comparison within your session. The recorded version is 1.0.2, requiring at least WordPress 5.8 and PHP 7.1, tested up to WordPress 7.1.4. It does not create a separate database or modify the PHP restriction. Use a copy for write operations. These minimums do not recommend installing an old PHP branch. The mode itself may fail if its required file cannot be created in mu-plugins: do not broaden permissions or open_basedir merely to force this optional tool to work.

1. On the copy, open Plugins > Add New Plugin, search for Troubleshooting by Marius L. J., then choose Install Now and Activate if your permissions allow it.
2. Open Tools > Site Health > Troubleshooting, then Enable Troubleshooting Mode. The theme and ordinary plugins change for your session; this tool does not isolate the database.
3. From the Troubleshooting Mode menu in the admin bar, reactivate necessary components one at a time and observe the same reference case.
4. Keep the corresponding logs. MU plugins and some early-loading mechanisms remain active; their presence limits the conclusion.
5. Finish with Disable Troubleshooting Mode from this menu and check the copy’s normal operation.

Adjust Plesk’s allowed list for just the domain

This second approach is appropriate if the external directory is necessary and the account can change the domain’s PHP settings. In Plesk, open Domains > the domain > Dashboard > PHP, or PHP Settings. Keep the entire open_basedir value, including panel variables. Click its field to enter a custom value. If the setting is absent or locked, have the host apply the documented need; do not change every domain’s service plan.

In the open_basedir field, preserve necessary paths and add only the confirmed directory. The Linux example below shows the expected format, not an automatic replacement for your existing list. The variables are specific to Plesk; do not paste this line into Additional configuration directives, an INI file, or a console. Windows uses semicolons between directories and its own path syntax: have the value adapted instead of transposing this Linux line.

1. Verify the domain and privately copy its initial value.
2. Add only the necessary directory through the panel’s mechanism.
3. Apply with OK or this screen’s confirmation button.
4. Read the effective value and test the same case.
5. To undo the change, restore the exact initial value in this field and check that it is applied.

{WEBSPACEROOT}{/}{:}{TMP}{/}{:}/chemin/prive/autorise

Have the effective configuration adjusted in other environments

Without Plesk, the PHP administrator must identify the file or setting imposing the value on the domain: the plan’s panel, service configuration, or a compatible per-directory setting. Do not create several configuration files to see which appears to work. Preserve the initial definition and its scope before changing it.

A runtime change can tighten open_basedir, but it is not a general way to broaden a restriction already applied. Adding ini_set to the theme or a snippet is therefore not the right approach to authorize an old rejected directory. A value imposed by the service must be handled at that level by its administrator.

The adjustment must target the necessary directory and preserve the other paths required for the domain to work. Do not use an empty value or access to the entire root as permanent diagnosis. After application, have the effective value reread in the web context, then repeat the reference case. If it remains unchanged, check the handler and loaded file before another change.

A .user.ini file is recognized only in compatible CGI/FastCGI contexts, not universally. PHP searches for these files along the script’s path up to the document root; a nearby setting may therefore still intervene. Their rereading depends on user_ini.cache_ttl, whose default is 300 seconds. Have the effective delay checked before adding further changes. Directives imposed with php_admin_value cannot be overridden by ini_set; involve the administrator of that configuration.

Separate the PHP restriction from system permissions

Even after the path is authorized, the file must exist and be accessible to the PHP process. If a new message reports a missing file or denied permissions, treat it as another diagnostic step. An allowed directory does not create the resource or by itself grant system read or write permissions.

Do not set every directory to 777 to eliminate a path warning. Check the owner, required permissions, and file function. Overly broad permissions do not fix a target outside open_basedir; they merely add another change to the incident. Keep the initial permission settings if a targeted check is necessary.

If the correct file was fixed but the old path still appears, have a concurrent copy, another connection endpoint, or old code still loaded checked. Use the host’s intended invalidation mechanism when that cause is confirmed. Do not install a public PHP cache-reset page to explore a hypothesis.

Validate the path and result on a new request

Repeat the exact visit that produced the warning after applying the fix. Note the time and examine the corresponding log. The message should stop for the affected path, and the function should produce the expected result. Hiding warnings from public display does not repair denied access: the private log and behavior remain the useful checks.

If the component was supposed to read a resource, check its contents or expected effect. If it was supposed to write an export, check the private location and final file without sending real sensitive data just for the test. A success notification does not establish that the correct directory was used. Also check a neighboring function relying on paths retained in the allowed list.

Then confirm the result on the copy in normal operation if you used a troubleshooting mode. An isolated session does not represent every component starting on the site. Do not accept a fix that merely replaces the old warning with an inclusion or permission error. The procedure is validated when the path is consistent and the result complete.

Restore the initial setting and prepare the next migration

If the test must be undone, restore only the value or file changed through the method used. Then read the domain’s effective setting. Restoring PHP configuration does not automatically restore data a component may have written during the test; keep data recovery separate and limited to its scope.

Document private paths, the site root, startup-file owners, and how to regenerate those files after transfer. At the next migration, compare these references with the new architecture before reusing a generated file. Avoid retaining an old path merely to silence a warning after an incomplete move.

To obtain precise help, provide the redacted message, calling file, domain, PHP handler, and effective and initial restriction values. State which resource actually exists on the new server and which fix was attempted. This information distinguishes an obsolete path from a need for authorization without accumulating permission, cache, and configuration changes that would mask the cause.

Replace an old absolute path in personal code

If you maintain your own plugin and its ressources/regles.json file is located next to the calling PHP file, resolving the path from that file avoids retaining the old hosting account’s name. The following example belongs only in that personal code, replacing its equivalent read; it is not suitable for provider-generated configuration.

The path is fixed: it does not come from a visitor parameter. __DIR__ identifies the directory of the file containing this snippet, not necessarily the plugin root. Therefore place the resource according to this structure and adapt error handling to the component. The readability check does not broaden open_basedir or authorize an external target through a symbolic link. On a copy, check the resource read and then the private log; if the expected directory differs, restore the initial file and correct the architecture instead of opening the server’s entire root.

$chemin_regles = __DIR__ . '/ressources/regles.json';
if ( ! is_readable( $chemin_regles ) ) {
    throw new RuntimeException( 'Ressource de configuration illisible.' );
}
$regles_json = file_get_contents( $chemin_regles );
if ( false === $regles_json ) {
    throw new RuntimeException( 'Lecture de la ressource impossible.' );
}