Recent Commits to wp-pluginsused:master (4)

The static analysis note takes the file's own dash

wp-sweep also had it between the phpcs block and the paragraph explaining
phpcs.xml, which belong together.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

CLAUDE.md says what composer analyse is for

The commands section named the suites and the linters and not the analysis,
which is the one a contributor is most likely to trip and least likely to
guess the rules of: that the baseline shrinks rather than gets regenerated,
and that the stub file holds only what the main file computes rather than
anything it already defines.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PHPStan analyses at level 8, and CI fails on what it finds

composer analyse runs PHPStan over the main file, uninstall.php and includes/
at level 8, and a Static analysis job runs it on every push. Level 8 because 9
is strict about mixed, and get_option(), get_post_meta(), $wpdb and the
superglobals all return it: every idiomatic (int) get_post_meta() becomes a
guard nobody asked for. Six through eight found real defects elsewhere in the
collection; nine found the platform.

phpstan-baseline.neon records every error that existed when analysis was
switched on, and nothing after. New code fails the build. A fixed error leaves
a stale entry, which PHPStan reports and which is deleted, not regenerated
around. phpstan-stubs/constants.stub declares the two constants the main file
computes -- PHPStan will not call plugin_dir_path() to learn them -- and never
a literal the main file already defines, which would be a second copy of the
version string. It is not a .php file because a .php beside the main file
reads as something WordPress might load.

The stubs are php-stubs/wordpress-stubs pinned to ^7.1 to match Tested up to.
Left to resolve they did not stay the same version across the collection, and
the 7.x stubs need the 2G the composer script passes: at the default the
parallel workers crash rather than degrade, and the run reports a crashed
worker instead of the errors it found. Everything is excluded from the release
by one phpstan* glob.

Docblocks only in the code: a $wpdb row is stdClass rather than a bare object
that promises no properties, and a template tag that echoes on $display says
so with a conditional return type instead of string|void, which made every
caller that passed false null-check a value that could not be null. Nothing
in a docblock reaches a site, so no version moves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

The actions run on Node 24, and Package moves to one shared job

actions/upload-artifact@v4 and actions/checkout@v4 declare node20, which
the runners no longer provide -- GitHub was already forcing them onto 24
and saying so in an annotation. ci.yml had moved checkout to v7 and the two
Claude workflows had not, so this repository was running two majors of one
action. Nothing between v4 and v7 of either touches how they are used here:
the inputs in use are unchanged, and v7 of checkout restricts only fork
pull requests under pull_request_target and workflow_run, neither of which
any workflow here uses.

Package is a caller now. The job it names builds the zip a release would
have built -- the build where there is one, the deploy's exclusion list,
the readme transform -- and lives in the tooling repository, because that
exclusion list is already a copy of the release procedure's and a copy of a
copy in nineteen places is how one skip list ends up with five spellings.

Run it from the Actions tab when somebody needs a fix before it is on
wordpress.org. The GitHub source zip cannot serve that: build/ is generated
and absent from git, so a plugin with blocks arrives with none registered,
and the zip unpacks under a name WordPress installs beside the copy already
there rather than over it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01757bRbnEDK95mmzYaqupuP