Repository navigation
com_kb: search in the header, categories on the home page, snippets in results (supersedes #1932) - #1939
Merged
Conversation
…user interface change
…n results Rework of the previous commit, which carried the core half of ticket 2814 as a controller tweak plus two template strings while the actual UI lived in a PURR template override. The generic parts of that override belong in core, where every hub gets them and they stop drifting from core's views: - The search box moves into the page header on both the home and the category view (com_blog and com_answers already use that region), via one _search partial. It keeps the current sort. - The category sidebar becomes a _categories partial used by both views, so the home page gets category navigation beside its existing category grid. Its links, and the sort links, carry the search term, so narrowing or re-sorting does not drop a search. - Searching shows a highlighted excerpt under each result. Article::snippet() strips field wrappers and markup, finds the phrase or else its earliest word, cuts on word boundaries, escapes, and wraps the matches in <mark>. A "Results for ..." line offers to clear the search. - The home view's help links (Answers, Wishlist, Support) move to a _help partial, so a template that routes help elsewhere overrides that one small file instead of the whole view. - Category::link() falls back to the alias when there is no stored path. The synthetic "all" category has none, so core's own sort links on /kb/all carried an empty section and routed to the wrong task. The controller builds that category in one allCategory() helper and gives the home view the same category/catid/filters contract as the category view. - The two "Contact" strings go back to the template that uses them. Tests cover snippet(): phrase and word matching, case, wrapper and tag stripping, cutting, escaping of the term, and the link fallback.
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.
Supersedes #1932 (ticket 2814), carrying its commit and adding the rework on top.
Why the split changed. The PR put a controller tweak and two template strings into core while the real UI change sat in a PURR template override on GitLab (
tpl_doi, branchkuang_local_branch_doi_template_10022026). Most of that override is generic: a search box in the page header, category navigation on the home page, sort and category links that keep the search term, and highlighted snippets in search results. Those now live in core, so every hub gets them and the override stops drifting from core's views (the override had already lost the April accessibility fixes). What is PURR's alone, a contact-page link in place of the Answers/Wishlist/Support blocks and the sidebar-on-the-left layout, stays in the template:tpl_doibranchkb-core-viewsdrops the full-view overrides and keeps a_help.phppartial, akb.cssoverride and two strings. Deploy the two together.What this adds to core
_searchpartial in the page header on both views (the region com_blog and com_answers already use), keeping the current sort._categoriespartial shared by both views; its links and the sort links carry the search term.Article::snippet()with a highlighted excerpt under each search result and a "Results for …" line with a clear link._helppartial for the home view's help links, so a template overrides one small file.Category::link()falls back to the alias when there is no path: the synthetic "all" category has none, so core's own sort links on/kb/allcarried an empty section and routed to the wrong task. The controller builds that category once (allCategory()) and gives the home view the same category/catid/filters contract as the category view.Verified with the doi overrides set aside on this hub:
/kb,/kb/all, a real category, and searches on both show the header search box, the category sidebar, highlighted snippets, a results line, and sort/category links that keep the search term, with no PHP diagnostics.ArticleSnippetTest(9 cases, including the link fallback) passes; lint clean.🤖 Generated with Claude Code