[RajkiranBagal]

Problem

Fatal Cannot use object of type stdClass as array on wp-admin/update-core.php. Core's list_plugin_updates() dereferences $plugin_data->update->icons['1x'], but the value is a stdClass.

Triggered by a stale update_plugins site transient entry written by a pre-1.2.0 SDK, where icons (and banners) were json_decode stdClass and never cast to array. v1.2.0 casts on a fresh fetch but never rewrites the stale persisted entry, and check_plugin_update() early-returns the stale entry untouched.

Why not serialize/cache

PHP serialize/unserialize preserves array-vs-object, so this isn't a cache round-trip artifact. The stdClass originates at json_decode, not at the cache layer.

Solution

New normalize_update_assets() helper coerces icons/banners to arrays, applied at:

• a site_transient_update_plugins read filter — the guaranteed path, since core re-reads the transient on update-core.php; covers the sub-minute window where wp_update_plugins() short-circuits.
• the check_plugin_update() early-return.
• the response write.

Idempotent, scoped to this plugin's own basename, plugin path only (themes untouched).

Tests

tests/unit/UpdaterTest.php:

• read filter normalizes a stale stdClass entry (the pre-fix fatal case)
• idempotency on already-array assets
• three defensive no-ops
• the check_plugin_update() normalization path

Notes

Forward-safe — no transient flush/migration needed (the read filter heals on first update-core.php load). no_update left uncast deliberately (core only derefs ->response). Suite is lint-verified only; phpunit was not run in a real WP test-DB env here.

🤖 Generated with Claude Code