Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Cron logger crashes when Optimole settings option is a string

Đã đóng
  • Có gì không ổn?
#1,104 3 bình luận 0 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@girishpanchal30 đang làm issue này rồi.

Từ ngày 6/8/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

bug-report bug-report-triage crash-report

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

  1. On Optimole v4.2.10, persist a non-array value such as a string for the optml_settings option.
  2. Trigger the cron workflow that sends Themeisle SDK logger data.
  3. The product filter reaches Optml_Main::add_settings() and telemetry indicates the request throws Error: 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 unsets service_data and api_key as array offsets on the raw option value.
  • inc/main.php — Optml_Main::instance() line 109 attaches add_settings() to optimole_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 tag v4.2.10 directly returns get_option( $this->namespace, false ) with no array validation.
  • Commit 8716dd792bffbbef1dbae21e5eaab8edd5535091 introduced the logger callback on 2025-08-18. Tag v4.2.10 points to 060fd3fe424f5fd239304fd8dd7f6736fb90596d and retains the unvalidated raw-option return. Commit 0165f5e76deecfc8fee6c7b5058c00baaa8f7bb0, dated 2026-08-04 and after v4.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_settings to be persisted as a string or another non-array value. The telemetry does not disclose how that persisted value arose.
  • Current master contains the guard from 0165f5e7; the affected telemetry version is the earlier released v4.2.10 tag.
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.10 tag by storing a string in the optml_settings option and triggering the logger cron action.
  • May be worth confirming the first release that includes commit 0165f5e7 and whether affected sites remain on v4.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)

Ngôn ngữ chính
PHP
Star
74
Fork
14
Merge trung bình
2 ngày 9 giờ
Pull request đã merge (30 ngày)
22

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của Codeinwp/optimole-wp

Tất cả issue của Codeinwp/optimole-wp

Issue tương tự

Thêm issue về PHP

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.