2

I have a need to have separate sites behave as if they are clones of each other; that is, they each need to have the same site UUID.

Due to the environment I am operating in, I am unable to change the site UUID via drush config:edit once the site is installed as I have no SSH access to the environment. Likewise, the only way I can create a new site in this environment is to upload the files, create an empty database and then run the install script. This creates a new site, with a new UUID, and therefore is no longer a clone. Once sites are installed in the environment, my only way of interacting with them is through the administration UI.

Any site I create in this environment will have the same code base; it is not a matter of messing things up by importing the wrong config.

I can import the same database into the new site once it is installed using Backup and Migrate, thereby changing the UUID (I assume). However, this does not quite solve the problem because it may be the case that I need to create sites via scripts in our continuous integration system.

My initial solution is to add a line in settings.php to override the configuration item in question, ie:

$config['system.site']['uuid'] = 'this is the site uuid';

However, when I export the configuration, the override value is not respected and configuration is exported using the original value. I can test this by exporting the configuration from a clone and trying to import it. If the UUID was being overridden 'fully', then I would expect the configuration import to fail.

Ideally, I would like to set the site UUID through an environment variable or service, so any site with access to the variable or service would be able to use the same UUID, and therefore be considered clones.

Has anyone had any success with something similar?

  • Once you have a running website, the uuid is basically baked into ALL config. Changing it in settings.php won't help you. The whole premise of single uuid-clones is plain wrong. The only solution to have the same config for different uuids is to export the config (drush cex), then via script delete the _config(i think) array and uuids from all the exported files. Then spin up a new site from clean sql file, set uuid via the settings.php and import config which will be treated like new(since no uuids). but event then you'll have issues(from that clean sql) so overall, bad idea from get go. – user21641 Feb 19 '18 at 10:25
  • @IvanJaros this is simply not true. You can very easily update the site UUID using drush cset system.site uuid "[new uuid]". Obviously this requires access to drush on the site in question. My problem was that I didn't have access to drush on the site, however some excellent work by the team in cloud.gov.au has sorted this issue out. – Jesse Boyd Mar 12 '18 at 23:28
  • of course you can change the uuid, i didn't not say otherwise. try drush cex and you will see each config now has _core value which is based on the initial uuid and will make the config compatible only with site with that uuid. – user21641 Mar 13 '18 at 11:27
0

In the end, it was a matter of getting Drush to work on the remote environment.

I was also able to build a small module to update the site UUID of an existing site, however we didn't end up using it. The code for that is available at this repository.

Essentially, this boils down to running something like this:

\Drupal::configFactory()
    ->getEditable('system.site')
    ->set('uuid', $uuid)
    ->save(TRUE);

Where $uuid is whatever the UUID you want, whether this is generated manually or loaded from a service.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.