Hello,
great module I wander why only 264 sites are using it. By the way I'm working in a use case where there is a big ecosystem of multiple independents sites where some groups of sites are related under one category but that categories may have a hierarchy:
Example:
In this scenario we need to search at different levels: locally in each site (ig. Museum1), multisite in a group of sites (ie. Museums, not necessary a tee branch), and globally in all sites (Cutura). this module resolve the first and the last scenario.
I think it would be useful to include the feature to search in a set of sites.
Comments
Comment #1
mscalone commentedtwo possibilities I figured out:
What do you think?
I think I'm going to make some tests with the second option.
Comment #2
thepanz commentedSolution #3: override multisite hooks to add in each indexed document also the site-category.
finally add such site-category as a search facet.
my 2 cents
Comment #3
mscalone commentedThat's a great idea because its less invasive and simpler, but unfortunately multisite search does not seems to expose any hook. Anyway it's possible to do the same implementing hooks from apachesolr and check whether apachesolr_miltisitesearch its enabled or not.
When I request the feature (one year ago) I was thinking in a modification to the apachesolr_miltisitesearch module, I thought it more adequate. But it does not seem to be a very requested feature by the community, maybe it's better to separate it into a different module.
I'll think about it, thanks
Comment #4
dave reidI actually wanted this feature because I need the multisite search, but only only wanted to query select sites, but not just the local site or all of the multisites. Patch ready for review.
Comment #5
dave reidRevised patch with some cleaned up logic and a helper function to retrieve the option array of multisite hashes since it's now used more than once.
Comment #6
pwolanin commentedLooks like a good start.
I might name the environment variable something like _sites instead of _hashes, since the "hash" name was kind of jus a dumb choice on my parts\ several years ago (when it started out as a hash of the site URL). It's really like a site ID or machine name.
Instead of the doing a raw string construction + implode we might want to use the subquery class like the apachesolr_access module:
The subquery comes from calling function apachesolr_drupal_subquery().
Comment #7
dave reidThanks for the feedback, those all sound like good improvements! Renamed things from 'hashes' to 'sites' and added a helper function apachesolr_multisitesearch_build_site_subquery() which uses a proper subquery object.
Comment #8
dave reidMissed one $hash variable should have been $site.
Comment #9
dave reidShouldn't had moved around the ->addParam() calls.
Comment #10
dave reidShouldn't patch too late at night.
Comment #11
xtfer commentedProbably related: #2224325: Bundle exclusion breaks when indexed bundles change
Comment #12
madhusudanmca commentedHi,
Many thanks for providing the patch. It looks good to me!!
However I still have one concern with this module since beginning, as indexed sites listed (to be searched or to delete index) some time show actual sites URL (like: http://examlple.com) and some times it's hash value (like: o792hb). Showing hash value of site make it very difficult to read, which site we are referring.
Can we get rid of this issue?
Thanks.
Comment #13
dave reid@madhusudanmca the same behavior happens without this patch as well, so no need to push it down to needs work for that.
Comment #14
madhusudanmca commentedHi Dave Reid,
Excuse me for putting it to "needs work", I thought that that you are the one of maintainers of this module!!
Actually for two of our clients I also wrote the custom code for having sites specific search in a multisite search environment using Apache SOLR hooks.
It'll be nice if we can have that in "Apache Solr Multisite Search" module itself.
This patch looks good to me except that site URL mash!!
Thanks
Comment #15
dave reidRevised patch that ensures the current site is always listed in the box of options (in case the metadata hasn't been refreshed before hitting the edit Solr environment page).
Comment #17
dave reidCommitted #15 to 7.x-1.x.
Comment #19
tjmoyer commentedDoes this, by any chance, resolve this issues as well: Bundle exclusion breaks when indexed bundles change? We're having trouble with the exclusions list changing, causing search to be unavaliable.