Site Search

introduction site search is an include you can add to your pages to enable users to search pages, webapp items, and module items for terms they're looking for by default, this will now search slugs, metadata and page content site search now has more configuration options to make searching your site more powerful this document will cover the new toolbox options for setting up a site search there are two parts of site search which you'll need to include in a site search input search results both are available in toolbox and it is up to you whether you put them on the same page or different pages including the search input {% include 'site search input' search placeholder 'search' result page url 'search results' %} parameters search placeholder default is search placeholder value that displays in the input field result page url this lets you define the relative url of the page where the search results are included this can be the current page url (default 'search results') search input class class on input field input id id on input field (default 'site search field') button id id of the button you want to control submission (default 'site search submit') using multiple site search forms on the same page if you're using a button to submit your input form and there are multiple input forms within the same page there are a couple of attributes you'll need to ensure are added you'll need to add the button id parameter to the include for search input and this must be unique for each search form {% include 'site search input' search placeholder 'search' result page url 'search results' button id 'id 1' %} then add an id to the button that submits your input, please match this to the id within the button id parameter, for example \<button class="btn site search submit" id="id 1">submit\</button> including the search results {% include 'site search results' layout 'default' per page '20' %} parameters per page default is 20 defines the number of items outputted on the page layout default is default defines the layout file used to display the results {{ all results | size}} can be used in the wrapper layout, and this will return the number of total results more parameters search by type when selecting "site search results" from the toolbox, you have the option of selecting which type of content will be contained within the results here you can mix and match whether you would like to display results from pages, webapp detail pages or module detail pages for example if you only want to search for pages on the website then you could have the results exclude any data from webapps and modules to get results from webapps or modules, you must turn on detail pages in their configuration in admin webapps if you select webapps as a type, you then get a further configuration option to select which webapps to search the webapps dropdown will display all of the available webapps, this allows you to either select one or multiple webapps to show results from if you leave this field empty them the search will show results all webapps on your site more parameters allow webapp items without detail pages sometimes you may want to show results from webapps without detail pages perhaps the relevant information is shown in a table instead? you can add the parameter allow list items 'true' and webapp items without detail pages will also show in the results we strongly recommend that if you use this parameter, you also update your site search results layout so that it hides links to the detail page if one does not exist you can use the following liquid if statement to achieve this {% if this detail view == 'true' %} details {% endif %} custom results layouts by default, results will appear in a list you can change the way they display with a custom layout layout files site search module layouts are stored in the following folder structure, which you can view via code editor layouts/modules/site search/ within this module folder you will find the following layout folders results/ the results layout folder design system/ default design system layouts folder item liquid items displayed within the results wrapper wrapper liquid wrapper of the list displayed using the results to create a custom layout, right click on the results folder and write a folder, followed by the two required files (item & wrapper) for example, type custom layout 1/wrapper liquid to create a folder called "custom layout 1" that contains a file called "wrapper" right click on your "custom layout 1" folder to create the final item liquid file handling liquid output pages, webapp items and module items may all output different liquid this is because they are different sorts of database objects if your search covers more than one type, you may wish to only use output fields which are available to all those types, or you could use if statements to show one field or the other depending on which is available for example, if you have a search results layout and you want to display the seo meta title for pages and webapps, you can use logic to show whichever one is actually available {% if this metadata title %} {{this metadata title}} {% elsif this properties meta title %} {{this properties meta title}} {% endif %} you can also use the default filter \<p>{{this metadata title | default this properties meta title }}\</p> page results liquid reference the following output is available for pages {{this id}} id of the page {{this name}} page name from admin {{this slug}} unique section of relative url marked by forward slashes {{this redirect to}} siteglide cli only {{this full slug}} url {{this content}} page content this will include liquid in its un rendered state rendering liquid from search results is blocked to securely avoid injection attacks this field is most likely to be used only in a filtered form, or as part of a logical operation {{this metadata id}} {{this metadata name}} {{this metadata enabled}} {{this metadata file type}} in most cases this will show as page {{this metadata last edit}} {{this metadata meta desc}} {{this metadata meta title}} webapp results liquid reference this will depend on the webapp use liquid dot notation to see the results for your webapps here is an example of a typical webapp {{this id}} id of the webapp item {{this name}} name of webapp item {{this model}} shows that this is a webapp item and the id of the webapp {{this full slug}} url for webapp detail page {{this properties name}} {{this properties slug}} the webapp item's unique url slug without the preceding url slug which precedes all detail pages for this webapp {{this properties enabled}} {{this properties release date}} {{this properties expiry date}} {{this properties og type}} {{this properties og title}} {{this properties meta desc}} {{this properties meta title}} {{this properties weighting}} {{this properties twitter type}} {{this properties category array}} array of ids for categories assigned to this item {{this properties webapp field 1 1}} custom fields where the first number is the id of the webapp and the second number the id of the field the ids are integers given to webapps and fields in the order they are created you can work this out by looking at the list of fields in the webapp's admin view module results liquid reference this will depend on the module use liquid dot notation to see the results for your modules here is an example of a typical module {{this id}} id of the module item {{this name}} name of module item {{this full slug}} url for module detail page {{this model}} shows that this is a module item and the id of the module {{this properties name}} {{this properties slug}} the module item's unique url slug without the preceding url slug which precedes all detail pages for this module {{this properties enabled}} {{this properties release date}} {{this properties expiry date}} {{this properties og type}} {{this properties og title}} {{this properties meta desc}} {{this properties meta title}} {{this properties weighting}} {{this properties category array}} array of ids for categories assigned to this item {{this properties twitter type}} seo twitter type {{this properties module field 1 1}} custom fields where the first number is the id of the module and the second number the id of the field the module ids are fixed for all sites, for example, the blog module always has the id of 3 outputting the search keyword you can output the value of any url parameter using platformos's context params object, including the search term in the "keyword" parameter \<p>search results for {{context params keyword}}\</p> platformos automatically sanitize https //documentation platformos com/api reference/liquid/sanitization tag output to escape any malicious input using the cross site scripting technique related documents searching keyword searching advanced filtering