3 Commits

Include renames

Author	SHA1	Message	Date
thatguygriffandClaude Opus 5	908b7fcd1f	Update the coding-standards tooling off three security advisories ... composer audit reported three advisories against the PHPCS stack, two rated high: squizlabs/php_codesniffer 3.13.5 -> 3.13.6 CVE-2026-67434, OS command injection wp-coding-standards/wpcs 3.3.0 -> 3.4.1 CVE-2026-45293, arbitrary code execution phpcsstandards/phpcsutils 1.2.2 -> 1.2.3 CVE-2026-65954, arbitrary code execution All three are dev-only and none ship in the plugin — bin/build-zip.sh installs --no-dev — but they execute against repository content on every CI run. The existing ^3.7 and ^3.0 constraints already allowed the fixed releases, so composer.json is unchanged. phpcsextra and the codesniffer installer come along as transitive dependencies. Five packages move, none are added or removed, and the updated standards report no new violations. composer audit is now clean. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:50:34 -03:00
thatguygriffandClaude Opus 5	b17adf02ff	Pin the Composer platform to PHP 8.1 ... composer.json declares "php": ">=8.1", but resolution ran against whatever PHP the machine doing the update happened to have. Running composer update on 8.5 could therefore produce a lock containing a package that requires 8.2 or newer, which installs fine locally and fails on the 8.1 leg of the test matrix — a lock that is only discovered to be wrong in CI. config.platform.php makes resolution always target the declared minimum, so a lock that resolves at all is a lock that installs everywhere the plugin claims to run. No package versions change: nothing currently locked requires a PHP newer than 8.1, so this only records platform-overrides and the new content hash. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:46:11 -03:00
thatguygriffandClaude Opus 5	c9d18fec74	Commit composer.lock so CI and releases install a fixed dependency set ... composer.lock was gitignored, so `composer install` resolved the graph afresh on every job. CI could quietly start testing different dependency versions than it did the day before, and two builds of the same tag could ship different vendor trees — the run that produces the zip is the same run that picks the versions. Track the lock, and make the two places that consume it use it: - the Composer cache keys hash composer.lock rather than composer.json, since the lock is now what actually fingerprints the dependency set; - bin/build-zip.sh stages the lock alongside composer.json, so the --no-dev production install resolves to the locked versions. It already deleted both from the staging directory before zipping, so the shipped plugin is unchanged. The current lock installs cleanly on 8.1: nothing in it requires a PHP newer than the >=8.1 composer.json declares. Closes #187 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 22:33:04 -03:00