vip-go-mu-plugins Remove WPcom-specific rewrite rules flush logic

Overview

Removes duplicate WPcom-specific rewrite rules flushing logic that is no longer needed on VIP Go. This addresses the technical debt and issues identified in the original issue where the custom flush implementation was:

Duplicating work already done by the Rewrite Rules Inspector plugin
Causing inconsistent flush behavior
Calling problematic wpcom_vip_refresh_wp_rewrite() logic

Problem

The rri_wpcom_flush_rules() function was hooking into rri_flush_rules to perform custom flush logic that manually rebuilt and saved rewrite rules. However, this was redundant because:

The Rewrite Rules Inspector plugin already calls flush_rewrite_rules(false) which handles the entire flush process correctly
The custom logic was originally added for WP.com platform compatibility, but VIP Go uses standard WordPress rewrite rules handling
As noted in the issue comments, this could cause race conditions where frontend requests would interfere with admin flush requests, leading to incomplete rule regeneration

Changes

Removed from rewrite-rules-inspector.php:

rri_wpcom_flush_rules() function and its hook (37 lines)
Conditional call to wpcom_vip_refresh_wp_rewrite()
Manual rewrite rule rebuilding logic

Impact

✅ No breaking changes - Rewrite rules flushing continues to work via the standard WordPress mechanism already implemented in the plugin
✅ Cleaner codebase - Removes 37 lines of technical debt
✅ Better alignment with core - VIP Go now uses the same flush behavior as standard WordPress
✅ Existing VIP helper functions (wpcom_vip_load_permastruct(), wpcom_vip_load_category_base(), wpcom_vip_load_tag_base()) remain available and functional

The wpcom_vip_refresh_wp_rewrite() function is no longer called anywhere in the codebase, effectively becoming dead code that can be addressed in a future deprecation effort if needed.

Testing

All linting passes (phplint + phpcs)
Full PHPUnit test suite passes (1701 tests)
Verified no other code references the removed function

Fixes issues described in the original issue regarding duplicate flushes and inconsistent rewrite rule behavior.

[!WARNING]

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

downloads.wordpress.org

Triggering command: /usr/bin/php8.1 (dns block)

example.com

Triggering command: php -d apc.enable_cli=1 /home/circleci/project/vendor/bin/phpunit (dns block)

https://api.github.com/repos/Automattic/VIP-Coding-Standards/zipball/2b1d206d81b74ed999023cffd924f862ff2753c8

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/PHPCSStandards/PHPCSExtra/zipball/11d387c6642b6e4acaf0bd9bf5203b8cca1ec489

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/PHPCSStandards/PHPCSUtils/zipball/87b233b00daf83fb70f40c9a28692be017ea7c6c

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/PHPCSStandards/PHP_CodeSniffer/zipball/ad545ea9c1b7d270ce0fc9cbfb884161cd706119

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/PHPCSStandards/composer-installer/zipball/4be43904336affa5c2f70744a348312336afd0da

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/WordPress/WordPress-Coding-Standards/zipball/9333efcbff231f10dfd9c56bb7b65818b4733ca7

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/Yoast/PHPUnit-Polyfills/zipball/134921bfca9b02d8f374c48381451da1d98402f9

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/sebastianbergmann/resource-operations/zipball/05d5692a7993ecccd56a03e40cd7e5b09b1d404e

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/sebastianbergmann/version/zipball/c6c1022351a901512170118436c764e473f6de8c

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/sirbrillig/phpcs-variable-analysis/zipball/ca242a0b7309e0f9d1f73b236e04ecf4ca3248d0

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/symfony/finder/zipball/63741784cd7b9967975eec610b256eed3ede022b

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/wp-cli/mustache.php/zipball/ca23b97ac35fbe01c160549eb634396183d04a59

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/wp-cli/wp-cli/zipball/03d30d4138d12b4bffd8b507b82e56e129e0523f

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

https://api.github.com/repos/wp-phpunit/wp-phpunit/zipball/a33d328dab5a4a9ddf0c560bcadbabb58b5ee67f

Triggering command: /usr/bin/php8.3 -n -c /tmp/slxYYp /usr/bin/composer install --no-interaction (http block)

woocommerce.com

If you need me to access, download, or install something from one of these locations, you can either:

Configure Actions setup steps to set up my environment, which run before the firewall is enabled

Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

This section details on the original issue you should resolve

<issue_title>WPcom specific rewrite rules logic should be removed</issue_title> <issue_description>### 1) Flushing rewrite rules from wp-admin forces them to essentially flush twice.

