Update wp-config.php regex to handle strict types declaration

[andyexeter]

Summary

When W3TC enables page caching it adds the WP_CACHE constant to wp-config.php, inserting it immediately after the opening <?php (or <?) tag. On installs that use declare(strict_types=1); this places the constant above the declaration, which is a fatal error:

PHP Fatal error:  strict_types declaration must be the very first statement in the script in /app/public/wp-config.php on line 5

Fix

Update the insertion regex in PgCache_Environment::wp_config_add_directive() so that, when a strict_types declaration follows the opening tag, the WP_CACHE directive is inserted after that declaration — keeping strict_types as the first statement in the file.

The regex is deliberately conservative and handles the real-world variations:

• Comments between the tag and the declaration — block (/* */), line (//) and hash (#) — since PHP allows a docblock before declare(strict_types=1).
• Multi-directive declares in either order, e.g. declare(strict_types=1, ticks=1) and declare(ticks=1, strict_types=1).
• Backward compatibility: a declare without strict_types (e.g. declare(ticks=1), which has no first-statement restriction) and a plain WordPress docblock with no declare both still receive the directive right after the opening tag, exactly as before.

Test

Adds tests/test-wp-config-directive.php, a standalone regression test (same convention as the other tests/test-*.php files — run with php tests/test-wp-config-directive.php). It mirrors the insertion regex and asserts the exact output for 12 scenarios (19 assertions), covering:

• standard <?php / short <? tags (directive follows the tag);
• strict_types on its own line and on the same line as the tag;
• case-insensitive DECLARE with internal whitespace;
• docblock / line / hash comments before the declaration;
• multi-directive declares in both orders;
• the negative declare(ticks=1) and plain-docblock cases;
• single-insertion only.

Each strict_types case also asserts that strict_types still precedes the inserted WP_CACHE define.

$ php tests/test-wp-config-directive.php
19 passed, 0 failed

Verified end-to-end that the generated wp-config.php is valid PHP and defines WP_CACHE for the strict_types + docblock and multi-directive cases (which previously produced a fatal).

[codecov-commenter]

Codecov Report

❌ Patch coverage is 0% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 1.52%. Comparing base (5f6f522) to head (eb5176a).
⚠️ Report is 58 commits behind head on master.

Files with missing lines	Patch %	Lines
PgCache_Environment.php	0.00%	1 Missing ⚠️

Additional details and impacted files

@@           Coverage Diff            @@
##             master   #1250   +/-   ##
========================================
  Coverage      1.52%   1.52%           
  Complexity    19723   19723           
========================================
  Files           634     634           
  Lines         98658   98658           
========================================
  Hits           1509    1509           
  Misses        97149   97149           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[andyexeter]

@cssjoe would you mind taking a look at this when you get a chance?

It's a small fix for a fatal we hit on strict_types installs — W3TC inserts WP_CACHE above the declare(strict_types=1); line in wp-config.php, which PHP rejects as a fatal error.

I've just pushed an update that hardens the regex (handles comments before the declare and multi-directive declares) and added a standalone regression test, so the earlier codecov 0%-coverage flag is covered now.