Auto-install Payments & Shipping plugin on WooCommerce activation

[chrisdavidmiles]

https://newfold.atlassian.net/browse/PRESS0-3627

Proposed changes

Restores auto-installing payments & shipping when WooCommerce is activated, for any site at any time (not just onboarding).

Background: in Dec 2025 (PRESS0-3588) the old YITH payment auto-install was removed because the YITH plugins were replaced by the consolidated Payments & Shipping plugin — but the replacement install (PRESS0-3627) was never wired up. Net effect: activating WooCommerce installed nothing. Reported in PRESS0-4705.

• Re-enables the activated_plugin hook → detect_plugin_activation().
• detect_plugin_activation() installs nfd_slug_wp_plugin_payments_shipping when woocommerce/woocommerce.php is activated, with an early return so it only fires for WooCommerce.

Depends on newfold-labs/wp-module-installer#331 (catalog entry).

Type of Change

• Bugfix (non-breaking change which fixes an issue)

Visual

N/A — backend activation behavior.

Checklist

• Verified end-to-end in the Bluehost plugin wp-env: activating WooCommerce installs + activates the catalog plugin; non-WooCommerce activations install nothing (guard); re-activation is idempotent.
• PHPCS clean (0 errors).

Further comments

Requires the installer catalog entry (#331) and the plugin zip published to the free download worker under wp-plugin-payments-shipping. Until the zip is in the bucket, the install call is a no-op/404 — no fatal.

[github-actions]

AI code review

✅ Strengths

• Restores the missing auto-provisioning behavior cleanly by re-enabling the activated_plugin hook and scoping the action strictly to woocommerce/woocommerce.php (good guard/early return).
• Minimal, targeted change that avoids side effects on non-WooCommerce activations.
• Clear docblock update explaining scope and intent; code removes the legacy YITH pathway to prevent confusion going forward.
• Uses the Installer module’s single call for idempotent install/activation, which should keep re-activations safe.

⚠️ Suggestions (non-blocking)

• Consider a defensive guard for the installer dependency to prevent fatals in odd load orders or if the installer is not present/up-to-date:
  • Example: if ( ! class_exists( '\\NewfoldLabs\\WP\\Module\\Installer\\PluginInstaller' ) ) { return; }
• Accept the second activated_plugin parameter ($network_wide) in case WooCommerce is network-activated on multisite. Even if you don’t need it now, declaring the signature and passing 2 to add_action makes behavior explicit and future-proof.
• Wrap the install call with basic error handling/logging. If PluginInstaller::install returns a WP_Error or throws, we should log (or at least silently bail) rather than risk surfacing errors to admins on activation.
• Extract the catalog slug (nfd_slug_wp_plugin_payments_shipping) into a class constant for maintainability and discoverability.
• Tests: add a unit/integration test that
  • Fires activated_plugin with woocommerce/woocommerce.php and asserts PluginInstaller::install is invoked once.
  • Fires it with a non-Woo plugin and asserts no call.
  • Optional: a multisite case covering $network_wide.
• Docs: update docs/changelog.md and add a brief note in docs/index.md describing that Payments & Shipping is auto-installed on WooCommerce activation (post-YITH consolidation), and add the dependency note on the catalog entry.

❌ Issues

• No blocking issues found. The change is low-risk and appropriately scoped.

Testing notes

• Please sanity check on a multisite with (a) single-site Woo activation and (b) network activation to confirm expected behavior and idempotency.
• Confirm behavior when the catalog slug is temporarily unavailable (ensure no fatal, as noted in the PR description) and that admin UX remains smooth.

Verdict

⚠️ Verdict: Merge with minor follow-ups. The core fix is correct and scoped; adding small guards (installer existence, error handling) and tests would harden this behavior, especially for multisite/network activation and installer availability edge cases.

[github-actions]

Coverage: Base 8.81% → PR 8.88% (must not decrease).
✅ No decrease.

project coverage report 8.88% @ 4e112a9

[arunshenoy99]

Approved ✅

Reviewed thoroughly alongside the paired catalog PR newfold-labs/wp-module-installer#331.

What this does: Re-enables the activated_plugin → detect_plugin_activation() hook and installs nfd_slug_wp_plugin_payments_shipping when WooCommerce is activated, with an early return so it only fires for woocommerce/woocommerce.php.

Verification performed:

• Slug matches the catalog entry exactly (installer#331 defines nfd_slug_wp_plugin_payments_shipping). PluginInstaller is already imported in ECommerce.php — no missing-class fatal.
• No race condition / no recursion. activated_plugin fires synchronously in-request. PluginInstaller::install() calls activate_plugin() on the payments plugin, which re-fires activated_plugin — but the 'woocommerce/woocommerce.php' !== $plugin early return cleanly stops re-entry. The separate detect_plugin_activation in wp-module-data's Jetpack listener is an independent callback on a different instance — no collision.
• Idempotent. is_plugin_installed() / is_plugin_active() guards inside install() make repeat WooCommerce activations safe (no double install/activate).
• No fatal when dependencies aren't ready. If installer#331 hasn't shipped, the unknown slug returns a WP_Error that detect_plugin_activation() discards (return value unused). If the worker zip 404s, same graceful no-op. The PR's own note confirms this.
• Admin functions are available because activated_plugin only fires from within wp-admin/includes/plugin.php's activate_plugin(); the upgrader files are explicitly required in install_from_zip().

Pattern mirrors the prior YITH auto-install (proven), consolidated to a single slug. Ship together with installer#331 and ensure the wp-plugin-payments-shipping zip is published to the free-download worker.