Frontend URL replacement fatals when Optimole SDK Image class is unavailable

[pirate-bot]

Summary

Optimole image URL replacement can terminate a frontend request with Class "Optimole\Sdk\Resource\Image" not found.

Expected behavior: Frontend image URLs are processed without a fatal error when Optimole's image replacement flow runs.

Actual behavior: The image replacement flow reaches the Optimole SDK image factory, which cannot load its Image class and aborts the request.

Impact: The affected frontend response can fail instead of rendering optimized content.

Customer context

• Product / area: Optimole WordPress plugin, frontend URL/image replacement
• Version: 4.2.11
• Environment: WordPress 7.1, PHP 8.4.7
• Integration / third party: Bundled codeinwp/optimole-sdk dependency; telemetry reports SDK version 3.3.58 separately
• Reported error / symptom: Uncaught Class "Optimole\Sdk\Resource\Image" not found from the SDK image factory
• Impact: 2 occurrences across 2 distinct production sites in the observed window

Reproduction notes

1. Activate Optimole 4.2.11 with frontend URL replacement enabled.
2. Process page output containing a supported image URL so Optml_Url_Replacer::normalize_image() calls the SDK image factory.
3. In the affected runtime state, the factory cannot load Optimole\Sdk\Resource\Image and the frontend request terminates.

Production reproduction is confirmed by 2 telemetry occurrences on 2 sites. A clean local reproduction and the affected release archive contents were not available.

Diagnosis

Conclusion

Production telemetry records an uncaught frontend exception at the Optimole SDK image factory after Optimole's URL replacer invokes Optimole::image(). The release dependency metadata locks codeinwp/optimole-sdk v1.2.4 and declares a PSR-4 mapping that is expected to load Optimole\Sdk\Resource\Image; the runtime class-not-found failure therefore indicates that the deployed dependency contents or autoload state does not satisfy the plugin's image-replacement contract. The exact packaging or installation mechanism is not established from the available repository.

Where this likely occurs

• inc/url_replacer.php — Optml_Url_Replacer::normalize_image() lines 270-274 invokes Optimole::image() for a frontend image URL and immediately uses the returned image object; this matches the in-plugin stack frames.
• inc/main.php — Optml_Main::instance() lines 95-100 conditionally includes vendor/autoload.php, the Composer entry point required for Optimole\Sdk classes.
• composer.lock — package metadata lines 10-45 locks codeinwp/optimole-sdk at v1.2.4 and maps Optimole\Sdk\ to src; lock source reference is 2f7a48525014bd681f39ddc85c55521b719d5879.
• bin/dist.sh — distribution build line 22 copies the assembled checkout while honoring .distignore; .distignore lines 1-52 does not exclude vendor.
• .github/workflows/deploy.yml — deployment workflow lines 16-29 runs composer install --no-dev before WordPress deployment and artifact generation. The reported release tag v4.2.11 contains the same locked Optimole SDK metadata.

Engineering notes

• The stack location is inside codeinwp/optimole-sdk, not the bundled ThemeIsle SDK. The shared ThemeIsle SDK clone contains no corresponding Optimole\Sdk\Resource\Image implementation, so this report is routed to the plugin release repository rather than Codeinwp/themeisle-sdk.
• The error occurs after the Optimole SDK class itself has loaded and when it tries to construct its image resource. This narrows the observed runtime failure to the Image resource being unavailable through the deployed SDK/autoloader state rather than the complete Composer autoloader being absent.
• Available source metadata identifies the SDK package and its intended namespace mapping, but the exact deployed vendor tree and release archive that generated these telemetry events were not available for inspection.
• No version boundary establishes that this behavior worked in an earlier release, so it is not classified as a regression.

Test coverage status

• tests/test-replacer.php exercises URL replacement flows, including image URLs, but no inspected assertion explicitly verifies that Optimole\Sdk\Resource\Image is loadable from the final distributable package.
• No relevant distribution-artifact integrity coverage was found during inspection.

What to verify or explore next

• May be worth verifying the v4.2.11 WordPress.org and direct-download artifacts contain vendor/codeinwp/optimole-sdk/src/Resource/Image.php and Composer autoload metadata for that package.
• If a local WordPress test environment is available, checking frontend replacement with the released artifact on PHP 8.4 may establish whether the crash reproduces outside the affected production installations.
• Comparing checksum manifests or archived package contents from the affected release may distinguish an artifact omission from a post-installation partial update or file-removal event.

Unknowns / follow-up

• The telemetry does not include the deployed file inventory, Composer autoload files, or plugin update history for either affected site.
• The supplied SDK version value is 3.3.58, whereas the Optimole SDK lock is v1.2.4; repository metadata indicates 3.3.58 belongs to the separate ThemeIsle SDK dependency, but the telemetry field's exact collection semantics are unavailable.

Confidence

Confidence: 87/100

The production trace records the same frontend fatal on two distinct sites running Optimole 4.2.11. The tagged release locks an Optimole SDK whose PSR-4 metadata is expected to resolve the missing class, while the image-replacement call path reaches that SDK factory directly. This supports a release/runtime dependency-loading defect, although the exact artifact or installation failure mechanism remains unverified.

Crash telemetry

Occurrences	2
Distinct sites	2
First seen	2026-08-27 16:47 UTC
Last seen	2026-08-28 01:23 UTC
Crash location	product:vendor/codeinwp/optimole-sdk/src/Optimole.php:126
Request context	frontend
Inside Themeisle SDK	no
Product versions	4.2.11
WP versions	7.1
PHP versions	8.4.7
SDK versions	3.3.58

---

Source: automated crash report — optimole-wp, fingerprint a3c8a206559d0e59709ffaa002952523
Generated by bug-report-triage (ID: bug-report-triage_6a9275be9a4316.39016069)