Resolve change-log revert by category slug, not display name#39
Merged
Conversation
The wpcom change log stored category identities as display names joined with '|', and inverse-replay resolved them back via the first name match. Two real-world failures fell out of this: - WordPress allows two categories to share a display name under different slugs. Reverting picked whichever same-named category was first in the cache, silently reassigning the post to the wrong one — on the undo path. - A category name containing '|' (e.g. 'Tips | Tricks') was split into phantom names on revert, 404ing and producing a partial restore. Display names are also a poor revert key because a category deleted by the apply run and recreated during restore keeps its slug but gets a new term ID, so neither the name nor the original ID is reliable — the slug is. Add old_category_slugs / new_category_slugs columns to the change log and resolve the SET_CATS inverse by slug (via _lookup_category_by_slug), with a name-based fallback for logs written before the columns existed or by the WP-CLI script. Update the AGENTS.md schema and parse_change_log docs. Add regression tests for duplicate names and '|'-in-name reverts.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The wpcom change log stored category identities as display names joined with
|, and inverse-replay resolved them back via the first name match. Two real-world failures fell out of that.WordPress allows two categories to share a display name under different slugs. Reverting picked whichever same-named category was first in the cache, silently reassigning the post to the wrong one, on the undo path.
A category name containing
|(e.g.Tips | Tricks) was split into phantom names on revert, 404ing and producing a partial restore.Display names are also a poor revert key because a category deleted by the apply run and recreated during restore keeps its slug but gets a new term ID, so the slug is the only identifier that stays stable across a restore.
This adds
old_category_slugs/new_category_slugscolumns to the change log and resolves theSET_CATSinverse by slug, with a name-based fallback for logs written before the columns existed (or by the WP-CLI script). I updated the AGENTS.md schema and theparse_change_logdocs, and added regression tests for the duplicate-name and|-in-name reverts.I also confirmed it against a live Jetpack site: with two categories sharing the name "ZZ WP Dup" under different slugs, a logged change plus an inverse-replay restore put the post back on the exact original category by slug, not the same-named one.
Testing
python3 -m unittest discover tests— greenruff check lib/ tests/— clean