Release package lacks Optimole SDK DprProperty class

[pirate-bot]

Summary

Optimole image replacement can terminate a frontend request with Class "Optimole\Sdk\Resource\ImageProperty\DprProperty" not found while generating a DPR image URL.

Expected behavior: image URLs that require a DPR value are generated without a fatal error.

Actual behavior: the request reaches image replacement and throws an uncaught class-not-found error.

Impact: affected frontend requests can fail instead of rendering optimized image content.

Customer context

• Product / area: Optimole WordPress plugin, frontend image URL replacement
• Version: 4.2.10 and 4.2.11
• Environment: WordPress 7.1; PHP 8.5.8 and 8.5.9
• Integration / third party: Bundled codeinwp/optimole-sdk dependency
• Reported error / symptom: DprProperty class not found from the SDK image resource
• Impact: 3 telemetry occurrences across 2 sites in the available query window

Reproduction notes

1. In a clean Optimole 4.2.10 or 4.2.11 installation, process frontend image content through Optml_Url_Replacer::build_url() with dpr greater than 1.
2. The inspected code reaches the failing SDK call at inc/url_replacer.php line 315.
3. Production telemetry confirms the observed class-not-found error on this path. A local runtime reproduction was unavailable because the workspace does not contain the packaged vendor/ directory or WordPress test environment.

Diagnosis

Conclusion

Production crash telemetry confirms an uncaught class-not-found failure in the frontend image-replacement path. The reported stack reaches Optml_Url_Replacer::build_url() and invokes the SDK DPR method. The plugin's pinned Optimole SDK source declares the referenced DprProperty class, while the runtime report shows it missing; this is strong evidence of a packaged dependency or Composer autoload integrity failure in the distributed plugin artifact.

Where this likely occurs

• inc/url_replacer.php — Optml_Url_Replacer::build_url() lines 254-266 derives dpr: 2 for eligible images, and lines 314-315 invokes $image->dpr() in the frontend request path.
• inc/main.php — Optml_Main::instance() lines 95-99 conditionally loads the plugin-local vendor/autoload.php that resolves SDK classes.
• composer.lock — package entry lines 10-45 locks codeinwp/optimole-sdk at v1.2.4 with PSR-4 namespace Optimole\Sdk\ mapped to src; the locked source reference was checked and contains Resource/ImageProperty/DprProperty.php.
• .github/workflows/deploy.yml — deploy job lines 16-29 runs composer install --no-dev before deployment and the distribution build.
• bin/dist.sh — distribution workflow lines 22 and 39-40 copies the installed workspace and creates the artifact. .distignore lines 1-52 does not exclude vendor/.
• The 4.2.10 to 4.2.11 dependency diff changes codeinwp/themeisle-sdk only; it retains codeinwp/optimole-sdk v1.2.4. The reported location is not inside Themeisle SDK code.

Engineering notes

The crash only occurs after a DPR value greater than one is present. The inspected code can derive that value for small images when Retina Images is disabled, or callers can provide it through the optml_image_args filter. Telemetry also establishes that the failure occurs during frontend output processing.

The source checkout has no vendor/ directory, so the exact distributed ZIP from either affected release was not inspected. The source package's class presence means the available evidence does not establish whether omission occurred during Composer installation, the archive step, or an altered installation after delivery. The two affected plugin versions and two distinct sites make an isolated single-site configuration issue less likely.

Test coverage status

tests/test-media.php — Test_Media::test_retina_images() lines 317-323 asserts generated /dpr:2/ URLs. tests/test-srcset.php — Test_Srcset_Functionality::test_change_url_for_size_dpr_addition() lines 40-49 and related DPR cases exercise string-level DPR URL handling. No relevant coverage was found during inspection for the SDK Image::dpr() class resolution or for contents of a built release ZIP. Tests were not run because this checkout lacks installed Composer dependencies and the WordPress test environment.

What to verify or explore next

• Inspect the vendor/codeinwp/optimole-sdk/src/Resource/ImageProperty/ contents and Composer autoload metadata in clean 4.2.10 and 4.2.11 release archives.
• Run the frontend image-replacement test path from a clean package installation with an image configuration that reaches dpr > 1.
• Compare the deployed artifact checksum or archive contents with the Composer v1.2.4 distribution referenced by composer.lock.
• Check whether the observed PHP 8.5 environments alter the Composer class-resolution path.

Unknowns / follow-up

• The telemetry report does not identify the exact image dimensions, Retina setting, or filters that supplied the DPR value.
• The affected production release archives and their generated Composer files were unavailable in the workspace.
• No earlier known-good runtime reproduction or version boundary was available; regression status is therefore unconfirmed.

Confidence

Confidence: 89/100

Production telemetry confirms three uncaught frontend failures on two sites, and the reachable DPR branch calls an SDK method whose required class is absent at runtime. The pinned source and release workflow expect that class to be present, indicating a release-artifact or autoload integrity defect in Optimole WP rather than the shared Themeisle SDK.

Crash telemetry

Occurrences	3
Distinct sites	2
First seen	2026-08-25 21:10 UTC
Last seen	2026-08-27 01:22 UTC
Crash location	product:vendor/codeinwp/optimole-sdk/src/Resource/Image.php:25
Request context	frontend
Inside Themeisle SDK	no
Product versions	4.2.10, 4.2.11
WP versions	7.1
PHP versions	8.5.8, 8.5.9
SDK versions	3.3.57, 3.3.58

---

Source: automated crash report — optimole-wp, fingerprint 911c5147c2c28682d528e9e63d930ba4
Generated by bug-report-triage (ID: bug-report-triage_6a8fd2c35ad3d4.64479435)