[Frontend] Add a wiki search box and fix inconsistent, silently-truncating sidebar pagination #396
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Impact: MEDIUM
Found in the August 2026 session lifecycle review (#319).
What the user experiences
There is no search box anywhere in the wiki — the only way to find an entry is to browse the category tree by hand. Worse, the sidebar that provides that browse tree is implemented twice, and the two implementations disagree:
CampaignStoryline's sidebar paginates properly ("Load more (X of Y)"), whileWikiArticle's sidebar uses an unpaginated fetch that silently truncates at the backend's default page size of 200. A campaign with more than 200 wiki entries will see an incomplete category tree fromWikiArticlewith no indication that entries are missing.Evidence
searchinwebapp/frontend/src/pages/CampaignStoryline.jsxandwebapp/frontend/src/pages/WikiArticle.jsxreturns no results — there is no search box anywhere in the wiki.webapp/frontend/src/pages/CampaignStoryline.jsx:136,170-183— paginates the sidebar with "Load more (X of Y)".webapp/frontend/src/pages/WikiArticle.jsx:1331— uses the unpaginatedfetchLoreEntries, silently truncating at the backend default of 200 (webapp/frontend/src/api/campaigns.js:170).Why it matters for a hosted product
A campaign that grows past 200 wiki entries — plausible for a long-running hosted game — silently loses part of its own category tree on one of two pages showing the same data, with nothing telling the GM that entries are missing.
Proposed fix
Add a search box to the wiki, covering entry titles at minimum. Unify
WikiArticle's sidebar to use the same paginatedfetchLoreEntriescallCampaignStorylinealready uses correctly, so the two pages show a consistent, complete category tree regardless of entry count. This is the audit's P24 and the sidebar-pagination finding from §9.6.Acceptance criteria
WikiArticle's sidebar uses the same paginated fetchCampaignStorylineuses, so both show the same complete entry list regardless of campaign size.Picking this up as v4.3.0 phase 6 (#514), last on the wiki lane. A search box reachable from the wiki home and the article sidebar (titles at minimum, via a small additive query parameter on the list endpoint if the backend has none), and the article sidebar moves onto the same paginated fetch the wiki home uses, so a campaign past 200 entries sees all of them on both pages.
Done in PR #527 (auto-merging on green); ships with v4.3.0.
No backend change was needed. The plan offered a
qparameter as a fallback if the list endpoint had no search; it already has?search=, implemented inlore_service.list_lore_entries, covering title, body, aliases and the viewer-visible structured fields, with existing tests. Addingqwould have been a second name for the same behaviour, so the search is a pure frontend addition.New
WikiSearchcomponent: debounced 200 ms, two-character minimum, server-side (a client-side filter could only ever find what the rail had already loaded, and the backend's search reaches the body and aliases too). One box per page, where that page navigates from: the main column on the wiki home, so it is reachable belowmd, and the rail on the article page, which has no other nav surface.WikiArticle's rail was on the unpaginatedfetchLoreEntries, capped at 200, so a long-running campaign's rail simply ended with nothing saying so. It now uses the same paginated fetch and "Load more (X of Y)" as the wiki home, which also widens the entry set behind[[wiki links]]and the relationship picker.Results are titles only: an entry-type chip would have been a fourth copy of the
TYPE_LABELSmap that already lives inWikiArticle,CampaignStoryline,WikiProposalsandCampaignDetail. Extracting that taxonomy into one module is a sensible small follow-up for the release-readiness pass.7 new tests; the lane's frontend suite ends at 616 passed.