On the Multisite Filters tab/page on one of my servers, one of the hash tags in the Administrative Functions section is showing up as the site's hash tag rather than the Site's name.

Delete data from sites using this index:
65797bf0df3c (18937 documents)
This site ('SITE Name', 7392 documents)

So on the search results the hash tag is also showing up instead of the site name.
I had the same sites and index on my localhost and after the index was built this information did 'translate' properly to the site's actual name.

Any thoughts as to why this might be occurring?

Thank you in advance for any suggestions. This has been a really helpful module so far.


Members fund testing for the Drupal project. Drupal Association Learn more


wmostrey’s picture

Category: bug » support

You will have to index the site once from the original site after you have installed the apachesolr_multisitesearch module. This will link your site's name to its hash.

wmostrey’s picture

Status: Active » Postponed (maintainer needs more info)
Takki’s picture

Version: 6.x-1.x-dev » 7.x-1.0


I seem to be having the same issue. I've tried to debug a bit and i noticed that the metadata of the (not translated) site is not commited to solr.
The site itself is indexed correctly. The generated metadata from apachesolr_multisitesearch_generate_metadata is also correct.
But the site metadata is not appearing in solr. Although apachesolr_multisitesearch_update_metadata() is not returning an error.
So because of that, the variable containing the hashes doesn't have this site, so the hash can't be mapped. This issue only appeared after the 7th site, the other 6 sites, showed up fine.

Any thoughts?

cntlscrut’s picture

I have been running in to the same issue as well. it wasn't noticeable until we implement the site facet block in line with caching.

One of things that I have noticed is that when refreshing the metadata in the admin, not all of the data refreshes and with each refresh the data comes back i see that one site that didn't get the sitename did but, one that was already correct lost it's meta data.

When working with a small number of sites (let's say 5) the data worked well in line. When the amount increased to (let's say 10) that's when the issue became more prevalent and from there not 100% of the metadata seemed to be returned and with each refresh it appears that the set changed.

One method that I'm looking at would be to get the metadata, determine, the number of sites and see how many of the "buckets" of data are full and then, from there request the data until we determine that the "buckets" are full before we set the apachesolr_multisitesearch_metadata variable in the db.

Though that process introduces a little extra overhead, it may insure that the data is stored locally for the benefit of other functions that implement the data.

If I'm successful in my thought, I will submit a patch for community review.

clock’s picture

I also noticed this happening
I simply deleted the solr index
ran drush vset apachesolr_site_hash "site_name" on each site
and re-indexed the sites

Once the hash is set in the db apachesolr_site_hash() will always return your custom set hash. I don't see anywhere in the code that this will hurt, its only used to set the id and i believe solr can hold up to 256 characters in the field. You can also set custom text this way, rather than showing "shop.example.com" it can show "Shop".

bibishani’s picture

Problem comes from apachesolr_multisitesearch_retrieve_metadata(). There is no given value for rows param in multisite meta query, so its using the default one - 10, so it returns only 10 documents and the module works properly with 10 or less sites. I'm applying patch, it's not the best solution, but works fine with less than 1000 sites

Dave Reid’s picture

Version: 7.x-1.0 » 7.x-1.x-dev
Component: User interface » Code
Category: Support request » Bug report
Issue summary: View changes
Status: Postponed (maintainer needs more info) » Needs review
thePanz’s picture

Could be a duplicate of #2135863: Error in counting HASHes?

comment #5: setting a value with spaces as site-hash (as the site_name is) may lead to errors given the hash handling functions of this module

k.minkov’s picture

554 bytes
PASSED: [[SimpleTest]]: [MySQL] 0 pass(es). View

The #6 patch doesn't apply to the latest dev, here is a rerolled version.

adam.leighton’s picture

Ran into the same issue. We have a large multisite instance, but only 10 sites at a time would have their site hash + sitename pair properly stored and rendered. This patch solved the issue. Very happy and hope this gets folded into the module's stable release.

janusman’s picture