fix(workspaces): run the real cast activation transition on every boot

[pcfreak30]

The cast guard's read-time force-on filter made every activation path see the
plugin as already active: wp plugin activate no-oped and core's
activate_plugin() skipped its activation block on the same filtered read, so
CastActivator (schema install, cast_version, rewrite flush) never ran and
publish requests failed on a missing wp_cast_export_items table.

Stands the guard filters down under WP_INSTALLING and makes activate_cast()
run a real deactivate_plugins() + activate_plugin() cycle every boot, which
is idempotent and self-heals a lost schema on the next start.

---

Summary

Fixes a regression where the Cast plugin appeared "active" (via the baked-in cast-guard MU plugin's read-time filter) but its real activation transition — schema installation, cast_version marker, rewrite flush via CastActivator — never actually ran.

Root cause: Because cast-guard re-adds Cast to active_plugins on every read of that option, WP-CLI's is_plugin_active() pre-check and core's activate_plugin() both saw Cast as already active and silently skipped the activation block. The result was a plugin that reported active while its DB tables (e.g., wp_cast_export_items) were never created, causing downstream failures (500s in the publish pipeline).

Changes

images/wordpress/mu-plugins/cast-guard.php

• Added a WP_INSTALLING exemption to both the option_active_plugins and site_option_active_sitewide_plugins filters.
• While WordPress's install/upgrade machinery is running (including the boot-time reconciler), the guard's force-on behavior stands down so core can see and drive the true state of the active_plugins option — allowing activate_plugin() to actually execute the activation block.

images/wordpress/wp-init.sh

• Replaced wp plugin activate cast (which was a no-op due to the guard's filtered read) with a wp eval that runs a real activation cycle on every boot:
  • Defines WP_INSTALLING (scoped to the boot process only) so the guard stands down.
  • Silently calls deactivate_plugins() (CastDeactivator is a documented no-op).
  • Calls activate_plugin() to run the real CastActivator transition.
• The cycle is idempotent and self-healing: an unchanged schema is a dbDelta no-op, while a lost or damaged schema/version marker is repaired on the next boot. Activation failure is non-fatal and leaves a WARN for the next boot to retry.

scripts/verify-wordpress.sh

• Added fresh-volume assertions that the activation transition actually ran, not just that the guard reports the plugin active:
  • wp_cast_export_items table exists.
  • cast_version option is set.
• Added a self-healing test: drops the Cast schema table and cast_version option, recreates the container, and verifies the next boot's real activation restores them.

Note from code review (medium)

scripts/verify-wordpress.sh:184 hardcodes the wp_ table prefix in its assertion while probing with $wpdb->prefix — this would cause false failures on non-default table prefixes.

[kody-ai]

Kody Review Complete

Great news! 🎉
No issues were found that match your current review configurations.

Keep up the excellent work! 🚀

Kody Guide: Usage and Configuration

Interacting with Kody

• Request a Review: Ask Kody to review your PR manually by adding a comment with the @kody start-review command at the root of your PR.

• Validate Business Logic: Ask Kody to validate your code against business rules by adding a comment with the @kody -v business-logic command.

• Provide Feedback: Help Kody learn and improve by reacting to its comments with a 👍 for helpful suggestions or a 👎 if improvements are needed.

Current Kody Configuration

Review Options

The following review options are enabled or disabled:

Options	Enabled
Bug	✅
Performance	✅
Security	✅
Business Logic	✅

Access your configuration settings here.

​