Webvanta includes a built-in search engine that indexes your site's content to provide high-quality search results.
You can configure which item types are included in the search, whether static pages are searched, and to which pages the search results link. You can also modify the search results page just like any other page.
Because site search uses a precomputed index, searches are fast, even when searching a lot of content. The search index is updated about every 10 minutes, so there is a small delay between when you change content or settings and when the results reflect those changes.
Site search uses a single search field. If you want a search form that is broken out into multiple fields, then you need to use advanced search, which performs a direct database query on a specific item type, rather than using the search index.
All database content can be searched. By default, all custom databases are marked "Private" and you must uncheck that checkbox in each custom item type you want the system to index for search. The "Private" checkbox is found in the specific custom item type's definition.
All text-oriented fields are searched, including name, body, excerpt, as well as any custom fields of type Text Field, Text Area, WYSIWYG Text Area, and Code Text Area. Taxonomy terms are also searched. Related items are searched by name only. The names of related assets are not searched.
You can also choose to search static page contents (i.e., content that is in a template or in an editable region of a page), as described later in this article.
The basic code to display a search box is as follows:
<form action="/search" id="searchbox" method="post"> <div> <input id="search_text" name="search_text" type="text" /> <input type="submit" value="search" alt="Search" /> </div> </form>
You may want to change the search button to an image-based button, and you will probably want to add classes and corresponding CSS styles to refine the visual appearance of the search box.
The search results are typically displayed on a page that has the slug of "search_results". (Note: you might expect the search results page to have the slug "search", based on the
action="/search" attribute for the search form. Due to the way the back-end processing works, however, these two values are different. The "magic" slug of "/search" triggers the search logic, which then loads the page /search_results to display the results.)
Advanced feature: If you want to have multiple search results pages, invoked by different search forms, you can specify the slug for the search results page by adding a hidden field to the search form, called "search_results", and giving it the value of the search results page path (e.g. "/mysearchresults"). Also see Setting Up Advanced Search.
At its most basic, the search results can all be displayed on a single page:
<w:kb:item search="true"> <h1>Search Results for "<w:search_query />" (<w:search_total_found />)</h1> <ul> <w:each search="true"> <li> <a href='<w:path url="default"/>'><w:name /></a><br /> <p><w:description /></p> </li> </w:each> </ul> </w:kb:item>
This code uses the standard item iterator, with the search option that causes it to display the search results. (We show the unpaginated version here to start with the simplest example, but you should generally use the paginated version described below.)
Note that this code uses two special bits of WebvantaScript that provide access to information about the results:
|<w:search_query />||Displays the search text entered|
|<w:search_total_found />)||Displays the number of results|
Also, the attribute
search = "true" on the iterator is essential.
You do not have to use a form submission to link to the search results page; you can simply add a URL parameter, with the name "q" and the value set to the search terms, to a link. For example, if the search results page has the slug "search_results", this link will display all search results for "cats":
<a href="/search_results?q=cats">Search for Cats</a>
The example above is acceptable if your site's database is small (a few dozen items) and you don't expect it to grow. But if you have, or expect to have, 50 or more items, you should include pagination for the search results. (The unpaginated list will be slow to generate if you have more than a few dozen results, and it will be truncated at 200 results.)
Here's an example of a search results page with pagination:
<w:kb:item:paginate search="true" page="auto" limit="25" sort="updated_at DESC"> <h1>Search Results for "<w:search_query />" (<w:search_total_found />)</h1> <w:pagination_widget /> <ul> <w:each> <li> (<w:type_label />, <w:updated_at format="%b %e, %Y" />) <a href='<w:path url="default"/>' target='_blank'><w:name /></a><br /> <p><w:description format="strip_tags" truncate='120' /></p> </li> </w:each> </ul> <w:pagination_widget /> </w:kb:item:paginate>
A few notes on the code here:
The search results page links each item in the results to an item page that is appropriate for that item. For example, articles may be displayed on one item page, while project profiles are displayed on another.
You determine which pages are used for each type through the following settings:
The search function as described above will search only content that is stored in a structured database item, rather than in a page region or template. Often, this gives the best result, because each search result links to an item page that has all the detail for the found item. This approach avoids showing lots of results for pages that may include the search terms, but are not the core content for that term.
You can also enable full searching of static page content as well. To do so, you must create a Global Setting named
admin.search.enable_page_indexing , and set its value to
If you make no changes to the search results display code, it will display results for static pages and database content.
When displaying search results, you may want to distinguish between pages and database items. You can do so testing for the type being
<w:if_item type="webvanta_page_type"> Page: <a href='<w:path url="default"/>' target='_blank'><w:name /></a> </w:if_item> <w:unless_item type="webvanta_page_type"> <a href='<w:path url="default"/>' target='_blank'><w:name /></a><br /> <p><w:description format="strip_tags" truncate='120' /></p> </w:unless_item>
Note that while search results for database items will point to the item page, search results for pages will, of course, point to that page.
To avoid having multiple results for a single database item, only "normal" pages are included in the static page searching. Specifically, this excludes pages of type category, list, and item. Those pages primarily present database content, so you wouldn't normally want them to be indexed as static pages. If, however, you have some static content on those pages in addition to the database-driven content, be aware that this content will not be searched.
There is not currently any mechanism to exclude certain static pages from the search. For now, this is an all-or-nothing feature.
Any pages that require login to view (such as member-only pages) are not indexed. In the future, we plan to support search of static pages on member-only content.
Static pages are indexed when they are rendered. So if you have created a page but never viewed it, it will not be in the index. Simply view the page to begin the indexing process.
When a page is deleted, it will remain in the search index until the next update of the index (typically every 10 minutes), so it is possible for there to be broken links in the search results for brief periods. Similarly, if a page is modified, the search index will reflect the old version of the page until the next update of the index.