This bit of code in rri_wpcom_flush_rules () should no longer be necessary and should be removed: https://github.com/Automattic/vip-go-mu-plugins/blob/master/rewrite-rules-inspector.php#L57-L69

The call to flush_rewrite_rules( false ); that the plugin makes before this hook is called is sufficient on VIP Go: https://github.com/Automattic/Rewrite-Rules-Inspector/blob/master/rewrite-rules-inspector.php#L282-L283

flush_rewrite_rules( false ); boils down to this (which you'll notice is essentially the same thing we duplicate in our addon plugin):

// In wp_rewrite->flush_rules()
update_option( 'rewrite_rules', '' );
$this->wp_rewrite_rules();

// In wp_rewrite->wp_rewrite_rules()
$this->rules = get_option('rewrite_rules');
if ( empty($this->rules) ) {
  $this->matches = 'matches';
  $this->rewrite_rules(); // Reconstructs rules from scratch. Remember this is what the plugin does to find missing rules.
  update_option('rewrite_rules', $this->rules);
}

2) Flushing rewrites can behave differently when a theme is using the older WPcom ways of declaring permalink structures.

If a site is using wpcom_vip_load_permastruct(), wpcom_vip_load_tag_base(), etc, then you'll see in the same function as above (rri_wpcom_flush_rules()) that it calls wpcom_vip_refresh_wp_rewrite().

It's in this function that I believe we have some error-some logic that might be causing some hard to catch bugs. This portion in particular feels like it should not be needed: https://github.com/Automattic/vip-go-mu-plugins/blob/da7fcd24b773e1957687c6eb56f0b56ddd402d9e/vip-helpers/vip-permastructs.php#L145-L158

I believe the $wp_rewrite->init(); might be interferring with things. Though I'm not 100% sure how this all works so a second opinion here would be very much appreciated.

</issue_description>

Comments on the Issue (you are @copilot in this section)

@mjangda > But I think long term this is just more technical debt and we should instead remove all this special handling and have it be just like core does.

This. Any special considerations that need to be made for WP.com migrations should happen via the compat plugin. mu-plugins should remain as close to core as possible.</comment_new> <comment_new>@WPprodigy

Also noting here that I've seen a few tickets where missing rewrite rules would not be added until I ran wp cache flush.</comment_new> <comment_new>@WPprodigy Ah, think I figured out some of what goes wrong here. The request to flush_rewrite_rules() is being interrupted by a second request (any frontend page view). Example:

Admin Request One: Empties out the rewrite_rules option here.
Secondary Visitor Request: WP runs parse_request very early and fetches rewrite_rules here. This then has to rebuild them since they are empty from step 1 above. But notably, the rri_flush_rules action is not triggered and it's possible this request isn't yet recognizing new rules from step 1.
Admin Request Two: Back in our first admin request, we hit this line but step 2 already re-populated the option so it doesn't bother re-building.

Ideally, core could have a "force flush" type option to prevent this type of issue I'm thinking.</comment_new> <comment_new>@WPprodigy

Found a bug with the wpcom_vip_refresh_wp_rewrite() logic.

If a site uses only wpcom_vip_load_category_base() for example, every flush via the plugin will result in permalink_base being reset to this: https://github.com/Automattic/vip-go-mu-plugins/blob/7bf6b099f7a1a218a9716b0dad93a66e388982ff/vip-helpers/vip-permastructs.php#L121

It seems to require an all-or-nothing approach to using those functions.</comment_new> <comment_new>@WPprodigy

Still in favor of deprecating/removing this extra bit of wpcom functionality. But we'll need an ideal system to switch to.

This seems fine:

add_action( 'init', function() {
	global $wp_rewrite;
	$wp_rewrite->set_category_base( 'category' );
	$wp_rewrite->set_tag_base( 'terms' );
} );

But is susceptible to the same problem we see with user roles - it's possible it triggers a stampede of FE writes should something go wrong/change. Could suggest th...

Fixes Automattic/vip-go-mu-plugins#1141

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

Oct 23 '25 23:10 Copilot

Codecov Report

:white_check_mark: All modified and coverable lines are covered by tests. :white_check_mark: Project coverage is 34.85%. Comparing base (18fe429) to head (4f7d431). :warning: Report is 1 commits behind head on develop.

Additional details and impacted files

@@              Coverage Diff              @@
##             develop    #6587      +/-   ##
=============================================
+ Coverage      34.84%   34.85%   +0.01%     
  Complexity      5029     5029              
=============================================
  Files            295      295              
  Lines          20746    20737       -9     
=============================================
  Hits            7228     7228              
+ Misses         13518    13509       -9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

:rocket: New features to boost your workflow:

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