Can I safely use the same UUID on independent sites?

Question

I'm trying to create a site building workflow which uses some sort of blueprint site, providing a shared, tested set of the Drupal core, modules, content types, paragraph types, a base theme, etc. for all our client work.

Projects/websites shall initially start with the same configuration as the blueprint site, but later on those projects are otherwise completely independent (different clients, different themes, modules will be added/removed, content types will change, ...)

From what I've read this should be possible with config export/import and by manipulating the UUID of the sites.

The question is: Is it a problem when ALL our projects share the same UUID? In the long run I'm going to end up with about 30-50 projects, each project will a dev and a prod environment, so in total there will be ~ 60-100 installations with the same UUID.

Updating the core and shared modules shall also be done and tested on the central blueprint site, and then pulled and merged by all projects.

Answer 1

This is a perfect use case for Features. You can export shared sets of functionality and configuration without worrying about UUID stripping or collision.

The features module enables the capture and management of features in Drupal. A feature is a collection of Drupal entities which taken together satisfy a certain use-case.

Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it contains additional information in its info file so that configuration can be checked, updated, or reverted programmatically.

Examples of features might be:

• A blog
• A pressroom
• An image gallery

Answer 2

Following Kevin's hint using the Features module I've done some testing, and this is what I've got so far:

Blueprint site:

1. Create a Drupal composer project
2. composer require all shared modules
3. drush site-install minimal
4. Set up my desireded configuration
5. In features module, create a blueprint feature containing every single component and export it
6. Commit to git
7. (Later on: update core and shared modules, after successful test push to git again; repeat)

Client project spawning:

1. Init a new repository, add blueprint as additional remote and pull from blueprint
2. composer install
3. drush site-install minimal
4. drush en blueprint_theme
5. drush en blueprint_module
6. git push to project's own origin remote
7. (Later on: pull core and shared module updates from blueprint repository, but do not import config)

Some things I've learned so far:

• Features exports your config as a custom module, you don't even need features to import the blueprint config into the client project, you simply enable the module.
• The theme used on your blueprint site must exist and must be activated before enabling the blueprint module on the client project. (I guess this is coming from blocks being included in config)
• All modules have to exist in your client project directory before activating the blueprint module. They don't need to be enabled, but Features can't download missing modules.
• Features seems to merge & override the existing client project configuration, but it does not remove additional configuration existing only on client. (e.g. it does not delete additional content types from the client project. This behavior differs from Drupal core configuration management.)
• Uninstalling the blueprint module has no effect at all, it will not revert your configuration.

It is neither perfect nor extensively tested so far, but it seems to be a much cleaner solution than messing around with UUIDs.