Configuration management in Drupal 8 multi-site and distributions by shawndearmond

no one loved features

you’ll love using it in Drupal 8 because it does what it was originally meant to do

What happens when you have a lot? Multiple Drupal Sites (distro, multisite, etc.)

we give content editors an ability to

place blocks

SiteFarm - that’s what we call our service to the campus

Use Acquia Cloud Site Factory to deploy all the code (600 times) we don’t deploy the config

we develop SiteFarm for an initial install with hundreds of behat tests that run against that initial install

we push the codebase up there

sometimes we have more bespoke sites, a separate distribution that’s slightly different, that we deploy to Pantheon - each code base is separate, they tend to be more custom sites.

Your distribution should be pretty lean: core, modules/contrib and themes/contrib aren’t there, all that’s defined by the composer.lock

always run composer update, composer install from the distribution directory. But the profile directory has its own composer.json file, which is where all the drupal requirements go.

Distribution depends on the profile. Profile depends on various modules and themes. And those can have their own dependencies.

However, you can also put Drupal modules in the distribution

The reason for that is we have several different distributions. We have one for Acquia, and one for Pantheon, where there are modules specific to those. And it’s convenient to have those in the distribution and not in the profile, because the profile doesn’t care where it goes. It shouldn’t have Acquia-specific modules there.

there’s also:

config/install config/optional

i don’t understand it, really. But my rule of thumb:

try to get all you can in config/install and if it blows up, put it in config/optional

I tend to find block placement, views that depend on a content type, go in optional.

module default configuration site managers might change it

now features is not about single site deployment, but for configuration we expect to revert (me: push overrides of)

for us that is node tyes, field storage, fields, block content types, views, pathauto patterns, view and form display, taxonomy vocabularies.

This is what you’re managing as your SaaS product?

Yes, and we might even change it on purpose.

Had a bug in our RSS feed, malformed XML real problem. That’s just a view. We fixed it, and when we did config update revert view view whatever it was, we were confident we weren’t overriding someone else’s work.

Create new field, and configure node form and displays in UI: /admin/structure/types/manage/sf_articles/fields

Re-export the Feature, including new field: /admin/config/development/features/edit/sitefarm_article

Features keeps track of what has changed, and what dependencies were added.

Download it and commit new and updated .yml files to Git. These are the ones that are going to be changed (field storage, displays, etc)

Write an update hook to revert the feature for the entire platform:

function sitefarm_article_update_8107(&$sandbox) {
  $config_revert = \Drupal::service('config_update.config_update');
  $config_revert->import('field_config', 'node.sf_article.field_sf_content_audit');
  $config_revert->revert('entity_form_display', 'node.sf_article.default');
  // ...

  return t('Added the content audit field to existing article content type.')

You need to get your import and revert correct.

We don’t allow people to get permissions to the site to do anything.

We created a mini-permissions page, that only gives them access to the things we want to let them change.

Lock Features we built for the express purpose of allowing Site builders to create new views, content types, etc. without touching the existing ones.

But then i learned today that the config_readonly module does pretty much the same thing.

config_ignore just ignores tho content

entity_clone - let people clone their nodes – and also configuration entities, including views and content types. They’ve basically forked that thing, they no longer get updates to that content type, but our updates don’t screw with it.

Q: Does that work for layouts when the layout is attached to the original entity? A: I don’t know.

Layout per node stored in database. Layout per content type stored in configuration.

Itwould be cloned because it’s a field.

Shawn DeArmond Web Achitect University of California, Davis

When is subprofiles going to be in core. I will say that the subprofile patch does work pretty well with this model. You can override configuration from your base profile in your subprofile by using the same filename.

If someone had customized their

The way we do our update hooks, we decide what we’re going to override and what we won’t.

We don’t have to write the update hook and we don’t want to.

If later, down the line, we decide to

Me: Things like title of a view We just don’t let them edit

We have the problem with us not configuring the module.

We’ve done that too– we’ve created another form, that extends the other form, and then we lock the original.