How to Fix the Failed to Open Stream: No Such File or Directory Error in WordPress

“Failed to open stream: No such file or directory” means PHP could not open the file or path that a WordPress component requested. The message is a symptom, not one diagnosis. Copy the complete warning, identify the exact target path and the caller named after in, then check whether that target belongs to WordPress core, a plugin, a theme, or custom code.

Do not start by changing every permission, reinstalling WordPress, or disabling every plugin. The safest repair depends on the path shown in the error and whether the file is actually missing or merely inaccessible.

What the error means

PHP emits this message when an include, include_once, require, or require_once statement cannot open its target. PHP documents that require failure is an error, while include produces a warning; exact fatal-error wording depends on the PHP version. The PHP manual also recommends anchoring paths to the current file with __DIR__ and avoiding the error-suppression operator @. See the PHP require documentation.

<?php
// Fragile: resolved relative to the process working directory.
require 'includes/settings.php';

// More predictable: resolved relative to this source file.
require __DIR__ . '/includes/settings.php';

“No such file or directory” makes a missing or incorrectly resolved path likely, but you must also check whether the exact target can be read by the PHP process. Ownership, access controls, and hosting layouts vary.

Read the complete message before changing anything

Copy the entire warning or fatal error, including whether it says include, include_once, require, or require_once.
Record the complete target path inside the message.
Record the caller file and line number shown after in.
Note any fatal error that follows the warning.
Record the URL, admin action, cron task, or deployment that triggered it.

The failed target path is the key evidence. The final caller line only tells you which code attempted the open.

Classify the path

Path in the message	What it commonly indicates	First safe action
`wp-admin`, `wp-includes`, or a WordPress root file	Incomplete update or missing or damaged core file	Back up files and the database, compare with a fresh package, and follow the manual update process
`wp-content/plugins/…`	Plugin update, removal, incomplete installation, or stale reference	Use Recovery Mode when available, or temporarily deactivate the implicated plugin
`wp-content/themes/…` or a theme `functions.php`	Theme code references a missing file or the theme update is incomplete	Inspect the reference and switch temporarily to a default theme if possible
Another application or custom-code directory	Incorrect path construction, deployment omission, or host configuration	Correct the path relative to the source file and verify the deployed file
The target exists but still fails	Ownership, PHP-user access, mount, or host restriction	Ask the host to inspect the exact file, owner, PHP user, and access rules

Step-by-step repair

1. Check the exact target on the server

Use your host’s file manager, SFTP/FTP, or shell. Check spelling, capitalization, directory names, and the WordPress installation root. A path that looks correct in code may point outside the real installation directory.

# Run from the WordPress installation directory when shell access is available.
ls -l wp-content/plugins/example-plugin/includes/settings.php
find . -path '*settings.php' -print

If the file is absent, determine why it disappeared before restoring anything. Check the last plugin, theme, WordPress, or deployment change.

2. Compare the caller’s path construction

Open the caller file and inspect how it builds the path. Relative paths can resolve from an unexpected working directory. For code located beside the target, use __DIR__:

<?php
$settings = __DIR__ . '/includes/settings.php';
if (! is_readable($settings)) {
    error_log('Missing or unreadable file: ' . $settings);
    return;
}
require $settings;

This check helps custom code and plugin authors. Do not hide the warning with @require; suppression removes information needed to fix the path.

3. Isolate a plugin or theme

If the path is under a plugin or theme, isolate that component before replacing core files.

Recovery Mode: When WordPress detects some fatal errors during a normal page load, it can email an administrator a Recovery Mode link. Recovery Mode was introduced in WordPress 5.2. It provides a temporary admin session in which the failing plugin or theme can be paused while you inspect notices. It does not cover every failure, including some cron or background errors. Follow the WordPress Recovery Mode documentation.

If wp-admin is unavailable: WordPress documents renaming the plugins directory through FTP or a file manager to deactivate plugins. Rename it temporarily, load the site, then restore the directory name and reactivate plugins one at a time. Keep access to the file manager because reactivation can reproduce the error.

For a theme error, switch to a default theme through the dashboard when possible, or ask your host or WordPress administrator to change the active theme through file or database access. Preserve custom theme changes before replacing or updating files.

4. Restore missing core files carefully

If the target is a WordPress core file, back up both site files and the database first. Use a fresh WordPress package appropriate to the installed version where practical, then follow the official manual update process to replace core directories and root files.

Confirm the WordPress version and installation root.
Replace core files from a clean package rather than downloading a random individual file.
Preserve wp-content. It contains site-specific plugins, themes, uploads, and other content and must not be deleted during a core replacement.
If the version, root path, or host workflow is unclear, have the host or a WordPress administrator perform the repair.

5. If the file exists, investigate access

A present file can still be unusable by the PHP process. WordPress Site Health reports filesystem permission status for directories WordPress needs to write, but it cannot replace host-specific inspection of read access, ownership, mounts, or PHP configuration. Ask the host to verify:

the exact target path and parent directories;
the file owner and group;
the PHP-FPM or web-server user;
read and execute access on the file and every parent directory;
whether a deployment, container, chroot, or network mount hides the path from PHP.

Avoid blanket recursive chmod or chown commands when you do not know the hosting model.

6. Confirm the fix and close the diagnostic loop

