What matters first: The caller referenced a class name that no active autoloader or include could resolve. Common causes are incomplete Composer vendors, case-sensitive filenames, plugin load order and mismatched versions.
What this symptom actually tells you
Class names carry more context than a generic fatal: namespace, caller and path show which package or plugin should provide the code.
Capture evidence before changing anything
- Record the fully qualified class name and first project file in the trace.
- Search Composer and plugin files for the declaration and namespace.
- Check vendor/autoload.php and the plugin’s autoloader registration.
- Compare deployed files and letter case with a clean package.
Most common causes
- Missing vendor directory: A deployment omitted Composer dependencies or ran install in the wrong stage.
- Namespace mismatch: Code calls an old namespace after an update.
- Case sensitivity: A class works on Windows but fails on Linux because filename case differs.
- Load-order problem: The caller runs before the provider plugin or autoloader initializes.
Safe diagnostic and repair sequence
- Restore the complete package from a trusted build rather than copying one class file.
- Run Composer with the production lock file when the project owns the dependencies.
- Correct the namespace or hook timing based on the provider’s supported API.
- Clear opcode cache and restart PHP after replacing class maps or vendor files.
How to choose between the likely causes
Do not treat Missing vendor directory and Namespace mismatch as interchangeable. A deployment omitted Composer dependencies or ran install in the wrong stage. By contrast, code calls an old namespace after an update. Use two checks to separate them: Record the fully qualified class name and first project file in the trace; and search Composer and plugin files for the declaration and namespace. Those observations usually show whether the next safe move is to restore the complete package from a trusted build rather than copying one class file or to preserve the current state and widen the investigation.
On a production WordPress site, repeat the failing request while checking a known-good page and the admin area. A fault isolated to one route calls for a narrower rollback than a failure affecting PHP, the database or every request. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not run composer update directly on a live site during an outage. It changes dependency versions and makes rollback harder.
How to verify the repair
- The intended autoloader resolves the class consistently.
- CLI, web, cron and REST contexts that use the class all work.
- The deployed dependency tree matches the recorded lock or release artifact.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Class names carry more context than a generic fatal: namespace, caller and path show which package or plugin should provide the code.
- 1
Record the fully qualified class name and first project file in the trace.
- 2
Search Composer and plugin files for the declaration and namespace.
- 3
Check vendor/autoload.php and the plugin’s autoloader registration.
- 4
Compare deployed files and letter case with a clean package.
What must be verified
- The intended autoloader resolves the class consistently.
- CLI, web, cron and REST contexts that use the class all work.
- The deployed dependency tree matches the recorded lock or release artifact.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Is it safe to run composer update directly on the live site to fix this?+
No. Running composer update on a live site during an outage changes dependency versions and makes rollback harder. Restore the complete package from a trusted build, or run composer install against the production lock file, instead.
Why would a class that works on my local Windows setup fail only on the live Linux server?+
Filename case sensitivity differs between operating systems — a class can resolve correctly on Windows despite a case mismatch, but fail on Linux where the filesystem is case-sensitive. Comparing deployed filenames and letter case against a clean package identifies this specific cause.
Could copying just the missing class file into vendor manually fix this?+
That is not a reliable fix. It typically points to a deeper deployment problem — an incomplete Composer vendor directory or a namespace mismatch after an update — and copying a single file risks mismatched versions elsewhere in the dependency tree. Restoring the full package from a trusted build addresses the root cause instead.
After fixing the vendor files, why does the error sometimes persist?+
An opcode cache can keep serving the old class map after files are replaced. Clearing the opcode cache and restarting PHP after replacing vendor files or class maps is a necessary step, not an optional one.