Cloud Platform

Known issues

This page describes the known issues with Acquia Search.

Known issues for Acquia Search on Drupal 7

The Workbench Moderation module can cause search integration problems

For more information about the Workbench Moderation module, see its project page on Drupal.org.

Search API has memory errors when indexing

For more information about this issue, see Better memory usage on indexing on Drupal.org.

Search API provides fewer configuration options

The Search API module provides fewer configuration options than ApacheSolr integration in Drupal 7.

Known issues for Acquia Search on the current Drupal version

The Search API module can’t display result snippets

The Search API module can’t display result snippets—the full node output displays as the search result.

Workaround: Create a Search result view mode to output something smaller than the full node. To add the workaround, complete the following steps:

  1. Go to Structure > Content types > Article > Manage display.
  2. In the Custom display settings section, select the Search result highlighting input checkbox.
  3. Click Save.
  4. Go to Structure > Content types > Article > Manage display > Search result highlighting input. The following settings control each search result’s output.
  5. To display result snippets, edit the appropriate field. For example, to make the Body field display result snippets, complete the following steps:
    1. In Format, click Trimmed.
    2. Click the gear icon. The webpage displays the Trimmed limit field.
    3. In the Trimmed limit field, enter 200 to trim the body field to 200 characters.
    4. Click Update.

You have now configured the Body field to display trimmed output as the search result.

Non-SQL query plugins for Views cause PHP errors

For more information about this issue, see Views problems with non-SQL query plugins on Drupal.org.

Views exposed filters must not be cached

Views exposed filters, such as search results and blocks with facets, must not have caching enabled alongside AJAX. For more information, see Ajax facet block seems to lose views context on Drupal.org.

Content types are unintentionally indexed

Acquia Search indexes content types, when that is not the intended behavior.

Workaround: Add a content type filter to an Acquia Search view.

Upgrading the search_api_solr module from 4.2.x to 4.3.x causes reindexing to fail

Upgrading the search_api_solr module from version 4.2.x to 4.3.x results in reindexing failure.

To successfully perform the upgrade:

  1. Upgrade the module to version 4.3.x.
  2. Delete the index from the Cloud UI.
  3. Create a new index using the Solr 8 configset.

Development environments can easily write to production indexes

By default, Acquia Search stores configuration in the database. When the production database is pulled into a development environment such as Acquia Cloud IDE or local environment, the Solr core/server, site ID (site_hash), and other details get copied over. As a result, the development and the production environments end up sharing the same Solr index. This causes numerous issues including duplicate results, results from the wrong site, and deletion of all content in the production environment’s Solr index.

Workaround: Set the index status to Read only on all development environments.

  1. Option 1 (works for local development environments and Cloud IDEs): In sites/default/settings.local.php, add the following code:

    // Check if Acquia environment variable is not set or equals 'ide'.
                                    if (!isset($_ENV['AH_SITE_ENVIRONMENT']) || $_ENV['AH_SITE_ENVIRONMENT'] === 'ide') {
                                    // If there's no 'AH_SITE_ENVIRONMENT' or we are on an Acquia Cloud IDE,
                                    // set Acquia Search to read-only mode.
                                    $settings['acquia_search']['read_only'] = TRUE;
                                    }
                                    
  2. Option 2: Add additional custom code by following the recommendations in Read-only Solr search index.

Suggester configuration causes the "Lock held by this virtual machine" error

The "Lock held by this virtual machine" error occurs in Solr when the following actions take place simultaneously:

  • Indexing
  • Building of a suggester for the index
This error occurs due to individual folders not being assigned for each suggester in the configuration.
Consequently, Solr attempts to build all these dictionaries in the same folder, leading to a write.lock conflict in Solr. This typically happens when Solr is in the process of building these dictionaries. 
The configset release, (Latest) Drupal 8 / 9 - Search API Solr 4.2.0 - Solr 7 - [drupal-4.2.0-solr-7.x-0] - v2.0, provides a fix for the Acquia default configuration. However, if you are using a custom configset that includes a suggesters configuration, you must add the following configuration item to each suggester:
<str name="indexPath">./SUGGESTERS_NAME</str>
The following is an example configuration for the en suggester:
<str name="indexPath">./en</str> and <str name="indexPath">./und</str>.
    <lst name="suggester">
      <str name="name">en</str>
      <str name="lookupImpl">AnalyzingInfixLookupFactory</str>
      <str name="dictionaryImpl">DocumentDictionaryFactory</str>
      <str name="field">twm_suggest</str>
      <str name="suggestAnalyzerFieldType">text_en</str>
      <str name="contextField">sm_context_tags</str>
      <str name="buildOnCommit">true</str>
      <str name="buildOnStartup">false</str>
      <str name="indexPath">./en</str>
    </lst>