Stop WP rewrite rules from matching files like wp-admin.css

[brandonpayton]

What is this PR doing?

This PR fixes a bug in our WordPress rewrite rules where plugin files named things like "wp-admin.css" were having their preceding plugin-specific path removed.

This was reported in WP.org Slack (#playground-logs):
https://wordpress.slack.com/archives/C06Q5DCKZ3L/p1713585476733489

How is the problem addressed?

This PR tweaks the pattern to only apply to directories. This fixes the problem of matching files but still leaves open the possibility of false positives when plugins or themes contain directories named /wp-admin/, /wp-includes/, etc.

Testing Instructions

• npm run dev
• Open local Playground with a blueprint that installs and activates the Material Board plugin
• Confirm that wp-admin dashboard is rendered cleanly without obvious styling issues

Without this fix, the appearence of the lefthand menu bar is obviously broken like:

[brandonpayton]

It would be nice to get the quick fix in for @fatihbalsoy who reported the issue, but perhaps we can make a follow-up PR to further reduce the chances of false-positives.

@bgrgicak, do we know more about the expected paths that prefix wp-admin, wp-content, and others that we could use to make this pattern not accidentally match similarly named directories in plugins and themes?

[adamziel]

Good fix @brandonpayton! Let's merge and deploy the site.

[bgrgicak]

@bgrgicak, do we know more about the expected paths that prefix wp-admin, wp-content, and others that we could use to make this pattern not accidentally match similarly named directories in plugins and themes?

Thanks for the fix! What you did makes sense, I just forgot to add the / and it in my testing it still worked.

[adamziel]

This fixes the problem of matching files but still leaves open the possibility of false positives when plugins or themes contain directories named /wp-admin/, /wp-includes/, etc

Would that also be a problem with a regular hosted WordPress?

[bgrgicak]

Would that also be a problem with a regular hosted WordPress?

I tested it on a new multisite and it worked, so this was just Playground bug.

[adamziel]

I didn't mean the thing this PR fixed. I meant what @brandonpayton mentioned about plugins containing /wp-admin/. If apache uses just the same regex as Playground, only shipped via .htaccess, it should have the same bug, right? In which case it's not ours to fix.

[brandonpayton]

This fixes the problem of matching files but still leaves open the possibility of false positives when plugins or themes contain directories named /wp-admin/, /wp-includes/, etc

I think I was wrong about there being further possibility of false positives for plugins and themes. Both will already be under the wp-content directory which is already matched by the pattern.

/^\/(.*?)(\/wp-(content|admin|includes)\/.*)/g

And the pattern has other aspects which should make it safer for nested directories:

• anchored to the beginning of the string
• is non-greedy with the preceding path: .*?
• ends with .* which consumes the rest of the string

I tested a bit with examples in the dev tools console, and it behaved well with paths like

/something/wp-content/plugins/any-plugin/wp-admin/stuff