5 Commits

Include renames

Author	SHA1	Message	Date
thatguygriffandClaude Opus 5	e2da45a1b0	Update stripe-php from 17.6.0 to 21.2.1 ... Four majors behind on the plugin's only production dependency. No site is using Stripe yet and the integration has not been verified end to end, so the pinned API version can move now at close to zero cost — later it would mean coordinating with live payment traffic. The library surface this plugin uses is four symbols, all in StripeGateway: StripeClient, paymentIntents->create, Webhook::constructEvent and Event. Checked each against the installed v21 by reflection; all present with compatible signatures. Most of the breakage flagged across 18 to 21 is in the V2 Events API, which this does not use — webhooks go through the V1 Webhook::constructEvent path. The pinned Stripe API version moves to 2026-07-29.dahlia. Verified beyond the suite, which mocks the client: a real HMAC-signed payload round-trips through Webhook::constructEvent and returns a Stripe\Event with the expected type and data, and a forged signature still raises SignatureVerificationException. The 21.0.0 ErrorObject retyping to null|string produces no new PHPStan findings. Part of #194 Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 23:15:01 -03:00
thatguygriffandClaude Opus 5	54a8b906f7	Update the dev dependencies ... Routine catch-up on the test and analysis tooling. Every package here is already allowed by the existing constraints, so composer.json does not move and no production dependency is touched. mockery/mockery 1.6.12 -> 1.6.15 phpstan/phpstan 2.2.2 -> 2.2.9 phpunit/phpunit 10.5.63 -> 10.5.64 hamcrest/hamcrest-php v2.1.1 -> v3.0.0 (transitive, via mockery) myclabs/deep-copy 1.13.4 -> 1.14.0 nikic/php-parser v5.7.0 -> v5.8.0 sebastian/recursion-context 5.0.1 -> 5.0.2 Seven patch releases of PHPStan is the one worth watching, since a static analyser routinely gains inferences between them. It reports no new errors here, and PHPCS and the suite are unchanged. Co-Authored-By: Claude Opus 5 <[email protected]> Claude-Session: https://claude.ai/code/session_01D9acV1mHktGAb1uyvNmrR2	2026-08-24 23:08:54 -03:00
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