You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Search Results for Tags Not Working as Expected with a Large Number of Tags #23978
When a site has a large number of tags (4,470+), certain tags do not appear in search results as expected. For example, while similar tags are displayed correctly, specific tags are missing from the results, even though they exist on the site. This issue seems to be related to the volume of tags rather than the tags themselves.
This was reported by a user in Zendesk: 9258078-zd-a8c
Mentioned in Slack as well: p1736530234720379-slack-C06NXHR5WQ1
This is likely fixed by the rebuilt tags list in #24668, #24670 and #24674. #24668 rewrote it specifically because not all tags were shown and search results were inaccurate on sites with many tags. It now uses the core REST tags endpoints (#24665).
To verify: on a site with hundreds of tags, search for a tag that is far down the list, in both the post tag picker and Site Settings > Tags.
Repro run (2026-10-30, trunk e64c851, iPhone 18 Pro simulator / iOS 27.0, Jetpack Debug)
Result: Fixed on trunk ✅. Recommend closing.
Steps (exact, minimal):
Post tag picker: on a local self-hosted site with 600 tags, open a post's Post Settings > Tags and search for tag-0587.
Site Settings > Tags: on a WordPress.com site with 4,641 tags, search for a tag about 4,600 places down the alphabetical list.
Expected / actual: As expected. Both searches found the tag. On the local site this was a server search: GET /wp-json/wp/v2/tags?context=view&per_page=100&search=tag-0587. On WordPress.com we saw the result but not the request. In the post tag picker the list also loaded pages 1 to 6 while scrolling, which covers all 600 tags.
Differences from the plan:
We read an existing WordPress.com site rather than seeding one, because this run can't write to WordPress.com. Its name and tag aren't given here because it's an internal site.
Site Settings > Tags only appears for admins on sites using the WordPress.com API, so it wasn't tested on the local site.
We didn't try the post tag picker on WordPress.com, or scroll through all 4,641 tags in Site Settings. Both screens build the same TagsViewModel.tags(for:) (from the code).
Evidence: the local site's access log and the app's accessibility tree.
Activity
dangermattic commentedon Jan 14, 2025
Thanks for reporting! 👍
jkmassel commentedon Oct 31, 2026
This is likely fixed by the rebuilt tags list in #24668, #24670 and #24674. #24668 rewrote it specifically because not all tags were shown and search results were inaccurate on sites with many tags. It now uses the core REST tags endpoints (#24665).
To verify: on a site with hundreds of tags, search for a tag that is far down the list, in both the post tag picker and Site Settings > Tags.
Generated by Claude Code
jkmassel commentedon Oct 31, 2026
Simulator test plan. Sign in using
docs/simulator-sign-in.md. Build from currenttrunk.Setup: WordPress.com token, and a test site seeded with 500 or more tags through the REST API, for example
tag-0001totag-0600.tag-0587.Pass: the tag is found in both places, and the full list scrolls through every tag.
Generated by Claude Code
jkmassel commentedon Oct 31, 2026
Repro run (2026-10-30, trunk e64c851, iPhone 18 Pro simulator / iOS 27.0, Jetpack Debug)
Result: Fixed on trunk ✅. Recommend closing.
Steps (exact, minimal):
tag-0587.Expected / actual: As expected. Both searches found the tag. On the local site this was a server search:
GET /wp-json/wp/v2/tags?context=view&per_page=100&search=tag-0587. On WordPress.com we saw the result but not the request. In the post tag picker the list also loaded pages 1 to 6 while scrolling, which covers all 600 tags.Differences from the plan:
TagsViewModel.tags(for:)(from the code).Evidence: the local site's access log and the app's accessibility tree.
Generated by Claude Code