Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Cron logger crashes when Optimole settings option is a string

オープン
  • 何か問題がありますか？
#1,104 コメント 3 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@girishpanchal30 がすでに取り組んでいます。

2026年8月6日 から。

評価

この issue はまだ評価されていません。

説明

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)

主要言語
PHP
スター
73
フォーク
14
平均マージ
2日 12時間
マージ済み PR（30日）
18

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Codeinwp/optimole-wp のほかの issue

Codeinwp/optimole-wp の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。