-
Notifications
You must be signed in to change notification settings - Fork 8.2k
pagefind v1.5.0 #24092
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pagefind v1.5.0 #24092
Conversation
dvdksn
commented
Feb 6, 2026
- agents: add fetch toolset to docs_engineer agent
- site: upgrade pagefind to v1.5.0-beta.1
- site: remove /search page, redirect to homepage
- site: implement pagefind component ui for search modal
- site: add pagefind metadata for improved search ranking
Signed-off-by: David Karlsson <35727626+dvdksn@users.noreply.github.com>
Assisted-By: cagent
The search functionality is now handled entirely by the modal. Assisted-By: cagent
✅ Deploy Preview for docsdocker ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
- Add pagefind-component-ui.css and .js assets - Replace search bar with custom button that opens modal - Add custom result template with Tailwind classes - Add dark mode styling for modal and result highlights - Support Cmd/Ctrl+K keyboard shortcut Assisted-By: cagent
Index description, keywords, and breadcrumbs as Pagefind metadata to improve search result relevance. Configure ranking weights to prioritize title matches and reduce term frequency bias. - Add pagefind-meta.html partial for centralized metadata - Move breadcrumb metadata from breadcrumbs.html to new partial - Configure metaWeights: title (10x), keywords (6x), description (4x) Assisted-By: cagent
42f7ba2 to
77645c2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Summary
Reviewed the pagefind v1.5.0 upgrade. The implementation looks solid overall. I found a few areas where code comments could be more explanatory, particularly around the WHY behind certain technical requirements. These are minor improvements that would enhance maintainability.
Found 3 opportunities for improvement:
- Code comments could be more specific about the reasoning behind technical requirements
- Inline comments should explain WHY, not just WHAT (per documentation standards)
These are suggestions to enhance clarity and maintainability. The code itself appears functional and well-structured.
| let leftPos = rect.left; | ||
| <script type="module"> | ||
| // Configure Pagefind before any components connect to DOM | ||
| await import('/pagefind/pagefind-component-ui.js'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Code comment could be more specific
The comment "Configure Pagefind before any components connect to DOM" is somewhat vague about what "components" means and why this order matters.
Per documentation standards, code comments should explain the WHY, not just WHAT. Consider clarifying:
| await import('/pagefind/pagefind-component-ui.js'); | |
| // Configure Pagefind instance before creating modal elements to ensure proper initialization of component UI |
This helps future maintainers understand the technical requirement.
| index: index + 1, | ||
| })); | ||
| const title = document.createElement('p'); | ||
| title.className = 'font-medium'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment could explain the purpose more clearly
The comment "Show/hide placeholder based on search state" describes WHAT the code does but not WHY this is necessary.
Per documentation standards emphasizing clarity and purpose, consider adding context:
| title.className = 'font-medium'; | |
| // Show/hide placeholder text based on search state to provide user feedback when search results are available |
This clarifies the user experience goal behind the logic.
| @@ -0,0 +1,10 @@ | |||
| {{/* Pagefind metadata - must be inside data-pagefind-body */}} | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hugo comment could be more specific about the technical requirement
The comment "must be inside data-pagefind-body" explains the constraint but not the reason behind it.
Per documentation standards for complete explanations, consider clarifying:
| {{/* Pagefind metadata - must be inside data-pagefind-body */}} | |
| {{/* Pagefind metadata - must be placed inside data-pagefind-body attribute so pagefind indexer includes it during build */}} |
This helps developers understand both the constraint and its purpose.
usha-mandya
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM