For multi-site or Site Factory use cases, consider sharing Search apps among multiple Drupal sites to reduce Search App management overhead. The strategy for deploying search pages influences the outcome, as there are trade-offs between using Drupal Views and SearchStax UI Kits. Both approaches depend on indexing the site_hash from the Drupal database for each site. In both cases, when a user searches on site A, the site_hash filter automatically restricts Solr results to documents indexed from site A, even though all sites use the same Search app.
The details for each approach are as follows:
UI Kits
Ideal use case
For websites aimed at enhancing the end user's search experience and business performance, consider adding additional search features and tuning search relevancy for each site.
Implementation method
Index the field for site_hash from the Drupal database.
Use SearchStax JavaScript components to deploy and style a search page on each site.
Create a search profile for each website with a Data Filter to include only results where the site_hash field matches the corresponding website's hash value.
Update the search input component to specify which model or search profile to use for returning relevancy.
Benefits
Additional features, such as faceting, spell check, and related searches, can be easily enabled and added to the search pages.
It is possible to tune advanced relevancy configurations for each website separately through a search profile without additional code changes.
All search pages interact directly with SearchStax APIs, reducing extra load on Drupal servers.
You can leverage SearchStax features that do not further contribute to the Monthly Search Request quota usage of your Search Plan, such as SearchStax Auto-Suggest or SearchStax Facets.
Drawbacks
Pages require additional development effort to add and style JavaScript and to specify the Search Profile to call in Search API requests.
Drupal Views
Ideal use case
For websites with common and simple search requirements and no foreseeable business need to enhance the user's search experience.
Implementation method
Index the field for site_hash from the Drupal database.
Add a filter in your Drupal View for site_hash.
Benefits
Capability to continue using existing Drupal Views.
Drawbacks
Arguments cannot be passed to specify a particular Search Profile, or model, within a Search App, meaning relevancy cannot be defined differently across sites.
There is an inability to leverage SearchStax Search Page features such as spell check, related searches, and popular searches.
Queries from the search input or facets continues to generate additional queries to fully return expected results to the end user.
Similar to sharing Search apps across sites in a multisite or Site Factory use case, multiple sites can be connected to index their content into a single Search App to create a unified search experience. This setup enables end users to find content from multiple sites with ease.
This can be implemented by following this process:
Create a unique identifier for each site.
Index the unique identifier across all sites involved in the search experience.
Use the unique identifier field to create a facet.
Assign a label such as Website or Content Source to the facet.
Enable users to filter results based on each site's unique identity.
Note
This implementation employs SearchStax Facets, which are available only when utilizing a UI Kit or invoking the Search API through a custom UI. Drupal Views overrides this capability.
Improving users' ability to easily find content can be achieved by implementing an Auto-Suggest or Auto-Complete feature. The following is a comparison between the Drupal Autocomplete module and the SearchStax Auto-Suggest feature.
Drupal Auto-Complete
Implementation method
Use a Drupal View for your search pages.
Install and configure the Drupal Auto-Complete module.
Benefits
Does not require a warm-up period.
Drawbacks
Does not provide feedback from actual user searches and surfaces search suggestions solely based on indexed content.
The Drupal Autocomplete interacts with the Search API and is considered a search request. Each character keystroke entered by the end user may trigger an additional search query against the Search API, potentially impacting the Monthly Search Requests limit of your search plan.
SearchStax Auto-Suggest
Implementation method
Use a UI Kit for your site’s search page.
Access the Search App your site connects to in the SearchStax dashboard.
Click the Optimizations dropdown in the left-hand navigation and select the Auto-Suggest tab.
Click Enable Auto-Suggest.
Select Data-Driven, Dictionary-Driven, or Data+Dictionary-Driven to determine how Auto-Suggest generates suggestions.
Upload a dictionary if you select the Dictionary-Driven or Data+Dictionary-Driven option.
Benefits
Provides autonomous and continuous improvement to suggestions based on user searches over time, with a flexible interface for manually adding additional suggestions.
Suggestions do not contribute to the Monthly Search Requests limit of your search plan.
Drawbacks
The Data-Driven suggestion method requires search analytics data to warm up.
You can configure the SearchStax Auto-Suggest feature and bypass the warm-up period by downloading the title field for all indexed content from the Drupal database. Convert this data into a .TXT file and upload it in the SearchStax dashboard. File limits are 10MB, with a maximum of 35,000 entries in the dictionary per Search App.
Note
The Data-Driven and Data+Dictionary-Driven suggestion methods are available only in the Premier and Premier Plus search plans, which include Search Analytics tracking.
To include content from outside Drupal sites in search results, post documents to the Search app using the Ingest API. For sample commands and details on supported file types, visit this page.
Web Crawler
For content outside Drupal, if you prefer not to develop a programmatic process to push data into a Search App, use the SearchStax Web Crawler to pull data. For more information, visit the Web Crawler user guide.
Note
Web Crawler is only available for the Premier Plus search plan.
Single pages as promotions
Single pages external to Drupal can be promoted to appear as a top result when specific keywords or phrases are searched. For more information about external promotions, visit this page.
Note
Promotions are only available for the Premier and Premier Plus search plans.
Enable Hit Highlighting in the Results Fields section after making necessary configuration changes in Drupal. For detailed instructions, visit this page.
If multiple local environments are connected to a Search App and you encounter issues with removing documents from another environment, clear the index by following the steps provided on this page.
Understanding the consumption of your search plan’s monthly request count is essential. Users in the account receive email alerts when usage reaches 60%, 80%, or 100% of the monthly quota. When the quota exceeds, searches generate Limit Exceeded errors.
Causes of unexpectedly high search volume:
Drupal Views with Additional Modules versus UI Kits:
Drupal Modules, such as the Facet Module or Autocomplete Module, may trigger separate search requests to the Search API before delivering the result to the end user, potentially causing multiple search requests for a single query. SearchStax UI Kits allow the inclusion of facets within the same Search API request. Additionally, the queries for suggestions from the SearchStax Auto-Suggest feature do not count towards your search plan's monthly request quota.
Custom UIs with Sliders for Filters:
Implement sliders for filters with consideration of your search plan consumption. A slider that calls the Search API with each user motion of the filter, without delay, can result in many more requests than anticipated.
Search plan consumption is refreshed daily in the dashboard. You can view usage for the account or an individual app by accessing the Account dropdown and selecting the Billing & Payments tab.
Note
Search Analytics captures the true searches made by users, rather than all Search API requests initiated by search pages, Drupal code, or other connected systems. Therefore, comparing search plan consumption in the Billing & Payments section to the Search Analytics history for the current month shows different numbers.
User management enables the invitation of users and assignment of role-based access. Default search plans include only the universal Admin role. For Premier and Premier Plus search plans, additional user roles can be assigned. For more information about these roles, visit this page.
Use the following steps to connect your Drupal sites to different SearchStax endpoints based on the Acquia environment, such as dev, test, and prod. This process uses secure config overrides in the nobackup directory as described on this page.
Note
This approach should not be followed if your application is hosted on Acquia Cloud Classic Infrastructure, which includes Site Factory. If your application already uses the Configuration Split module to manage configuration across environments, you must store SearchStax application data in the configuration directory of each environment.
Store keys in the nobackup directory:
Access each environment using SSH and create /mnt/gfs/<sitename>.<env>/nobackup/api_keys.php.
Insert the following code and replace <zone>, <app_id>, and <core_name> with the values from your SearchStax application:
Replace with an actual endpoint, for example: https://searchcloud-us-east-1.searchstax.com/12345/mysitedev-6789/update.
Use the correct token for each environment.
The nobackup path is /mnt/gfs/<sitename>.<env>/nobackup/api_keys.php.
Load keys in the settings.php file by adding the following to your settings.php or settings-include file:
$api_keys_file = "/mnt/gfs/<sitename>.<env>/nobackup/api_keys.php";
if (file_exists($api_keys_file)) {
require_once $api_keys_file;
}
Ensure that you update these lines based on your site name and environment. For example, if your site name is upperbasement and you are working in the stage environment, then replace $api_keys_file = "/mnt/gfs/<sitename>.<env>/nobackup/api_keys.php"; with $api_keys_file = "/mnt/gfs/upperbasement.stage/nobackup/api_keys.php";.
Override the SearchStax config by adding the following to your settings.php file:
Ensure that you update these lines based on your server name. For example, if your server name is Upper Basement Server, then replace $config['search_api.server.searchstax'] with $config['search_api.server.upper_basement_server'].
Note
The Drupal UI may not display the overridden values, but they are applied.
Never commit API keys to your repository. Keep them in the nobackup directory or a similar secure location.
Repeat this process for each environment, such as development, testing, and production.
Routing searches through Site Search
Specify in the Drupal module settings to route searches through Site Search. Route all searches through Site Search to leverage its features.
If you use additional modules in a Drupal View, review which features to use or override. For example, if you use the Drupal Facet module, you must deselect the Faceting box to exclude Faceting.
The following table outlines different settings and explains their usage:
Setting
Usage
Parse Mode and Searched Fields
The algorithm defined in the Drupal View overrides all defined search fields.
Highlighting Settings
Drupal performs highlighting, not search.
Spellcheck Settings
Drupal Spell Check continues to operate.
Sorting
Sorting remains controlled by Sorting Criteria within the Drupal View configuration.
For multi-site or Site Factory use cases, consider sharing Search apps among multiple Drupal sites to reduce Search App management overhead. The strategy for deploying search pages influences the outcome, as there are trade-offs between using Drupal Views and SearchStax UI Kits. Both approaches depend on indexing the site_hash from the Drupal database for each site. In both cases, when a user searches on site A, the site_hash filter automatically restricts Solr results to documents indexed from site A, even though all sites use the same Search app.
The details for each approach are as follows:
UI Kits
Ideal use case
For websites aimed at enhancing the end user's search experience and business performance, consider adding additional search features and tuning search relevancy for each site.
Implementation method
Index the field for site_hash from the Drupal database.
Use SearchStax JavaScript components to deploy and style a search page on each site.
Create a search profile for each website with a Data Filter to include only results where the site_hash field matches the corresponding website's hash value.
Update the search input component to specify which model or search profile to use for returning relevancy.
Benefits
Additional features, such as faceting, spell check, and related searches, can be easily enabled and added to the search pages.
It is possible to tune advanced relevancy configurations for each website separately through a search profile without additional code changes.
All search pages interact directly with SearchStax APIs, reducing extra load on Drupal servers.
You can leverage SearchStax features that do not further contribute to the Monthly Search Request quota usage of your Search Plan, such as SearchStax Auto-Suggest or SearchStax Facets.
Drawbacks
Pages require additional development effort to add and style JavaScript and to specify the Search Profile to call in Search API requests.
Drupal Views
Ideal use case
For websites with common and simple search requirements and no foreseeable business need to enhance the user's search experience.
Implementation method
Index the field for site_hash from the Drupal database.
Add a filter in your Drupal View for site_hash.
Benefits
Capability to continue using existing Drupal Views.
Drawbacks
Arguments cannot be passed to specify a particular Search Profile, or model, within a Search App, meaning relevancy cannot be defined differently across sites.
There is an inability to leverage SearchStax Search Page features such as spell check, related searches, and popular searches.
Queries from the search input or facets continues to generate additional queries to fully return expected results to the end user.
Similar to sharing Search apps across sites in a multisite or Site Factory use case, multiple sites can be connected to index their content into a single Search App to create a unified search experience. This setup enables end users to find content from multiple sites with ease.
This can be implemented by following this process:
Create a unique identifier for each site.
Index the unique identifier across all sites involved in the search experience.
Use the unique identifier field to create a facet.
Assign a label such as Website or Content Source to the facet.
Enable users to filter results based on each site's unique identity.
Note
This implementation employs SearchStax Facets, which are available only when utilizing a UI Kit or invoking the Search API through a custom UI. Drupal Views overrides this capability.
Improving users' ability to easily find content can be achieved by implementing an Auto-Suggest or Auto-Complete feature. The following is a comparison between the Drupal Autocomplete module and the SearchStax Auto-Suggest feature.
Drupal Auto-Complete
Implementation method
Use a Drupal View for your search pages.
Install and configure the Drupal Auto-Complete module.
Benefits
Does not require a warm-up period.
Drawbacks
Does not provide feedback from actual user searches and surfaces search suggestions solely based on indexed content.
The Drupal Autocomplete interacts with the Search API and is considered a search request. Each character keystroke entered by the end user may trigger an additional search query against the Search API, potentially impacting the Monthly Search Requests limit of your search plan.
SearchStax Auto-Suggest
Implementation method
Use a UI Kit for your site’s search page.
Access the Search App your site connects to in the SearchStax dashboard.
Click the Optimizations dropdown in the left-hand navigation and select the Auto-Suggest tab.
Click Enable Auto-Suggest.
Select Data-Driven, Dictionary-Driven, or Data+Dictionary-Driven to determine how Auto-Suggest generates suggestions.
Upload a dictionary if you select the Dictionary-Driven or Data+Dictionary-Driven option.
Benefits
Provides autonomous and continuous improvement to suggestions based on user searches over time, with a flexible interface for manually adding additional suggestions.
Suggestions do not contribute to the Monthly Search Requests limit of your search plan.
Drawbacks
The Data-Driven suggestion method requires search analytics data to warm up.
You can configure the SearchStax Auto-Suggest feature and bypass the warm-up period by downloading the title field for all indexed content from the Drupal database. Convert this data into a .TXT file and upload it in the SearchStax dashboard. File limits are 10MB, with a maximum of 35,000 entries in the dictionary per Search App.
Note
The Data-Driven and Data+Dictionary-Driven suggestion methods are available only in the Premier and Premier Plus search plans, which include Search Analytics tracking.
To include content from outside Drupal sites in search results, post documents to the Search app using the Ingest API. For sample commands and details on supported file types, visit this page.
Web Crawler
For content outside Drupal, if you prefer not to develop a programmatic process to push data into a Search App, use the SearchStax Web Crawler to pull data. For more information, visit the Web Crawler user guide.
Note
Web Crawler is only available for the Premier Plus search plan.
Single pages as promotions
Single pages external to Drupal can be promoted to appear as a top result when specific keywords or phrases are searched. For more information about external promotions, visit this page.
Note
Promotions are only available for the Premier and Premier Plus search plans.
Enable Hit Highlighting in the Results Fields section after making necessary configuration changes in Drupal. For detailed instructions, visit this page.
If multiple local environments are connected to a Search App and you encounter issues with removing documents from another environment, clear the index by following the steps provided on this page.
Understanding the consumption of your search plan’s monthly request count is essential. Users in the account receive email alerts when usage reaches 60%, 80%, or 100% of the monthly quota. When the quota exceeds, searches generate Limit Exceeded errors.
Causes of unexpectedly high search volume:
Drupal Views with Additional Modules versus UI Kits:
Drupal Modules, such as the Facet Module or Autocomplete Module, may trigger separate search requests to the Search API before delivering the result to the end user, potentially causing multiple search requests for a single query. SearchStax UI Kits allow the inclusion of facets within the same Search API request. Additionally, the queries for suggestions from the SearchStax Auto-Suggest feature do not count towards your search plan's monthly request quota.
Custom UIs with Sliders for Filters:
Implement sliders for filters with consideration of your search plan consumption. A slider that calls the Search API with each user motion of the filter, without delay, can result in many more requests than anticipated.
Search plan consumption is refreshed daily in the dashboard. You can view usage for the account or an individual app by accessing the Account dropdown and selecting the Billing & Payments tab.
Note
Search Analytics captures the true searches made by users, rather than all Search API requests initiated by search pages, Drupal code, or other connected systems. Therefore, comparing search plan consumption in the Billing & Payments section to the Search Analytics history for the current month shows different numbers.
User management enables the invitation of users and assignment of role-based access. Default search plans include only the universal Admin role. For Premier and Premier Plus search plans, additional user roles can be assigned. For more information about these roles, visit this page.
Use the following steps to connect your Drupal sites to different SearchStax endpoints based on the Acquia environment, such as dev, test, and prod. This process uses secure config overrides in the nobackup directory as described on this page.
Note
This approach should not be followed if your application is hosted on Acquia Cloud Classic Infrastructure, which includes Site Factory. If your application already uses the Configuration Split module to manage configuration across environments, you must store SearchStax application data in the configuration directory of each environment.
Store keys in the nobackup directory:
Access each environment using SSH and create /mnt/gfs/<sitename>.<env>/nobackup/api_keys.php.
Insert the following code and replace <zone>, <app_id>, and <core_name> with the values from your SearchStax application:
Replace with an actual endpoint, for example: https://searchcloud-us-east-1.searchstax.com/12345/mysitedev-6789/update.
Use the correct token for each environment.
The nobackup path is /mnt/gfs/<sitename>.<env>/nobackup/api_keys.php.
Load keys in the settings.php file by adding the following to your settings.php or settings-include file:
$api_keys_file = "/mnt/gfs/<sitename>.<env>/nobackup/api_keys.php";
if (file_exists($api_keys_file)) {
require_once $api_keys_file;
}
Ensure that you update these lines based on your site name and environment. For example, if your site name is upperbasement and you are working in the stage environment, then replace $api_keys_file = "/mnt/gfs/<sitename>.<env>/nobackup/api_keys.php"; with $api_keys_file = "/mnt/gfs/upperbasement.stage/nobackup/api_keys.php";.
Override the SearchStax config by adding the following to your settings.php file:
Ensure that you update these lines based on your server name. For example, if your server name is Upper Basement Server, then replace $config['search_api.server.searchstax'] with $config['search_api.server.upper_basement_server'].
Note
The Drupal UI may not display the overridden values, but they are applied.
Never commit API keys to your repository. Keep them in the nobackup directory or a similar secure location.
Repeat this process for each environment, such as development, testing, and production.
Routing searches through Site Search
Specify in the Drupal module settings to route searches through Site Search. Route all searches through Site Search to leverage its features.
If you use additional modules in a Drupal View, review which features to use or override. For example, if you use the Drupal Facet module, you must deselect the Faceting box to exclude Faceting.
The following table outlines different settings and explains their usage:
Setting
Usage
Parse Mode and Searched Fields
The algorithm defined in the Drupal View overrides all defined search fields.
Highlighting Settings
Drupal performs highlighting, not search.
Spellcheck Settings
Drupal Spell Check continues to operate.
Sorting
Sorting remains controlled by Sorting Criteria within the Drupal View configuration.
Did not find what you were looking for?
If this content did not answer your questions, try searching or contacting our support team for further assistance.
Cloud Platform