What matters first: A missing function can mean a plugin was deactivated, a required file did not load, code ran too early, a version removed the API or a conditional path was not met.
What this symptom actually tells you
The fatal message names the caller and function. The repair is not to define a dummy function; it is to restore the intended dependency or call it only when available.
Capture evidence before changing anything
- Record the missing function and first project file in the stack trace.
- Search the installed codebase for the function definition and provider.
- Confirm the provider plugin, theme or PHP extension is active and compatible.
- Check the hook priority or direct include that controls load order.
Most common causes
- Missing dependency: A required plugin, module or PHP extension is absent or inactive.
- Code runs too early: The function exists later in the WordPress lifecycle.
- Version mismatch: An update removed, renamed or namespaced the API.
- Incomplete deployment: The file containing the definition was not copied or extracted.
Safe diagnostic and repair sequence
- Restore the exact compatible dependency and verify its files before activation.
- Move custom calls onto the documented hook where the provider is available.
- Use function_exists only to handle a genuinely optional dependency and provide a clear fallback.
- Reproduce the triggering route, cron or API request because not every request loads the same components.
How to choose between the likely causes
Do not treat Missing dependency and Code runs too early as interchangeable. A required plugin, module or PHP extension is absent or inactive. By contrast, the function exists later in the WordPress lifecycle. Use two checks to separate them: Record the missing function and first project file in the stack trace; and search the installed codebase for the function definition and provider. Those observations usually show whether the next safe move is to restore the exact compatible dependency and verify its files before activation 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 paste an arbitrary function with the same name into functions.php. It can hide the dependency problem and create incompatible behaviour.
How to verify the repair
- The missing function resolves from the intended provider.
- The triggering request and background contexts complete without a fatal error.
- Plugin and deployment dependency requirements are documented.
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
How to narrow the fault without guessing
The fatal message names the caller and function. The repair is not to define a dummy function; it is to restore the intended dependency or call it only when available.
Record the missing function and first project file in the stack trace.
Search the installed codebase for the function definition and provider.
Confirm the provider plugin, theme or PHP extension is active and compatible.
Check the hook priority or direct include that controls load order.
What must be verified
- The missing function resolves from the intended provider.
- The triggering request and background contexts complete without a fatal error.
- Plugin and deployment dependency requirements are documented.
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 defining a dummy function with the same name a valid way to stop this fatal error?+
No. Pasting an arbitrary function with the matching name into functions.php can hide the real dependency problem and introduce incompatible behavior. The correct fix is restoring the intended dependency or only calling the function when it's actually available.
The function works on the front end but fails during a cron job — why?+
Not every WordPress request loads the same components, so a function that's available during a normal page load may not yet be loaded during a cron run, admin-ajax call, or REST request. Reproducing the exact triggering context is necessary rather than assuming the function is universally missing.
How do I know if this is a load-order issue rather than a genuinely missing plugin?+
Check whether the function is defined somewhere later in the WordPress lifecycle by searching the installed codebase for its provider. If the provider plugin is active and the function does exist, the problem is that your code executed before that function was registered, which points to hook timing rather than a missing dependency.
An update just ran — could that be why a function I've used for years suddenly stopped working?+
Yes. A version update can remove, rename, or namespace a previously available API, which produces exactly this fatal error. Comparing the current provider plugin's version and changelog against the function that went missing confirms whether this is the cause.