Usage logger crashes when chart settings meta is a string

[pirate-bot]

Summary

During scheduled usage telemetry collection, processing a published chart whose settings value is a string terminates with TypeError: array_key_exists(): Argument #2 ($array) must be of type array, string given. Usage collection is expected to tolerate the stored chart data and complete without an uncaught exception. Instead, the cron request is interrupted and the usage payload is not completed.

Customer context

Product / area: Visualizer usage telemetry
Version: 4.0.7
Environment: WordPress 6.8.6 and 6.9.5; PHP 8.2.31 and 8.3.32; cron request context
Integration / third party: Themeisle SDK 3.3.57 logger invokes the Visualizer filter; the crash is outside SDK code
Reported error / symptom: TypeError: array_key_exists(): Argument #2 ($array) must be of type array, string given
Impact: Three occurrences across three distinct production sites interrupted scheduled usage collection.

Reproduction notes

Production reproduction is established by three telemetry occurrences across three sites. Inferred focused workflow: create or identify a published visualizer chart whose visualizer-settings post meta resolves to a string, then trigger scheduled SDK usage logging so visualizer_logger_data invokes Visualizer_Module_Setup::getUsage(). The observed result is the TypeError at line 116; the expected result is completion without an uncaught exception. The exact workflow that originally produced the string-valued meta is unavailable.

Diagnosis

Conclusion

The defect is confirmed. Production traces place the uncaught exception at Visualizer_Module_Setup::getUsage(), and release 4.0.7 passes the unvalidated visualizer-settings meta value directly as the second argument to array_key_exists(). The captured TypeError establishes that this value was a string on the affected requests.

Where this likely occurs

• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::__construct() lines 42–55 registers getLoggerData() on visualizer_logger_data.
• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::getLoggerData() lines 69–71 forwards SDK logger data into getUsage().
• classes/Visualizer/Module/Setup.php — Visualizer_Module_Setup::getUsage() lines 81–116 queries published charts, reads CF_SETTINGS, and calls array_key_exists() without a type check.
• classes/Visualizer/Plugin.php — Visualizer_Plugin constants lines 30–42 identify inspected code as version 4.0.7 and map CF_SETTINGS to visualizer-settings.
• Commit 7d7075eb0e1d4c25a604f4f0f965fd3de123ba65 introduced the manual-configuration statistic and unchecked call in 2019. The inspected v4.0.7 tag resolves to commit 5413a172602969edbe5d1c8c6dfa4c6eb8b0d0e0, where the path remains present.

Engineering notes

The SDK initiates logging, but the failing contract is in the Visualizer callback, so routing to Codeinwp/visualizer is supported. Normal classic-editor persistence stores sanitized settings arrays in classes/Visualizer/Module/Chart.php — Visualizer_Module_Chart::_handleDataAndSettingsPage() lines 820–868. The origin of the string-valued meta on the affected sites is unknown; regardless of origin, the logger currently lets one incompatible chart record terminate collection for the request. Only the reported free-plugin path and PHP 8.2/8.3 environments were inspected.

Test coverage status

No relevant coverage was found during inspection for Visualizer_Module_Setup::getUsage(), the visualizer_logger_data filter, or string-valued settings meta. Existing settings-related coverage in tests/test-ajax.php includes array-valued persistence scenarios but does not exercise this logger path.

What to verify or explore next

• May be worth reproducing on PHP 8.2 and 8.3 with one published Visualizer chart whose visualizer-settings meta resolves to a string, then invoking the visualizer_logger_data filter.
• May be worth checking empty-string, serialized array, scalar string, and malformed serialized meta cases through the same callback.
• May be worth running the PHPUnit suite after exercising the focused usage-logger path.
• If reproducible, checking whether subsequent cron callbacks are skipped in the active cron runner could clarify the request-level impact.

Unknowns / follow-up

The telemetry does not identify how the affected sites acquired string-valued settings meta or whether those records originated in an older Visualizer release, an import, or third-party code. A local WordPress runtime reproduction was not performed.

Confidence

Confidence: 99/100

Production telemetry from three sites records the same uncaught PHP 8 TypeError at the exact unchecked call present in Visualizer 4.0.7, and no matching existing issue was found.

Crash telemetry

Occurrences	3
Distinct sites	3
First seen	2026-07-30 19:55 UTC
Last seen	2026-07-30 22:31 UTC
Crash location	product:classes/Visualizer/Module/Setup.php:116
Request context	cron
Inside Themeisle SDK	no
Product versions	4.0.7
WP versions	6.8.6, 6.9.5
PHP versions	8.2.31, 8.3.32
SDK versions	3.3.57

---

Source: automated crash report — visualizer, fingerprint 00725a51bf7206b4af13b562a485fdcb
Generated by bug-report-triage (ID: bug-report-triage_6a6c39fec62361.64192737)