Boost: Add filter on cookies so caching is more flexible

[donnchawp]

The cache in Jetpack Boost only operates when a browser has no cookies. If a website uses JavaScript to display UI elements or is proxied through Cloudflare they may set cookies that do not change the HTML of the page, but will stop the page being cached.

This PR fixes that by allowing the site owner to define a set of cookie names that will be removed from the cookie list used by the plugin. By default, it uses the list of Cloudflare cookies listed here, plus a WooCommerce cookie.

The cookie list can be modified by using a filter (although at this time it's not possible to use this filter as we haven't built the "pre WordPress" infrastructure required), or by setting the constant JETPACK_BOOST_IGNORE_COOKIES to a comma separated list of cookie names.

The cache activity log will show any cookies that are removed when cache files are created or served.

Fixes #39935

Proposed changes:

• Add the filter "jetpack_boost_cache_parameters" to the get_parameters() function in Request.php
• Use the get_parameters() function instead of accessing $this->parameters in the Request class.
• In Boost Cache, use that filter to modify the cookie list, removing cookies.

Other information:

• Have you written new tests for your changes, if applicable?
• Have you checked the E2E test CI results, and verified that your changes do not break them?
• Have you tested your changes on WordPress.com, if applicable (if so, you'll see a generated comment below with a script to run)?

Jetpack product discussion

Does this pull request change what data or activity we track or use?

Testing instructions:

• Apply PR to a self hosted website
• Add this to an mu-plugin script:

if ( isset( $_GET['test'] ) ) {
        error_log( "setting test cookie" );
        setcookie('test-cookie', mt_rand(), time() + 3600, '/');
}

• tail -f your PHP error log.
• Load your website with ?test=1 added to the url
• Check that the test-cookie cookie has been set and look for the cache miss in the header of the request for the page.
• Note the "setting test cookie" message in the error log.
• Reload the page and there will be another cache miss, and the cookie will change value.
• Add 'test-cookie' to the list of cookies in pre-wordpress/Boost_Cache.php on line 497.
• Reload the page. The cookie value won't change, meaning the PHP wasn't executed, and the network tab will show a cache hit.

If #40920 is merged, create wp-content/boost-cache-extra.php and add this code to remove the "test-cookie" instead of modifying Boost_Cache.php

function remove_test_cookie( $ignore_cookies ) {
        if ( ! in_array( 'test-cookie', $ignore_cookies ) ) {
                $ignore_cookies[] = 'test-cookie';
        }
        return $ignore_cookies;
}
add_filter( 'jetpack_boost_ignore_cookies', 'remove_test_cookie' );

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add a "[Type]" label (Bug, Enhancement, Janitorial, Task).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Follow this PR Review Process:

1. Ensure all required checks appearing at the bottom of this PR are passing.
2. Choose a review path based on your changes:
   • A. Team Review: add the "[Status] Needs Team Review" label
     • For most changes, including minor cross-team impacts.
     • Example: Updating a team-specific component or a small change to a shared library.
   • B. Crew Review: add the "[Status] Needs Review" label
     • For significant changes to core functionality.
     • Example: Major updates to a shared library or complex features.
   • C. Both: Start with Team, then request Crew
     • For complex changes or when you need extra confidence.
     • Example: Refactor affecting multiple systems.
3. Get at least one approval before merging.

Still unsure? Reach out in #jetpack-developers for guidance!

---

Boost plugin:

• Next scheduled release: none scheduled.

If you have any questions about the release process, please ask in the #jetpack-releases channel on Slack.

[dilirity]

This is so cool!

Love the testing instructions by the way!

I would love for @haqadn to take a look at it as well. I'm happy with merging this. A few notes below.

[dilirity]

I think a note about why this is necessary would help understand the reason its there.

Is this so it doesn't get executed multiple times?

[dilirity]

Array unique would eliminate duplicates here!

Also maybe a trim in case a naughty space comes in.