Autoloader
in package
Autoloader class.
Tags
Table of Contents
- init() : bool
- Require the autoloader and return the result.
- register_woocommerce_psr4_fallback() : Closure|null
- Register the WooCommerce-scoped PSR-4 fallback as an appended (lowest-priority) SPL autoloader, so it is consulted only after every other autoloader — including the primary Jetpack autoloader — has missed.
- missing_autoloader() : mixed
- If the autoloader is missing, add an admin notice.
- __construct() : mixed
- Static-only class.
- log_fallback_declined() : void
- Log, under WP_DEBUG only, why the PSR-4 fallback declined to register.
Methods
init()
Require the autoloader and return the result.
public
static init() : bool
If the autoloader is not present, let's log the failure and display a nice admin notice.
Return values
bool —register_woocommerce_psr4_fallback()
Register the WooCommerce-scoped PSR-4 fallback as an appended (lowest-priority) SPL autoloader, so it is consulted only after every other autoloader — including the primary Jetpack autoloader — has missed.
public
static register_woocommerce_psr4_fallback() : Closure|null
The handler resolves each miss with a throwaway loader (see {@see})
rather than a single long-lived ClassLoader. Composer's ClassLoader records a
per-instance negative cache (missingClasses) on a PSR-4 miss and short-circuits
subsequent lookups for that class; a shared instance would therefore cache a miss for a
class probed before an in-place upgrade swaps the files, then keep refusing that same
class after the new file is on disk — for the remainder of the request. A fresh loader
per miss keeps every resolution honest while still reusing Composer's PSR-4 resolution.
Registration is idempotent: at most one handler is ever added per request.
Degrades to null (nothing registered) if the Composer files are unavailable or a
foreign/malformed ClassLoader shape is present. The handler likewise leaves a class
unresolved — rather than fataling — if a resolved file is torn/unparseable mid-upgrade,
so a defensive class_exists() probe during an upgrade gets false instead of an error.
The failed attempt stays retryable: the handler records only the files it has executed
cleanly, so once the upgrade finishes writing a file that previously failed to parse,
link, or run, a later probe in the same request re-attempts and loads it. It never
re-executes a path it already loaded (an uncatchable "Cannot redeclare class" fatal);
it cannot, however, guard the first execution of a file that declares a class already
loaded elsewhere under a non-matching PSR-4 path.
Tags
Return values
Closure|null — The registered autoloader, or null if no fallback was registered.missing_autoloader()
If the autoloader is missing, add an admin notice.
protected
static missing_autoloader() : mixed
Return values
mixed —__construct()
Static-only class.
private
__construct() : mixed
Return values
mixed —log_fallback_declined()
Log, under WP_DEBUG only, why the PSR-4 fallback declined to register.
private
static log_fallback_declined(string $reason) : void
When the fallback bails to "no fallback", the downstream "class not found" fatal an operator eventually sees during an in-place upgrade carries no breadcrumb back to this decision — yet that breadcrumb is the most useful signal in the system, since the fallback exists precisely to prevent that fatal. Mirrors the WP_DEBUG error_log the registered handler already emits for a caught autoload error.
Parameters
- $reason : string
-
Human-readable reason the fallback was not registered.