Stop invalidating opcache on upgrade for subset of websites

[leonidasmi]

Important

To be merged for the 26.2 release, not earlier.

Context

• The 2nd step of our plan for sunsetting the opcache invalidation upon Yoast upgrade.

Summary

This PR can be summarized in the following changelog entry:

• Disables opcache invalidation on plugin upgrade for a subset of the userbase.

Relevant technical choices:

• The calculation of the staggered rollout could have been added in its own class, since we will probably want to use it elsewhere in the future. However, it was added inline for now, to avoid using new PHP files in the place where we normally do the opcache invalidation, for a more cautious approach. A @todo was added so that the logic is moved once the opcache invalidation is completely phased out
• The calculation of the staggered percentage was based on a variation of what's proposed here: https://github.com/Yoast/reserved-tasks/issues/205
  • generate the SHA-256 hash of the site domain (e.g. home_url( '/' ): e.g. 5238923365edca027a4f8c108d7f7cf45a76c9372e813d9c5b18f2a876c372ae
  • consider only the first 8 characters and convert them from hex to decimal, e.g. 1379439155
  • use this number to assign the site to pool A or B based on whether it's perfectly divided by 10 or not (10, as the percentage of or staggered rollout is 10%)

Test instructions

Test instructions for the acceptance test before the PR gets merged

This PR can be acceptance tested by following these steps:

Preparation:

• To understand whether your site is picked from the staggered rollout logic to have its opcache invalidation disabled, run the following in https://3v4l.org:

<?php

$site = 'http://test-site.local'; // Here add the URL of your homepage.
if ( ( ( hexdec( substr( hash('sha256', $site ), 0, 8 ) ) ) % 10 ) !== 0 ) {
    echo 'site picked to invalidate' . PHP_EOL;
} else {
    echo 'site picked to not invalidate';
}

• Take a note of the result
• (one example of a domain picked to not invalidate is http://test-site-5.local (aka, the new behavior) and one example of a domain picked to invalidate is http://test-site.local)

Test instructions:

• Install Yoast test helper
• Clone op-cache gui to the public folder of your WordPress environment.
• Go to http://wordpress.test/opcache-gui/ (with your site).
• Enable real time update
• Search for wordpress-seo in the Cached tab and see a bunch of files
• Do an upgrade via the Test Helper and switch quickly to the tab where you have the op-cache gui open
• If you had a site picked to invalidate result above:
  • Confirm that at some point, you see no wordpress-seo files in that Cached tab (and then you get a lot of files again, as Opcache is being re-generated)
• If you had a site picked to not invalidate result above:
  • At no point you see wordpress-seo files disappearing from the Cached tab (since Opcache doesn't get regenerated)
• Now add the add_filter( 'Yoast\WP\SEO\should_invalidate_opcache', '__return_false' ); filter on your site
  • Do an upgrade via the Test Helper and switch quickly to the tab where you have the op-cache gui open
  • No matter what result you had above, you never see wordpress-seo files disappearing from the Cached tab (since Opcache doesn't get regenerated)
• Now add the add_filter( 'Yoast\WP\SEO\should_invalidate_opcache', '__return_true' ); filter on your site
  • Do an upgrade via the Test Helper and switch quickly to the tab where you have the op-cache gui open
  • No matter what result you had above, at some point, you see no wordpress-seo files in that Cached tab (and then you get a lot of files again, as Opcache is being re-generated)

Extra steps for devs:

• My methodology to confirm that the calculation indeed picks the 10% of our users, is to run the following:

<?php

$site = 'http://test.local';
$success = 0;
for ($n=0; $n<10000; $n++) {
    $site++;
    if ( ( ( hexdec( substr( hash('sha256', $site ), 0, 8 ) ) ) % 10 ) !== 0 ) {
        $success++;
    }
}
echo $success;

• In there, I start from a random URL and check 10,000 cases of incremented URLs based on that. I expect to get a number close to 9000, which is the 90% of all the cases, which I do.
• Double check the methodology (or even propose a better one) and run the snippet a couple of times, with a different base URL each time

Relevant test scenarios

• Changes should be tested with the browser console open
• Changes should be tested on different posts/pages/taxonomies/custom post types/custom taxonomies
• Changes should be tested on different editors (Default Block/Gutenberg/Classic/Elementor/other)
• Changes should be tested on different browsers
• Changes should be tested on multisite

Test instructions for QA when the code is in the RC

• QA should use the same steps as above.

Impact check

This PR affects the following parts of the plugin, which may require extra testing:

• Introduce filter that disables opcache invalidation #22577 but our test instructions already regression test it.

Other environments

• This PR also affects Shopify. I have added a changelog entry starting with [shopify-seo], added test instructions for Shopify and attached the Shopify label to this PR.

Documentation

• I have written documentation for this change. For example, comments in the Relevant technical choices, comments in the code, documentation on Confluence / shared Google Drive / Yoast developer portal, or other.

Quality assurance

• I have tested this code to the best of my abilities.
• During testing, I had activated all plugins that Yoast SEO provides integrations for.
• I have added unit tests to verify the code works as intended.
• If any part of the code is behind a feature flag, my test instructions also cover cases where the feature flag is switched off.
• I have written this PR in accordance with my team's definition of done.
• I have checked that the base branch is correctly set.

Innovation

• No innovation project is applicable for this PR.
• This PR falls under an innovation project. I have attached the innovation label.
• I have added my hours to the WBSO document.

Fixes #

[coveralls]

Pull Request Test Coverage Report for Build cddcb27d9a5fe3a6c48ffa814228a7989a62f497

Warning: This coverage report may be inaccurate.

This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

• For more information on this, see Tracking coverage changes with pull request builds.
• To avoid this issue with future PRs, see these Recommended CI Configurations.
• For a quick fix, rebase this PR at GitHub. Your next report should be accurate.

Details

• 0 of 3 (0.0%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall first build on add/gradual-sunset-of-opcache-invalidation at 49.494%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
wp-seo-main.php	0	3	0.0%

Totals
Change from base Build c168df4a5c8d5eed7ce42a3ffd5ef7a0eace9d1d:	49.5%
Covered Lines:	17310
Relevant Lines:	34974

---

💛 - Coveralls

[thijsoo]

CR + ACC 👍 this makes sense for now :)