Although this issue has been raised, and purportedly fixed, elsewhere, I found it still occurring for my current install:

  • Domain Access 7.x-3.8
  • Apache Solr 7.x-1.2
  • Apache Solr Panels 7.x-1.0+6-dev

After debugging, it appeared to be caused by a single apachesolr_site_hash being used for all domains.

I made a small implementation of hook_domain_batch to allow setting the apachesolr_site_hash variable.

The variable can be set per-domain from /admin/structure/domain/batch > Apache Solr site hash

After deleting the index and reindexing from both sites, the search results became domain-specific.

Just posting the code here in case any one else has a similar issue.

Setting domain specific site hashes and re-indexing fixed the search problem for me.

/**
* Implements hook_domain_batch().
*
* Add batch settings to Domain Conf.
*/
function MODULENAME_domain_batch() {

  $batch = array();

  if(function_exists('apachesolr_site_hash')){
    $batch['apachesolr_site_hash'] = array(
      '#form' => array(
        '#title' => t('Apache Solr site hash'),
        '#type' => 'textfield',
        '#description' => t('Unique site hash for Apache Solr.'),
      ),
      '#domain_action' => 'domain_conf',
      '#permission' => 'administer site configuration',
      '#system_default' => apachesolr_site_hash(),
      '#meta_description' => t('Set Apache Solr site hash for each domain.'),
      '#variable' => 'apachesolr_site_hash',
      '#data_type' => 'string',
      '#weight' => -1,
      '#group' => t('Apache Solr'),
      '#update_all' => TRUE,
      '#module' => t('Apache Solr'),
    );
  }

  return $batch;

}

Cheers,

DT

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

davidwhthomas’s picture

Issue summary: View changes

More info

davidwhthomas’s picture

Issue summary: View changes

clarification

davidwhthomas’s picture

Issue summary: View changes

change data type from text to string

agentrickard’s picture

Category: bug » feature
Status: Active » Needs work

That is fascinating. I am tempted to add this to the main module.

davidwhthomas’s picture

Status: Needs work » Needs review
FileSize
1.13 KB

Thanks agentrickard!

I've attached a patch that adds the feature to domain_conf_domain_batch

Cheers,

DT

davidwhthomas’s picture

Version: 7.x-3.8 » 7.x-3.x-dev
davidwhthomas’s picture

Renamed patch for testbot

mstrelan’s picture

I've just tested out this patch and it initially appears to be working, at least for users other than user 1. I'm wondering if I will need a cron job per domain now or will it just work having cron on the master domain?

davidwhthomas’s picture

@mstrelan, I believe DA takes care of running cron separately for each site via a single cron job, so that single master cron job should be fine there.

agentrickard’s picture

Well, normal hook_cron indexing of search should be fine -- if I understand the question. If it doesn't work, then you can implement hook_domain_cron() to run your hook for each specific domain context.

agentrickard’s picture

Issue summary: View changes

detail

deardagny’s picture

Looks like this was never committed. I'm using Solr 7.x-1.5 and applied the patch to Domain Access 7.x-3.10+9-dev, set different hashes for my domains, and cleared/reindexed.

I see that two .fdt files are generated with their particular hashes, but it seems that all content is sent to both indexes regardless of their domain settings. Is this expected behavior, or should the content in the indexes themselves be domain-specific? I'm getting the same incorrect search results on both domains, along with duplicates of content that is set to both domains.

Any help would be appreciated!

davidwhthomas’s picture

@deardagny

Keep in mind if the user has sufficient permissions, they can view content from the other domain in the search results.

To eliminate that possibility, try searching as an anonymous user or user without admin permissions.

deardagny’s picture

Thanks David - All the testing I've been doing is as an anonymous user. I noticed that the Solr autocomplete widget is not respecting the access rules either. One thing I failed to mention is that I'm using Domain Access Entity to set these access rules (products on a Commerce site). I'm wondering if there may be an incompatibility there.

mas0h’s picture

Is this going to be committed?

agentrickard’s picture

Typically, I don't support non-core modules in the main module.

preksha’s picture

I am having the same issue and I have followed above steps. But when I try to search I am getting error "Search is temporarily unavailable. If the problem persists, please contact the site administrator" and I am not able to search the contents.

Any help would be appreciated !