Fix array encoding for custom taxonomies and use term IDs for resolution#4
Open
Fix array encoding for custom taxonomies and use term IDs for resolution#4
Conversation
- Add wp_urlencode helper in Python to properly format nested arrays/dicts for WordPress APIs, fixing issue #2. - Update agent documentation (CLAUDE.md, AGENTS.md, agents/apply.md) to mandate the use of wp_urlencode. - Switch from using slugs to term_ids as the canonical identifier in exports, analysis, and applying changes to prevent taxonomy drift.
silverstein
added a commit
to silverstein/taxonomist
that referenced
this pull request
Apr 2, 2026
Implements a tested adapter for the WordPress.com / Jetpack REST API at lib/adapters/wpcom_adapter.py, matching the WpCliAdapter interface. Specific defenses against documented bugs: - #1: delete_category() accepts only int term_id, resolves slug from live data before deleting. Raises TypeError on string input. - m#2: wp_urlencode() uses doseq=True so list values produce repeated keys instead of being stringified. - m#3: update_category() always includes parent in the payload and verifies term count before/after to detect silent duplicates. - m#4: wp_urlencode() used consistently for all request encoding. 23 unit tests with mocked HTTP covering pagination, error handling, cache invalidation, and all four issue defenses. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This was referenced Apr 2, 2026
jeherve
added a commit
to jeherve/taxonomist
that referenced
this pull request
Apr 6, 2026
The wp_urlencode helper landed in m#4 without any tests, which left the issue #2 regression unprotected and the nested-list-of-dicts follow-up in 3bcd2d8 unverified. I added coverage for: - the exact issue #2 input (nested dict with a list value) - bracket URL-encoding (%5B / %5D vs literal [ ]) - nested lists of dicts, the 3bcd2d8 case - empty list, empty dict, empty input, None, bool, int, and special characters - a regression class that asserts the broken Python-repr form never comes back, and that a naive urlencode still demonstrates the original bug
This was referenced Apr 6, 2026
3 tasks
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
2 participants
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.
Resolves #2
What changed:
The issue was caused by Python's
urllib.parse.urlencodestringifying lists in nested dictionaries (e.g.,terms[kb_category][]), which caused WordPress to interpret the payload as a single literal string instead of an array of parameters.To fix this:
wp_urlencodehelper inlib/helpers.pythat properly flattens nested dictionaries and lists into the exact query parameter format expected by WordPress and PHP (e.g.,key[subkey][]=val).agents/apply.md,CLAUDE.md, andAGENTS.md) to mandate the use ofwp_urlencodewhen building queries for the WordPress.com API, preventing this bug from reoccurring.slugtoterm_idto prevent taxonomy drift across the entire analysis lifecycle.