Skip to content

Rewrite Rules: Fix rewrite rules breaking for taxonomies with URL-encoded Unicode slugs - #12863

Open
SainathPoojary wants to merge 2 commits into
WordPress:trunkfrom
SainathPoojary:fix/41791
Open

Rewrite Rules: Fix rewrite rules breaking for taxonomies with URL-encoded Unicode slugs#12863
SainathPoojary wants to merge 2 commits into
WordPress:trunkfrom
SainathPoojary:fix/41791

Conversation

@SainathPoojary

@SainathPoojary SainathPoojary commented Aug 5, 2026

Copy link
Copy Markdown

This PR intercepts the permastruct inside WP_Rewrite::add_permastruct() and decodes the URL-encoded slug back into standard UTF-8 text before saving it.
To ensure we don't accidentally corrupt real rewrite tags (where %ca in %category% could be decoded by a naive urldecode), we use a preg_replace_callback that strictly decodes only uppercase hex strings ([0-9A-F]). WordPress's URL encoding always uses uppercase, while built-in rewrite tags use lowercase, making this a safe and robust fix.

Trac ticket: #41791

Use of AI Tools

AI assistance: Yes
Tool(s): GitHub Copilot
Model(s): Gemini, Claude
Used for: Checking for potential edge cases, drafting the PR description, and assisting with local code review. The final implementation and testing were written and executed manually by me.


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

@github-actions

github-actions Bot commented Aug 5, 2026

Copy link
Copy Markdown

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

@SainathPoojary
SainathPoojary marked this pull request as ready for review August 8, 2026 12:27
@github-actions

github-actions Bot commented Aug 8, 2026

Copy link
Copy Markdown

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props sainathpoojary.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@irozum irozum left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Solid fix for a real 9-year-old bug: taxonomies/post types registered with a percent-encoded Unicode slug (WooCommerce does this for cyrillic attribute names) end up with literal %D0%A1... bytes in the permastruct, which generate_rewrite_rules() misreads as tag delimiters, shifting every $matches[n] capture. Decoding in add_permastruct() is the right choke point since it's the single entry for taxonomies, post types, and any plugin's own call, matching the reporter's original diagnosis. It's also a nice improvement over the old 2016 patch on the ticket, which called plain urldecode() — that would convert literal + in a slug into a space; rawurldecode() avoids that, and scoping the regex to uppercase hex avoids colliding with any lowercase built-in tag like %category%.

Checked out the branch and ran the full rewrite group (1388 tests, no regressions) plus lint/PHPStan on the two changed files, all clean. The new test correctly asserts both the decoded struct and that the generated rule maps to $matches[1] rather than a shifted index — the exact symptom from the ticket's screenshots.

Non-blocking: a plugin-registered tag whose name happens to be 2+ uppercase hex letters (e.g. a hypothetical %AB%) would now get silently decoded instead of matched — no core tag is shaped that way, but requiring the decoded bytes to be valid UTF-8 before substituting would close that edge case if anyone wants extra safety.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants