Optimized-image polling calls the SDK before initialization

Start with Optml_Rest::poll_optimized_images() in inc/rest.php and trace its calls into inc/media_offload.php, inc/config.php, and inc/app_replacer.php. Review tests/test-poll-optimized-images.php, especially the nonempty polling setup, then verify the case where the response is nonempty but CDN settings and SDK initialization are absent. Done means the authenticated polling request completes with image results instead of an initialization exception, with coverage for that state.

Summary

When optimized-image polling receives a nonempty image list while the Optimole image SDK is uninitialized, URL generation throws an uncaught runtime exception instead of completing the REST response. This leaves the polling request failed and prevents the dashboard from receiving its image results.

Customer context

• Product / area: Optimole WordPress plugin, optimized-image REST polling
• Version: 4.2.13 and 4.2.14
• Environment: Reported across WordPress 6.9.9–7.1.2 and PHP 8.2–8.5
• Integration / third party: Optimole image SDK; Themeisle SDK versions 3.3.61 and 3.3.62 were also present
• Reported error / symptom: Please initialize the Optimole SDK first. during REST polling
• Impact: The affected polling request terminates before returning image results.

Reproduction notes

Telemetry reports the exception during a REST polling request in versions 4.2.13 and 4.2.14. A source-indicated reproduction condition is a nonempty optimized-image API response when the site is not connected and the image SDK has therefore not been initialized; this condition was not runtime-reproduced. Existing tests cover nonempty results only with CDN connection settings present.

Diagnosis

Conclusion

The product's REST polling callback can reach URL generation without ensuring the image SDK was initialized. Initialization of the media-offload singleton is conditional on the site's connected state, while the polling callback proceeds for a nonempty API response. This is a reachable product-side precondition gap consistent with the reported exception. The exact settings and SDK state on the affected requests were not captured.

Where this likely occurs

• inc/rest.php — Optml_Rest::poll_optimized_images(), lines 708–733, calls the API and sends every returned image through Optml_Media_Offload::instance()->get_media_optimized_url() when the list is nonempty.
• inc/media_offload.php — Optml_Media_Offload::instance(), lines 154–162, invokes its initialization path only when Optml_Settings::is_connected() is true.
• inc/settings.php — Optml_Settings::is_connected(), lines 189–198, requires both CDN key and secret.
• inc/app_replacer.php — Optml_App_Replacer::get_optimized_image_url(), lines 664–681, calls Optimole::image() for URL generation.
• inc/config.php — Optml_Config::init(), lines 95–149, initializes the image SDK during the normal connected setup.
• inc/api.php — Optml_Api::get_optimized_images(), lines 344–355, accepts an API key for the request independently of the connection check above. The telemetry shows that the callback reached image URL generation with a nonempty list.

Engineering notes

The behavior is reported in product versions 4.2.13 and 4.2.14, and the same conditional initialization path is present in the inspected 4.2.14 source. No regression boundary was identified. The exception's source dependency was not present in the workspace; the recorded stack identifies it as coming from codeinwp/optimole-sdk, while the product caller and initialization lifecycle were inspected locally. The REST route uses the default manage_options permission callback in inc/rest.php, lines 189–232, so the reported surface is an authenticated REST request.

Test coverage status

tests/test-poll-optimized-images.php covers successful nonempty polling at lines 188–218, but its setup supplies CDN key and secret at lines 22–33. Error and empty-list cases are also covered. No relevant test was found for a nonempty response with the SDK uninitialized. Tests were not run.

What to verify or explore next

• May be worth verifying polling with a valid API response while CDN connection settings are absent or incomplete.
• If reproducing against a tagged release, checking whether the REST request can occur during or immediately after disconnection would clarify the triggering state.
• The affected sites' saved service data and initialization state are not available in this report.

Unknowns / follow-up

The telemetry does not identify the API-key state, connection settings, or request timing on the affected sites. The actual deployed codeinwp/optimole-sdk source was not available in this workspace for independent inspection.

Confidence

Confidence: 82/100

One product-side initialization precondition gap is confirmed in the REST polling path and no matching open GitHub issue was found. The other three crashes are not confirmed code defects: the reported SDK file and both product classes exist in the reported release with reachable load paths, so the telemetry is consistent with transient or inconsistent runtime files.

Crash telemetry

Occurrences	5
Distinct sites	2
First seen	2026-09-23 15:21 UTC
Last seen	2026-09-23 19:46 UTC
Crash location	product:vendor/codeinwp/optimole-sdk/src/Optimole.php:80
Request context	rest
Inside Themeisle SDK	no
Product versions	4.2.13, 4.2.14
WP versions	6.9.9, 7.1.2
PHP versions	8.2.15, 8.2.33
SDK versions	3.3.61, 3.3.62

---

Source: automated crash report — optimole-wp, fingerprint 929319f2cd6aedc1c371f0cdb334d42a
Generated by bug-report-triage (ID: bug-report-triage_6ab60e5e41a8e2.77469449)