FIX #7942: Varnish Purge on Cloudways

[Miraeld]

Description

Fixes #7942 Change Cloudways Varnish port from 8080 to 80

• Route PURGE requests through Nginx (port 80) instead of directly to Varnish (port 8080)
• Ensures Nginx adds required X-Real-IP header for Cloudways' new VCL
• Update test fixtures to reflect port change

Type of change

• [x] Bug fix (non-breaking change which fixes an issue).

Detailed scenario

What was tested

• Unit tests verify the Varnish IP change (port 8080 → 80)
• Unit tests verify X-Real-IP header injection when Varnish is running
• Tests cover edge cases: Varnish not running, missing headers, varnishpass mode

How to test

Prerequisites:

• Cloudways server with Varnish enabled
• WP Rocket installed

Steps:

• Clear cache from WP Rocket dashboard
• Check Varnish logs to verify PURGE requests are successful
• Confirm cache is actually cleared (visit a page, check it's regenerated)

Expected result:

• PURGE requests should reach Varnish through Nginx (port 80) with X-Real-IP header included, allowing Cloudways VCL to properly validate and process the cache purge.

Technical description

Documentation

This pull request enhances the integration with Cloudways Varnish caching by ensuring that the correct headers and IP addresses are used during purge requests. It introduces a new method to add the X-Real-IP header when Varnish is detected, updates the default Varnish IP, and adds comprehensive tests to verify this behavior.

Cloudways Varnish integration improvements:

• Added a new method, add_purge_headers, in Cloudways.php to inject the X-Real-IP: 127.0.0.1 header into Varnish purge requests when Varnish is running, and registered it to the rocket_varnish_purge_headers filter. [1] [2]
• Changed the default Varnish IP from 127.0.0.1:8080 to 127.0.0.1:80 in Cloudways.php and updated related test fixtures to reflect this change. [1] [2] [3] [4] [5]

Testing improvements:

• Added a new fixture file, addPurgeHeaders.php, with various scenarios for header injection based on Varnish status.
• Introduced integration and unit test classes to validate the behavior of add_purge_headers under different server configurations. [1] [2]

Mandatory Checklist

Code validation

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

Code style

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

[Miraeld]

Special mention to @jeawhanlee , regarding this comment, The engineer from Cloudways mentioned

set through port 80 so that all requests are routed through Nginx, ensuring the request headers—such as the real-ip header—are preserved as expected

Preserved doesn't assure that headers are added as we want, so I added a header addition in case.

[codacy-production[bot]]

Coverage summary from Codacy

See diff coverage on Codacy

Coverage variation	Diff coverage
Report missing for 7666e82a3ec7a142181052d2c979ed5571dc1884[^1]	:white_check_mark: 100.00% (target: 50.00%)

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (7666e82a3ec7a142181052d2c979ed5571dc1884)	Report Missing	Report Missing	Report Missing
Head commit (bff588b3d101a1342bd2dcd8554c488e2dd23f1b)	41856	18877	45.10%

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 (#7948)	1	1	100.00%

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%

See your quality gate settings    Change summary preferences

[^1]: 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.

[jeawhanlee]

@Miraeld From my little findings, if you log $_SERVER['HTTP_X_REAL_IP'] on our cloudways site, you'll see it's added without purge triggered, so I'm thinking this will be the case even when purge is triggered.