[remyperona]

Description

Closes #1303

The PHP 7.4, 8.0 and 8.1 CI jobs fail at composer install on every PR, because roave/security-advisories now conflicts with php <8.2.35|>=8.3,<8.3.36|…. This is CI-only: there is no change for plugin users, and the released ZIP is built with --no-dev.

Before setup-php-composer runs, a new step removes roave/security-advisories from require-dev on PHP 7.4/8.0/8.1 only. The committed composer.json stays the same.

Type of change

• New feature (non-breaking change which adds functionality).
• Bug fix (non-breaking change which fixes an issue).
• Enhancement (non-breaking change which improves an existing functionality).
• Breaking change (fix or feature that would cause existing functionality to not work as before).
• Sub-task of #(issue number)
• Chore
• Release

Detailed scenario

What was tested

• Reproduced locally with PHP 7.4.30: composer update --dry-run fails with the same roave conflict on the current composer.json. After the step's jq edit, it resolves (62 packages, phpunit 9.6.38).
• Parsed all three workflows to check the new step's if: and run:.
• The CI on this PR is the real check: the PHP 7.4/8.0/8.1 jobs should get past Setup PHP + Composer, Strauss included, and the 8.2+ jobs should be unaffected.

How to test

Check that WP 5.9 with PHP 7.4, WP latest with PHP 8.0, WP latest with PHP 8.1 and Code Coverage. pass Setup PHP + Composer and run their test suites. In the 8.2+ jobs, the Drop roave/security-advisories… step should show as skipped.

Affected Features & Quality Assurance Scope

CI only: test.yml, test_legacy.yml, code_coverage.yml. No plugin code changed.

Technical description

Documentation

Roave now lists advisories for PHP itself in its conflict section. Upstream says this is intentional (Roave/SecurityAdvisories#155). PHP 7.4, 8.0 and 8.1 are end of life and will never ship a version outside the range, so the conflict on them is permanent.

Options considered:

Option	Why not / why
Pin roave to a commit from before the PHP entry	Freezes the advisory list for every PHP version, which quietly drops protection on 8.2+ too.
--ignore-platform-req=php	Also ignores every package's PHP constraint, so 7.4 could install PHP 8-only packages.
Set config.platform.php	Resolves dependencies for the wrong PHP version.
Remove roave from composer.json entirely	Changes every developer's setup. A separate decision (see Risks).
Remove roave in CI for EOL PHP only (this PR)	Smallest change. 8.2+ jobs keep roave, and the committed file is unchanged.

The step runs before the shared wp-media/workflows setup-php-composer action, because that action sets up PHP and installs dependencies in one go, with no hook in between. It uses jq, which is preinstalled on GitHub runners, because PHP and Composer don't exist yet at that point. composer-options: '' is unchanged, so the post-install/update scripts (Strauss prefixing) still run.

New dependencies

None.

Risks

• On PHP 7.4/8.0/8.1 the dependency set can differ from 8.2+ (for example phpunit 9 vs newer), and roave no longer checks it there. Composer 2.9+ (CI runs 2.10.3) still refuses package versions with known advisories during composer update by itself (policy.advisories.block, on by default), so only roave's PHP-runtime conflict is lost on those jobs.
• Locally, developers on PHP below 8.2.35 (for example Local's 8.2.30) hit the same conflict on composer update. That is out of scope here. Removing roave altogether in favour of Composer's native blocking could be a follow-up.
• The PHP version list in the if: must be updated if the matrix adds another end-of-life version.

Mandatory Checklist

Code validation

• I validated all the Acceptance Criteria. If possible, provide screenshots or videos.
• I triggered all changed lines of code at least once without new errors/warnings/notices.
• I implemented built-in tests to cover the new/changed code.

Code style

• I wrote a self-explanatory code about what it does.
• I protected entry points against unexpected inputs.
• I did not introduce unnecessary complexity.
• Output messages (errors, notices, logs) are explicit enough for users to understand the issue and are actionnable.

Unticked items justification

There are no built-in tests: this is a CI workflow change, and the CI run on this PR is its test. The acceptance criteria are confirmed by that run (see "How to test").

Additional Checks

• In the case of complex code, I wrote comments to explain it.
• When possible, I prepared ways to observe the implemented system (logs, data, etc.)
• I added error handling logic when using functions that could throw errors (HTTP/API request, filesystem, etc.)

🤖 Generated with Claude Code

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Coverage ∅ diff coverage

Metric	Results
Coverage variation	Report missing for 34da2131
Diff coverage	✅ ∅ diff coverage (50.00%)

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (34da213)	Report Missing	Report Missing	Report Missing
Head commit (44234e8)	20546	1653	8.05%

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#1304)	0	0	∅ (not applicable)

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

¹ Codacy didn't receive coverage data for the commit, or there was an error processing the received data. Check your integration for errors and validate that your coverage setup is correct.

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}