Move the gate's ABSPATH guard into the 50 lines Plugin Check reads

[Shubochandrosarker]

What this changes

CI / WordPress Plugin Check has been red on main with one error — missing_direct_file_access_protection, "PHP file should prevent direct access" — and the message is misleading, because the file did prevent direct access. Plugin Check's Direct_File_Access_Check reads a file's first 50 lines when it looks for the guard and nowhere else; in includes/payments/class-payment-integrity-gate.php a 39-line docblock plus a twelve-line use block had pushed the guard to line 56. The check therefore concluded there was no guard, and because the file plainly contains executable code it reported an error instead of waiving it. After this PR the guard sits directly under the namespace declaration and above the imports — where the rest of the plugin already puts it — at line 46. The protection itself is unchanged; it is now somewhere the reviewer's tool can see it.

Closes #

Type

• Release/CI plumbing

Rules touched

• None of the above

The change is the position of a defined( 'ABSPATH' ) guard within one file, plus a new test. No runtime behaviour, no payment logic, no schema.

Multi-edit checklist

• N/A — no new class file, no database change, no shortcode, no capability, no version bump.

Documentation

• No docs needed, because: nothing user-visible changed. The reasoning lives where it is actionable — a two-line comment at the guard and the docblock of tests/unit/DirectAccessGuardTest.php.

What I ran

$ find . -name '*.php' -not -path './vendor/*' -not -path './build/*' -print0 | xargs -0 -n1 php -l
(no output — every file clean)

$ find assets -name '*.js' -print0 | xargs -0 -n1 node --check
js ok

$ vendor/bin/phpunit -c phpunit.xml
............................................................. 124 / 124 (100%)
Time: 00:00.287, Memory: 16.00 MB
OK (124 tests, 1107 assertions)

$ bin/build-dist.sh && bin/assert-dist-clean.sh
distributable is clean

$ for f in $(find build/memberistic -name '*.php'); do ... done | sort -rn | head -3
46 includes/payments/class-payment-integrity-gate.php
44 includes/class-privacy.php
43 includes/payments/providers/interface-payment-provider.php

The last one is the audit that identified the fault: the gate was the only shipped file whose guard fell outside the window, which is why exactly one file was ever reported.

What I did NOT test

Plugin Check itself was never run locally. wp-env needs Docker and network access to api.wordpress.org and downloads.wordpress.org, both blocked in this environment, so the only proof this fixes the job is the CI run on this PR. What I did instead was read Direct_File_Access_Check from the plugin-check source and port its logic locally to reason about it — useful for finding the 50-line window, but not a substitute for the real run.

Two earlier attempts at this failed because they reasoned from the error message rather than from the tool: uninstall.php is skipped by this check entirely, and index.php was already inside the window. Neither was ever the cause.

Risk and rollback

• Blast radius if this is wrong: none at runtime. The guard fires under exactly the same condition as before; only its line number moved. Worst case the CI job stays red and we have learned something more about the check.
• How to roll it back: revert the commit.
• Does it need a data migration to reverse? no

---

Generated by Claude Code