Configure hash_salt to be different for multisites.

[dpagini]

Is your feature request related to a problem? Please describe.
There is probably some background on this that can be gained in the discussions on this Acquia ticket. The Acquia team is suggesting to us that it is a best practice to make hash_salt differ between different multisites. This is also related to #4290 in a way.
The underlying gist of this is that our APCu cache is getting prefixed with a hash of this value, and it's being shared across all of our multisites since it's the same and corrupting caches that should be different across sites.

Describe the solution you'd like
In our project, we are prefixing/suffixing our site specific has salt with the $site_dir variable. Not entirely sure if that's an OK approach or frowned upon for any reason?

Describe alternatives you've considered
None.

[danepowell]

I agree that a separate hash salt per db probably makes sense, but this won't be trivial to implement because you can't just hardcode a hash salt on disk for ACSF applications that can create dbs on the fly. For now you might want to implement yourself using the guidance in https://support.acquia.com/hc/en-us/articles/360054634014-How-to-set-a-unique-hash-salt-for-an-individual-site-in-Site-Factory

Related upstream issue: https://www.drupal.org/project/drupal/issues/2984232

[mikemadison13]

i've done something like this in the past by "dyamically" generating the hash based on the site name and environment. @danepowell I can show you an internal jira issue that discusses this if you're interested.

[dpagini]

Well this already wouldn't be working ideally for ACSF, so I suppose this is suggesting we improve the experience for traditional multisites and not solve the ACSF issue immediately?

[bkosborne]

@dpagini Been a while, I wonder if you can expand on the issue you faced originally where the same hash salt used across your ACSF sites was causing an issue. I know Drupal uses the hash salt when computing the APCu cache prefix, which is used by the Composer file autoloader. Is this where you had issues? It seems that the only way you'd have issues here is if you have some sites using different versions of files with the the same class name, which seems like it shouldn't be possible in ACSF (e.g. you cannot have site-specific module folders in ACSF like you can in traditional multisite).

Note that Acquia started setting hash salt to unique-per-site as of mid 2020:

"By default, new sites in multisite or Site Factory applications got unique hash salt starting from July 9, 2020. Contact Acquia support to enable hash salt for the sites that were created before July 9, 2020."

I guess because they noticed problems with it, but I personally don't think I've encountered them. We have a stack with over 500 sites in it with the same hash salt

[dpagini]

I'm just seeing you posted on that linked d.o issue for me almost a year ago, sorry about that!

I'm having to rack my brain a bit to remember what was going on here... I think this might have been my first guess at what the problem was. Basically BLT was using the same hash_salt for all sites in a multisite (including, I would suspect, site factory sites), and the suggestion, based on Drupal best practices, was to vary that per site.

But I think I continued to face the problem even after making the hash salt change locally. I was clicking around related Drupal issues, and I think this issue was ultimately the culprit for me. It had more to do with the fact that when Drupal was building a container, based on the way the container was getting rebuilt (potentially via drush), it was not including site specific code/extensions, and that site specific code was then breaking.

So it would really only be a problem if you had, for example, a module at docroot/sites/xyz/my_module and docroot/sites/abc/another_module.

Does that help at all?

[bkosborne]

Yes, that helps! Thank you for following up. I suspected what you reported was related to that type of scenario.