Problem/Motivation

Multisite relies on the locally set ApacheSolr site hash to determine which site it is currently looking at. This is a random six-digit string.

While this string is intended to be unique per site, in practice this is not the case, as the hash will be shared across any sites which duplicate the database. This includes development sites, for which this may be desirable, and sites which simply result from a duplicated database. While the latter is not optimal from a development perspective, it does occur.

Additionally, should this value get out of sync, or be changed, it cannot be predictably reset, since it is randomly regenerated.

Proposed resolution

Implement hash generation for multisite indexes based on the site URL, and allow the user to regenerate this hash if required. Don't replace existing hashes unless the user forces it, but warn on the Multisite admin page when this might be beneficial.

Remaining tasks

None, patch supplied.

User interface changes

The Multisite overview page will require a minor redesign to accommodate the additional hash checking, hash information, and regeneration options.

API changes

None.

CommentFileSizeAuthor
#2 2225181-1-validate-hashes.patch15.3 KBxtfer
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

xtfer’s picture

Issue summary: View changes
xtfer’s picture

Patch attached.

xtfer’s picture

Status: Active » Needs review
Related issues: +#2224325: Bundle exclusion breaks when indexed bundles change

Additionally, this patch is blocked by and requires #2224325: Bundle exclusion breaks when indexed bundles change.

Dane Powell’s picture

What if a single site is accessible by multiple URLs? For instance www.example.com (public-facing) and edit.example.com (for authenticated users). Seems like this would create multiple hashes for the same site.