[bonelifer]

Adds .github/workflows/epv.yml, a reusable workflow that runs EPV (Extension Pre Validator) on a phpBB extension and fails when it finds a problem the extension hasn't explicitly allowed.

Why

• EPV exits 0 unless it finds a Fatal problem: its ValidateCommand returns 1 only when the Fatal count is above zero, on both phpbb/epv:dev-master and dev-epv-phpbb4. Error findings print "Validation: FAILED" and the job still passes. This is how an EPV htmlspecialchars error in phpbbmodders/contactadmin went unnoticed until Support phpBB 4.0 and start 1.6.1-dev contactadmin#45.
• The usual --dir="phpBB/ext/$EXTNAME/", used by the phpbbmodders extensions' copied template and by phpbb-extensions/test-framework alike, makes EPV report a false "Packaging structure doesn't meet the extension DB policies" error. Pointing it at phpBB/ext/, the folder that contains vendor/name, avoids that. phpBB keeps only index.htm there on 3.3.x and master, so nothing else is scanned.
• EPV has no way to ignore a finding, and some findings are justified.

What it does

• Inputs: EXTNAME (vendor/name) and PHPBB_BRANCHES, a JSON list that defaults to ["3.3.x"]. Each branch runs as its own job, named EPV - phpBB <branch>.
• Checks out phpBB and the calling extension, and installs EPV with phpBB's own composer.phar: dev-master with PHP 7.4 for 3.3.x, and dev-epv-phpbb4 with PHP 8.2 for master, because EPV's dev-master can't install next to phpBB 4.0's Symfony 7.
• Runs EPV and keeps its full output in the log.
• Fails on any Fatal or Error line that isn't listed in the extension's .github/epv-allowed.txt. Entries are written as EPV prints them, without on line N and with paths relative to the extension, so they survive edits elsewhere in a file. Each entry should have a # comment with its reason.
• Warns about allowed entries that no longer occur.

Use from an extension's workflow (after this is merged and tagged v1):

jobs:
    epv:
        uses: phpbbmodders/.github/.github/workflows/epv.yml@v1
        with:
            EXTNAME: vendor/name
            PHPBB_BRANCHES: '["3.3.x", "master"]'

Testing

Claude ran this workflow's own run: steps, taken from the YAML, in throwaway Docker containers against the phpbbmodders/contactadmin pilot branch (epv-strict):

• phpBB 3.3.x with PHP 7.4 and phpBB master with PHP 8.2: no packaging false positive, the allowed unserialize finding is accepted, and the job passes.
• With the allowlist removed, the job fails and names the finding.
• With a stale entry added, it passes with a warning.

The filter was also checked on EPV output from all 50 phpbbmodders extensions with a tests.yml. 39 have no Fatal or Error findings. The other 11 need fixes or allowlist entries before they switch over, and that rollout is a separate step.

After merging

Tag the merge commit v1 so extensions can pin to it. The contactadmin pilot currently pins this branch's commit (3dcf869) and switches to @v1 before it is merged.

---

Investigated and written by Claude on behalf of William Jacoby (bonelifer).

🤖 Generated with Claude Code

[bonelifer]

@kaileymsnay, a quick briefing for you.

TL;DR: why this workflow exists, and where things stand (10/19/2026)

The problem

• EPV (phpBB's Extension Pre Validator) exits 0 unless it finds a Fatal problem. Its Error findings, the ones phpBB.com validators act on, printed "Validation: FAILED" while every job stayed green.
• The usual --dir="phpBB/ext/$EXTNAME/" also produced a false "Packaging structure" error in every run. Real errors were easy to dismiss as part of that noise.
• This surfaced in phpbbmodders/contactadmin: an EPV htmlspecialchars error passed CI unnoticed until Support phpBB 4.0 and start 1.6.1-dev contactadmin#45.

What was done

• This PR: one shared workflow, epv.yml@v1. It runs EPV the right way (--dir=phpBB/ext/, with the phpBB 4.0 EPV branch where needed) and fails CI on any Fatal or Error finding, unless the extension lists it with a reason in .github/epv-allowed.txt. Released migrations can't be changed, and some findings are deliberate, so the allowlist keeps those visible and justified rather than silently passing.
• Pilot: Run EPV through the organization's strict EPV workflow contactadmin#46, merged.
• Rollout: a survey of all 50 extensions with a tests.yml found 39 clean and 11 with Error findings. 47 rollout PRs are open; each repo's real findings were fixed (for example htmlspecialchars changed to utf8_htmlspecialchars) or allowlisted with a reason.
• Runner pin: Pin the EPV workflow to ubuntu-24.04 #3 pins ubuntu-24.04, because ubuntu-latest moves to Ubuntu 26.04 from today and ubuntu-22.04 is deprecated. v1 was moved to it, so every caller picks it up with no change on their side.

Side findings along the way

• Two repos (bulkuseradd, pmwelcome) hadn't run CI in months: their runner images are retired and their PHP 7.1 jobs can't run against phpBB 3.3. Each has a fix PR.
• 45 repos pin ubuntu-22.04 or rely on ubuntu-latest. Each has a PR pinning ubuntu-24.04, and five of them also raise their declared PHP minimum to 7.4.

Not covered: knowledgebase (handled separately) and trackers (left alone by policy).

---

Investigated and written by Claude on behalf of William Jacoby (bonelifer).