Codeinwp / Codeinwp/optimole-wp
Cron logger crashes when Optimole settings option is a string
@girishpanchal30 is already working on this.
Since Aug 6, 2026.
- Dominant language
- PHP
- Stars
- 72
- Forks
- 14
- Avg merge
- 2d 9h
- Merged PRs (30d)
- 15
Description
Summary
Optimole can terminate a cron request while collecting logger data if its stored settings value is not an array.
Expected behavior: Logger data collection handles an invalid or legacy settings value without terminating the cron request.
Actual behavior: The request throws Error: Cannot unset string offsets.
Impact: Affected sites can have scheduled WordPress work interrupted when the Optimole logger runs.
Customer context
- Product / area: Optimole WordPress plugin, cron logger data collection
- Version: 4.2.10
- Environment: WordPress 7.0.2; PHP 8.2.33
- Integration / third party: Themeisle SDK 3.3.58 is present in the logged call chain, but the fatal frame is in Optimole product code.
- Reported error / symptom:
Error: Cannot unset string offsets - Impact: 2 telemetry occurrences across 1 site between 2026-08-05 and 2026-08-06.
Reproduction notes
- On Optimole
v4.2.10, persist a non-array value such as a string for theoptml_settingsoption. - Trigger the cron workflow that sends Themeisle SDK logger data.
- The product filter reaches
Optml_Main::add_settings()and telemetry indicates the request throwsError: Cannot unset string offsets.
The production crash was observed twice on one site. The malformed option value and its originating workflow are not available from telemetry.
Diagnosis
Conclusion
Production telemetry identifies Optml_Main::add_settings() as the fatal frame during a cron-triggered logger action. In release v4.2.10, the method obtains the raw optml_settings option without validating its type, then uses array-offset unset() operations. A string stored in that option therefore matches the recorded Cannot unset string offsets error. This is confirmed by the post-release commit 0165f5e7, titled fix: handle non-array option values, which changes the raw-settings method to return an empty array for non-array values.
Where this likely occurs
inc/main.php—Optml_Main::add_settings()lines 159-164 registers the logger-data callback and unsetsservice_dataandapi_keyas array offsets on the raw option value.inc/main.php—Optml_Main::instance()line 109 attachesadd_settings()tooptimole_wp_logger_data, matching the product callback named in the production stack trace.inc/settings.php—Optml_Settings::get_raw_settings()lines 785-787 in tagv4.2.10directly returnsget_option( $this->namespace, false )with no array validation.- Commit
8716dd792bffbbef1dbae21e5eaab8edd5535091introduced the logger callback on 2025-08-18. Tagv4.2.10points to060fd3fe424f5fd239304fd8dd7f6736fb90596dand retains the unvalidated raw-option return. Commit0165f5e76deecfc8fee6c7b5058c00baaa8f7bb0, dated 2026-08-04 and afterv4.2.10, contains a non-array guard on the same method.
Engineering notes
- The telemetry call chain reaches the product filter from the bundled SDK logger, but the fatal operation and the missing type boundary are in the Optimole repository rather than SDK code.
- The crash requires
optml_settingsto be persisted as a string or another non-array value. The telemetry does not disclose how that persisted value arose. - Current
mastercontains the guard from0165f5e7; the affected telemetry version is the earlier releasedv4.2.10tag.
Test coverage status
tests/test-logger.php covers logger instance creation and basic log storage/retrieval, but contains no coverage for the optimole_wp_logger_data filter or non-array raw settings. No relevant coverage was found during inspection for Optml_Main::add_settings() with malformed option data.
What to verify or explore next
- May be worth reproducing on the
v4.2.10tag by storing a string in theoptml_settingsoption and triggering the logger cron action. - May be worth confirming the first release that includes commit
0165f5e7and whether affected sites remain onv4.2.10. - If reproducible, checking the relevant PHP unit suite with malformed option values would establish release-level coverage.
Unknowns / follow-up
- The telemetry does not reveal the persisted option value or the workflow that wrote it.
- No customer-site inspection was performed.
Confidence
Confidence: 99/100
Production telemetry provides a direct fatal-error frame in Optimole 4.2.10, and the tagged source permits a string option value to reach array-offset unset() calls. A post-release commit on master adds the missing array validation, confirming the released behavior is a product defect.
Crash telemetry
| Occurrences | 2 |
| Distinct sites | 1 |
| First seen | 2026-08-05 18:04 UTC |
| Last seen | 2026-08-06 00:05 UTC |
| Crash location | product:inc/main.php:161 |
| Request context | cron |
| Inside Themeisle SDK | no |
| Product versions | 4.2.10 |
| WP versions | 7.0.2 |
| PHP versions | 8.2.33 |
| SDK versions | 3.3.58 |
Source: automated crash report — optimole-wp, fingerprint bde4b12fac2c18087bc7e75d92d846e3
Generated by bug-report-triage (ID: bug-report-triage_6a7422fe937474.06797849)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.