Repeat the original page load or admin action.
Inspect the PHP and WordPress logs for the original path error.
If disabling a plugin fixed the page, reactivate plugins individually to identify the failing component.
Update, repair, replace, or contact the component maintainer based on the evidence.
Turn off temporary public error display after diagnosis. Error output can expose filesystem paths and other sensitive details.

Recovery choices by evidence

Evidence	Likely next step	Caution
Plugin path, especially immediately after an update or removal	Review the plugin’s files and recent change; isolate with Recovery Mode or temporary deactivation	Reactivation can reproduce the failure; keep file-manager access
Theme path or `functions.php`	Inspect the reference; temporarily use a default theme	Theme updates can overwrite custom changes; back up first
Core directory or root path	Compare with a clean package and restore core files	Back up files and database; do not delete `wp-content`
Target exists but cannot be read	Have the host inspect owner, PHP user, and access	Do not apply guessed global permissions
Custom-code path	Anchor the path to the source file and deploy the missing file	Do not suppress the diagnostic instead of fixing it

Common errors and fixes

“Failed opening required …” followed by a fatal error

Cause: The code used require or require_once, and PHP could not open the target. Fix: Verify the exact target path, restore the missing component or correct the path, then repeat the request. Do not describe every instance as a corrupt WordPress installation.

The message appears after a plugin update

Cause: An incomplete update, changed file layout, or stale reference is possible. Fix: Isolate the plugin, inspect its installed files, reinstall or update it from a trusted source when appropriate, and contact its maintainer if the package is incomplete.

The plugin was deleted but the error remains

Cause: Another component may still reference the deleted path, or an autoload/cache entry may be loading old code. Fix: Search the remaining code for the path, clear the relevant application cache, and inspect deployment or must-use plugins.

The file is visible in FTP but PHP says it is missing

Cause: FTP and PHP may use different roots, containers, users, or mounts; capitalization can also differ on case-sensitive systems. Fix: Confirm the path from the PHP runtime and ask the host to compare the PHP process view with the FTP view.

Changing permissions did not help

Cause: The path may be wrong, the file may be absent, or the PHP process may be restricted by ownership or hosting policy. Fix: Return to the complete path and caller, then have the host inspect the exact access chain.

The dashboard is inaccessible

Cause: A require failure can stop the request before WordPress renders admin pages. Fix: Use the Recovery Mode email if available; otherwise use the host’s file manager or FTP to isolate plugins or switch themes temporarily.

The error happens only on cron or background work

Cause: Recovery Mode is designed for some regular page-load failures and does not cover every background error. Fix: Inspect scheduled-task logs and the component named in the path, then isolate it through file access or host tooling.

Performance, reliability, and cost considerations

Performance: Repeated missing-file warnings can add log I/O and failed requests, but the primary concern is correctness. Fix the path or component rather than adding retries around a deterministic missing file.
Reliability: Back up files and the database before core or theme replacement. Prefer reversible isolation first, then make the smallest repair supported by the evidence.
Deployments: Keep dependency files and generated assets in the deployment artifact, and verify the working directory and case-sensitive paths in staging.
Cost: The repair itself usually requires access to your existing host, file manager, SFTP/FTP, or administrator. Host support or a developer may charge separately; do not assume a paid WordPress migration or reinstall is necessary.

Or skip the browser setup

If you need a screenshot of the repaired page for a ticket, regression record, or deployment check, ScreenshotNeo can capture it with one request. Its API accepts a URL and returns PNG, JPEG, WebP, or PDF. Before capture it accepts cookie or consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and the response reports the verdict and billing status in X-Page-Verdict and X-Billed headers.

See the ScreenshotNeo API documentation for all options, including full-page and element capture, waits, custom CSS and JavaScript, headers and cookies, device presets, PDFs, caching, signed links, async jobs, webhooks, and bulk capture.

cURL

curl -G "https://api.screenshotneo.com/v1/shot" \
  -d access_key=YOUR_API_KEY \
  --data-urlencode url=https://stripe.com \
  -o shot.webp

Python

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
r.raise_for_status()
open("shot.webp", "wb").write(r.content)

Node.js

const q = new URLSearchParams({
  access_key: 'YOUR_API_KEY',
  url: 'https://stripe.com'
});
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`Screenshot failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
require('node:fs').writeFileSync('shot.webp', image);

ScreenshotNeo also provides an MCP server with take_screenshot, get_page_info, and capture_pdf tools for Claude, Cursor, and other MCP clients. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Does this error always mean WordPress core is corrupted?

No. The path may belong to a plugin, theme, custom code, or a file that exists but is inaccessible. Classify the target before restoring core.

Should I reinstall all plugins?

No. Isolate the component named by the path, inspect its files and recent changes, and reinstall only when the evidence points to an incomplete or damaged package.

Can I fix it by adding a leading slash?

Only if the intended path is genuinely absolute and you know the server layout. For code relative to its source file, __DIR__ is usually clearer and more stable.

Why does the site work in one environment but fail in another?

Different document roots, case sensitivity, deployment artifacts, PHP users, containers, or mounts can change how the same path resolves. Compare the runtime paths in both environments.

Where can I find the official WordPress guidance?

Use WordPress’s troubleshooting FAQ, Recovery Mode documentation, updating instructions, and Site Health screen documentation.