Install the Claude workflows the collection now runs everywhere The same two files wp-postviews took in its PR #62: @claude answers on issues and PR comments, and every pull request gets a /code-review pass posted as inline comments. Verbatim copies; the CLAUDE_CODE_OAUTH_TOKEN secret has to exist in this repository for either to run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY
Recent Commits to wp-pluginsused:master (7)
-
Install the Claude workflows the collection now runs everywhere
-
Give the upgrade tests the file the siblings give them
Give the upgrade tests the file the siblings give them The fold-in of pluginsused_options -- including the admin-path fold that is the plugin's own §-worthy bug -- and the marker coverage sat inside test-options.php while the sibling suites keep them in test-upgrade.php. Pure move, eight tests and no bodies changed; the options file keeps the storage and precedence coverage it is named for. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY
-
Drive the uninstall fan-out from the suite, every call
Drive the uninstall fan-out from the suite, every call run_uninstall() required uninstall.php on first call -- whose file body runs the real network loop -- and went straight to the per-site function on every later call in the same process, which silently uninstalled only the current site. Two uninstall tests in one multisite run therefore exercised two different behaviours, and which test got which depended on execution order. The helper now carries the fan-out itself, the same loop the file runs with the same arguments, so every call does the same work. This is the form four sibling plugins already used. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY
-
Bring the lockfile up to date with the shared ranges
Bring the lockfile up to date with the shared ranges One declared range had come to resolve differently across the collection -- @wordpress/eslint-plugin ^25.7.0 was locked at 25.7.0 in six plugins and 25.8.0 in thirteen, so npm ci ran a different rule set per repository and a clean lint in one predicted nothing about another. All nineteen lockfiles now resolve the same registry state (25.9.0); eslint and the vitest suites pass on the result. package.json is untouched. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY
-
Spell the test loader the way the other suites do
Spell the test loader the way the other suites do Eight spellings of one function had accumulated across the collection's bootstraps; the shared form is _wp_pluginsused_manually_load_plugin, underscore prefix included, which also puts the plugin's own prefix on a global the old name lacked. The name appears nowhere but this file. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY
-
Stage 2.0.1 for the network-activation fix
Stage 2.0.1 for the network-activation fix Header, constant, Stable tag, changelog section and the metadata suite's expected_version() all move together. Deliberately unreleased so further fixes can accumulate; the release pre-flight ships it when asked. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY
-
Upgrade every site on a network activation, not just the current one
Upgrade every site on a network activation, not just the current one WP_PluginsUsed::activate() took no $network_wide and ran the upgrade against whichever site happened to be current. The settings and the version markers are per-site rows, so every other site on a network kept its pre-2.0.0 row unread -- including its hidden-plugins list, which is the setting whose absence actually publishes something. Nothing was lost -- migrate() only deletes the legacy row once it has folded it in, and the admin_init hook runs the same routine -- so a site healed the moment somebody opened its dashboard. A network whose subsites are front-end only never does, which is why this went unnoticed. tests/test-multisite.php covers the loop, the per-site activation that must not touch its neighbours, the uncapped get_sites() call, and the unwound blog stack. Removing the branch again fails two of the four. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01CVrFykSreGPwV1hTiRdQBY