Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Cron logger crashes when Optimole settings option is a string

Cerrado
  • ¿Algo no está bien?
#1,104 3 comentarios 0 reacciones 1 asignado Ver en GitHub

Los mantenedores suelen responder en 1 día

@girishpanchal30 ya está trabajando en esto.

Desde el 6/8/2026.

Evaluación

Este issue todavía no se ha evaluado.

Descripción

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)

Lenguaje dominante
PHP
Estrellas
74
Forks
14
Merge medio
2 d 6 h
PR fusionados (30 d)
21

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de Codeinwp/optimole-wp

Todos los issues de Codeinwp/optimole-wp

Issues similares

Más issues de PHP

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.