Split configuration so devel module is only enabled in development

[geerlingguy]

Currently I have all the site's configuration dumped into one big bucket. During the (#34) March 24th livestream, I added the Devel module, which resulted in some configuration being added to that bucket, namely:

• core.extension.yml has an entry that enables Devel
• devel.settings.yml config was added
• devel.toolbar.settings.yml config was added
• system.menu.devel.yml config was added

I don't really want those things to be enabled in 'production' (even though that doesn't exist yet), so I would like to set up a 'split' that allows Devel to exist in a local environment, but not in a production environment.

[geerlingguy]

I'm following this documentation page, and made it to the step of creating the dev split and the config/dev directory. We'll finish this on next week's live stream.

[gitressa]

Thanks to the update published in the change record Modules can be excluded from the configuration synchronization for Drupal 8.8 (September 2019) you can define which modules should not be included in the configuration export by adding a single line in your local development settings.php file like this:

$settings['config_exclude_modules'] = ['devel', 'webprofiler', 'views_ui'];

I think this probably means that if you configure fx Devel for your local development environment, these changes won't stick, but I haven't tested it, since I just use the defaults.

[geerlingguy]

@gitressa - Thanks for the information; I'll take a look.

[geerlingguy]

Hmm, one thing I wonder—would re-installs from config in the local environment, then, not have the devel module enabled? Since it's not in config anywhere, it seems like I'd have to manually re-enable the Devel module each time I reinstall my local instance.

The new feature in 8.8 seems nice from a "don't allow this module's config to ever hit production" perspective, but it's not as helpful as config split in terms of allowing for different config settings for different environments :/

[gitressa]

Yes @geerlingguy, I do enable those modules as part of my build process. I use Lando's tooling feature for fresh builds, to automate as much as possible and avoid repetitive typing (and possible errors). The last few commands are these:

- echo "# DEVELOPMENT relax some permissions"
- /bin/sh -c "chmod -R u+rw web/sites"
- /bin/sh -c "cat .lando-settings.txt >> web/sites/default/settings.php"
- drush user:create ed --password=ed
- drush user:role:add "editor" ed
- echo "## enable Views UI, Devel and WebProfiler
- drush en devel webprofiler views_ui -y
- echo "### one time login for admin"
- drush uli
- echo "### RESET search, and re-index"
- drush search-api:reset-tracker && drush search-api:index

You're correct that the config_exclude_modules solution via settings.php is a bit simple, and won't allow Devel configuration to be saved. Like I wrote, I use the default Devel settings, but certain settings could also be set during a build process like above.

For example, to enable the Devel option Display $page array during the build process, this could be added: - drush config:set devel.settings page_alter true -y

EDIT: I just re-read the the description in the change record of Modules can be excluded from the configuration synchronization, and there is a sentence which actually pretty much answers our questions:

... sometimes it is not necessary to share the development configuration and instead it is more important to guarantee that development modules can not be included in the configuration export.

[gitressa]

Actually, it seems like Drush 9.7.2 doesn't respect modules defined under $settings['config_exclude_modules']. Running the same command under Drush 9 and Drush 10:

Drush 9.7.2

$ drush config:status	Name	State
core.extension	Different
devel.settings	Only in DB
devel.toolbar.settings	Only in DB
system.menu.devel	Only in DB
webprofiler.config	Only in DB

Drush 10.2.2

$ drush config:status
 [notice] No differences between DB and sync directory.

I found the issue https://github.com/drush-ops/drush/issues/4194 where it seems to get fixed, but maybe only for Drush 10?

And Migrate Upgrade doesn't work with Drush 10 yet. So that was a wild goose chase for nothing, sorry about that.

[geerlingguy]

@gitressa - Haha, no problem, it's good to know about this so I can highlight the feature in the next episode (tomorrow morning!). And in my case, since I will probably store a few settings specific to my local environment, I think Config Split's extra functionality will still be worth keeping it around for me.

[gitressa]

@geerlingguy: Good :-) I will probably wait for Drush 10 to work with Migrate Upgrade, since during the actual migration and development I don't need to disable those modules, it's only when it's time to move to production it will be needed. But Config Split seems complex to set up, so it'll also be interesting to see you go through the steps.