Frontend fatal when the Composer autoloader is unavailable

[pirate-bot]

Summary

The plugin can terminate a frontend request with Error: Class "TIOB\Main" not found when its Composer autoloader is unavailable.

Expected behavior: plugin startup handles an unavailable dependency loader without causing a fatal frontend error.

Actual behavior: startup reaches a missing class reference and the request fails.

Impact: affected sites return a fatal error on frontend requests instead of rendering normally.

Customer context

• Product / area: Templates Patterns Collection bootstrap
• Version: 1.4.4
• Environment: WordPress 7.0.4; PHP 8.3.33 and 8.4.24 in the recorded reports
• Reported error / symptom: Error: Class "TIOB\Main" not found during a frontend request
• Impact: 2 occurrences across 2 distinct production sites in the telemetry query window

Reproduction notes

1. Use Templates Patterns Collection 1.4.4 in an installation where the plugin's vendor/autoload.php is unavailable.
2. Trigger a frontend WordPress request so init runs.
3. The recorded and source-supported outcome is Error: Class "TIOB\Main" not found from ti_tpc_run().

Runtime reproduction was not performed on a customer site; the production stack trace and tagged source establish the reachable path.

Diagnosis

Conclusion

Production telemetry records an uncaught TIOB\Main class-not-found exception at the plugin bootstrap call. In the inspected 1.4.4 source, loading vendor/autoload.php is conditional, but ti_tpc_run() is registered and later calls TIOB\Main::instance() without verifying that the loader or class is available. This makes the reported failure directly reachable when the Composer autoloader is absent or cannot be loaded.

Where this likely occurs

• templates-patterns-collection.php — lines 62-65, plugin bootstrap conditionally requires vendor/autoload.php only when it is a file.
• templates-patterns-collection.php — ti_tpc_run() lines 66-84 registers on init and unconditionally invokes \TIOB\Main::instance() at line 84.
• composer.json — lines 14-20, Composer PSR-4 maps TIOB\ to includes/, so the inspected code relies on the Composer loader for TIOB\Main resolution.
• includes/Main.php — TIOB\Main at lines 8-15 and Main::instance() at lines 83-90 confirm the expected class is project code rather than Themeisle SDK code.
• Git blame attributes the conditional autoload block to 2336f8f7 (2021-05-13) and the unconditional Main::instance() call to a7c62129 (2020-10-02). The current 1.4.4 release tag effa745173b273b915876eea9c73a724a5fd321f contains this arrangement.

Engineering notes

The release workflow runs composer install --no-dev before WordPress.org deployment (.github/workflows/deploy.yml lines 17-23), so a normal release artifact is intended to contain the autoloader. The inspected production symptom therefore suggests a missing or unavailable dependency-loader path on the affected installations; telemetry alone does not establish how it became unavailable. The failure is in product bootstrap, not inside the bundled Themeisle SDK.

Test coverage status

phpunit.xml lines 1-17 configures PHPUnit through tests/bootstrap.php. The bootstrap loads the plugin (tests/bootstrap.php lines 27-34), and tests/rest-test.php and tests/digital-test.php reference Main::instance(). No relevant coverage was found during inspection for ti_tpc_run(), a frontend request without vendor/autoload.php, or unavailable-autoloader handling.

What to verify or explore next

• May be worth verifying a 1.4.4 package with vendor/autoload.php unavailable and then issuing a frontend request.
• May be worth checking the deployed package contents and installation/update logs for the affected telemetry cohort to distinguish an incomplete artifact from a missing-file condition after installation.
• If reproducible, running the existing PHPUnit suite and relevant frontend smoke coverage after exercising the bootstrap path would clarify compatibility with supported WordPress and PHP versions.

Unknowns / follow-up

• The telemetry report does not include filesystem state, plugin installation source, or package-integrity evidence.
• It is unknown whether the autoloader was absent, unreadable, or failed before the reported call on the affected sites.

Confidence

Confidence: 92/100

Telemetry records the exact uncaught class-not-found error at the unguarded bootstrap call in version 1.4.4, and source inspection confirms that the only autoloader registration is conditional while the later class reference is unconditional.

Crash telemetry

Occurrences	2
Distinct sites	2
First seen	2026-08-12 19:07 UTC
Last seen	2026-08-12 22:28 UTC
Crash location	product:templates-patterns-collection.php:84
Request context	frontend
Inside Themeisle SDK	no
Product versions	1.4.4
WP versions	7.0.4
PHP versions	8.3.33, 8.4.24
SDK versions	3.3.58

---

Source: automated crash report — templates-patterns-collection, fingerprint 5a41ac44d3b7e5d1a7138609343a9bb8
Generated by bug-report-triage (ID: bug-report-triage_6a7d5d85c4b897.08414330)