WordPress failed to open stream: how to fix it

The full error typically looks like this: Warning: require(/home/user/public_html/wp-content/plugins/some-plugin/includes/class-something.php): failed to open stream: No such file or directory . PHP tried to read a file, could not, and told you why. The “failed to open stream” part is PHP’s generic message for any file access failure. The part after the colon tells you the specific reason.

This error is actually several different errors sharing the same wrapper message. “No such file or directory” means the file does not exist. “Permission denied” means the file exists but PHP cannot read it. “HTTP request failed” means PHP tried to fetch a remote URL and it did not work. Each reason has a different cause and fix.

Unlike errors that produce a white screen or a full crash, “failed to open stream” often appears as a PHP warning rather than a fatal error. The site may still load but with broken functionality, missing styles, or incomplete pages. When it appears with require or require_once (as opposed to include ), it becomes a fatal error and the site crashes entirely.

Understanding the error message#

The error message has four parts that tell you everything you need to know:

Warning: require(/home/user/public_html/wp-content/plugins/example/class-foo.php):
failed to open stream: No such file or directory
in /home/user/public_html/wp-content/plugins/example/main.php on line 15

1. Warning or Fatal error –  include  and  include_once  produce warnings (site keeps running).  require  and  require_once  produce fatal errors (site crashes).
2. The file PHP tried to open – the path in parentheses after  require  or  include .
3. The reason it failed – after “failed to open stream:”.
4. Where the call was made – the file and line number that tried to load the missing file. This is where the  require  or  include  statement lives, not the missing file itself.

The reason string tells you which category of fix you need.

Reason: No such file or directory#

The most common variant. The file PHP is trying to load does not exist at the specified path.

Cause 1: Incomplete plugin or theme installation

A plugin or theme was partially uploaded, or the installation was interrupted. Some files exist in the plugin directory but others are missing. When the plugin tries to require a file that was not uploaded, you get this error.

How to confirm

Check if the file mentioned in the error exists:

ls -la /path/to/the/missing/file.php

If it does not exist, but other files in the same plugin directory do, the installation is incomplete.

How to fix

Reinstall the plugin or theme completely. The cleanest approach:

# Deactivate and delete
wp plugin deactivate plugin-name
wp plugin delete plugin-name

# Reinstall
wp plugin install plugin-name --activate

If the plugin is a premium plugin that cannot be installed via WP-CLI, download a fresh copy from the vendor and upload it via SFTP, replacing the entire plugin directory.

Cause 2: File deleted manually or by another process

Someone deleted a file via SFTP, or a security plugin quarantined a file it identified as suspicious, or an automated cleanup process removed it.

How to confirm

Check if the plugin is otherwise intact – if most files exist but one specific file is missing, it was likely removed individually rather than being a failed installation.

How to fix

Same as above – reinstall the plugin. If a security plugin quarantined the file, check the quarantine log to understand why. The file may have been flagged as malware, in which case reinstalling the plugin from a trusted source (wordpress.org or the vendor’s site) gives you a clean copy. See My WordPress site was hacked: what to do right now if you suspect the file was legitimately flagged.

Cause 3: Wrong file path after migration

After migrating WordPress to a new server, the directory structure may be different. If a plugin stores absolute file paths in the database or in a configuration file, those paths point to the old server’s directory structure on the new server.

How to confirm

The error path contains a directory structure that does not match your current server. For example, the error says /home/olduser/public_html/... but your current user is different.

How to fix

Run a search-replace on the database to update the old paths to the new paths:

wp search-replace '/home/olduser/public_html' '/home/newuser/public_html' --all-tables

Also check for hardcoded paths in plugin configuration files (usually in wp-content/plugins/plugin-name/). For a complete migration walkthrough including path replacement, see How to migrate WordPress to another hosting provider.

Cause 4: Case sensitivity

Windows file systems are case-insensitive ( File.php and file.php are the same file). Linux file systems are case-sensitive (they are two different files). If a plugin was developed on Windows and references Class-Loader.php but the actual file is class-loader.php , it works on Windows but fails on Linux.

How to confirm

The file exists but with different capitalization than what the error message shows:

ls wp-content/plugins/plugin-name/includes/

Compare the actual filenames with the path in the error message.

How to fix

Rename the file to match what the code expects, or contact the plugin developer – this is a bug in the plugin. Most hosting runs Linux, so case sensitivity issues in a published plugin should be reported.

Reason: Permission denied#

The file exists but PHP does not have permission to read it.

How to confirm

The file is there but has restrictive permissions:

ls -la /path/to/the/file.php

If the owner is root or a different user than PHP runs as, or if the permissions are 600 or 000 , PHP cannot read it.

How to fix

Set the correct permissions. WordPress files should be 644 (owner read/write, group and others read):

chmod 644 /path/to/the/file.php

Ensure the file is owned by the correct user (the user that PHP-FPM runs as):

chown youruser:youruser /path/to/the/file.php

