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.

2 Answers 2


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
  • I thought the primary use case for features is to export/import smaller subsets of configuration, while core's config-management should be used for the complete config set. I intented to use the features module too, but only to reuse smaller, only infrequently used subsets. Is features really the right tool to export the complete configuration?
    – Hudri
    Apr 21, 2017 at 14:38
  • The core CM is meant for the same site, not for sharing across different sites. You can use Features to extract some or all config from a site and package it into modules or even an installation profile.
    – Kevin
    Apr 21, 2017 at 14:39
  • You can install Features and configure bundles - it does have a "Core" package which sounds like what you are after.
    – Kevin
    Apr 21, 2017 at 14:53

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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