For a complete breakdown of WordPress file permissions, see Linux file permissions: chmod and chown explained.

On Hostney, each site’s PHP-FPM runs as the account user inside its own container. File ownership is set correctly during provisioning. If permissions drift (usually after manual file transfers), the platform corrects them automatically in the background.

open_basedir restriction

If the error says “Permission denied” but the file permissions look correct, check for an open_basedir restriction. This PHP setting limits which directories PHP can access:

wp eval "echo ini_get('open_basedir');"

If open_basedir is set, PHP can only access files within the listed directories. A plugin trying to read a file outside those directories gets “Permission denied” even if the file system permissions would allow it.

On Hostney, open_basedir can be toggled per site in PHP Manager. When enabled, it restricts PHP to the site’s document root. When disabled, PHP can access the full home directory. If a plugin needs to read files outside the document root (some cache or temp directory plugins do), you may need to adjust this setting.

Reason: HTTP request failed#

This variant appears when PHP tries to access a remote URL using file functions ( file_get_contents('https://...') , include('https://...') ):

Warning: file_get_contents(https://example.com/data.json): failed to open stream: HTTP request failed

How to confirm

The path in the error is a URL (starting with http:// or https:// ), not a local file path.

How to fix

If a plugin is using file_get_contents() for remote URLs: This is poor practice. WordPress provides wp_remote_get() for HTTP requests, which handles SSL, redirects, and timeouts correctly. The plugin should be updated. Check for plugin updates or contact the developer.

If allow_url_fopen is disabled: PHP can be configured to disallow remote URL access via file functions:

wp eval "echo ini_get('allow_url_fopen');"

If this returns 0 or empty, PHP cannot open remote URLs. Some hosting providers disable this for security. The fix is either to enable allow_url_fopen or to update the code to use cURL/ wp_remote_get() instead.

If the remote URL is unreachable: The external server may be down, the DNS may not resolve, or a firewall may be blocking the connection. See WordPress cURL error 28: connection timed out for diagnosing outbound connection failures.

Reason: Is a directory#

Less common but confusing when it appears:

Warning: include(/home/user/public_html/wp-content/plugins/): failed to open stream: Is a directory

This means the code tried to include or require a directory path instead of a file. Usually a misconfigured plugin constant or a path variable that is missing the filename portion.

How to fix

Check the plugin’s configuration. A path constant may be set to a directory instead of a file. This is almost always a plugin bug – check for updates or report it to the developer.

When the error appears intermittently#

If the “failed to open stream” error appears sometimes but not always, the cause is usually:

Network file system latency. If WordPress files are on a network-attached storage (NAS or NFS mount), brief network interruptions can make files temporarily inaccessible. This is rare on modern hosting but can happen on custom server setups.

Race condition during updates. If WordPress is updating a plugin while a visitor loads a page, the old files may be partially deleted before the new files are in place. The visitor’s request references a file that existed a moment ago but was removed during the update. This is transient and resolves after the update completes.

OPcache serving stale bytecode. PHP’s OPcache compiles PHP files to bytecode and caches the result. If a file is deleted but its bytecode is still cached, OPcache may try to load dependencies of the deleted file. Restart PHP-FPM or reset OPcache to clear stale entries:

wp eval "opcache_reset();"

Debugging when the cause is not obvious#

If the error message does not make the cause clear, enable full debugging:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

Check wp-content/debug.log for the full stack trace. The trace shows every function call that led to the failed require or include , which helps you identify which plugin or theme initiated the file access and what it expected to find.

For errors in WordPress core files ( wp-includes/ or wp-admin/ ), verify core file integrity:

wp core verify-checksums

If core files are corrupted or missing, reinstall them:

wp core download --force --skip-content

For a walkthrough of core file recovery, see WordPress white screen of death: how to fix it – corrupted core files are one of the common causes.

How Hostney handles file access#

Container isolation. Each site’s PHP runs in its own container with its own filesystem view. One site’s file permission issues cannot affect another site.

Automatic permission correction. If file permissions drift from the correct values (common after manual SFTP uploads or plugin-created files), the platform corrects them automatically. The standard WordPress permissions (755 for directories, 644 for files) are enforced without manual intervention.

Per-site PHP error logs. File access errors are logged to ~/.logs/{your-domain}-php.error.log , isolated from other sites. The error log includes the full path and reason, making it straightforward to identify missing or inaccessible files.

Summary#

“Failed to open stream” means PHP could not access a file or URL it needed. The reason after the colon tells you what happened: “No such file or directory” means reinstall the plugin or check for path changes after migration. “Permission denied” means fix file ownership and permissions or check open_basedir . “HTTP request failed” means an outbound connection failed or allow_url_fopen is disabled.

The error message always includes both the file PHP tried to access and the file that made the request. Start with the target file – check if it exists, if it has correct permissions, and if the path is valid for your server’s directory structure. For a complete reference of WordPress errors and their quick fixes, see How to fix the most common WordPress errors.