This is an outline how we're using the devel_config module to enable configuration in a way like a bit like features.

Aim

  1. to move away from having all config in 1 monolithic blob and into modules so that test and deploy are more manageable.
  2. Place config into git in a manageable way.
  3. Means you don't need to use config split but can define config in features following along from git flow
  4. A reproducible build process that can take you from empty database to basic test in 2 or 3 steps and less than 5 minutes.

Using git flow and having had a love hate relationship with Drupal features (now not reccomended) I wanted an alternative approach to using a feature based development work flow and after some experiment we are using the following method in our team.

Pre requisites

  • You're happy using a mix of Drush and Drupal console to perform a wide array of
  • You have a custom profile and can get used to running drush si on a regular basis without shuddering (hey it's not D7 days anymore!)

Custom default profile

If you want you can define your profile as the default and then you can override it like this: drush site-install standard - installs with standard profile rather the new default

//filename=yourprofile.info.yml
name: 'YOURPROFILE base config'
type: profile
description: 'Some base config for home page and modules etc.'
core: 8.x
version: 0.1-dev
# Optional: Declare your installation profile as a distribution
# This will make the installer auto-select this installation profile.
# The distribution_name property is used in the installer and other places as
# a label for the software being installed.
distribution:
  name: Your profile
dependencies:
  - admin_toolbar
  - admin_toolbar_tools
  - automated_cron
  - backup_migrate
  - block
  - block_content
  - breakpoint
  - ckeditor
  - color
  - comment
  - config
  - config_devel
  - contact
  - contextual
  - datetime
  - dblog
  - default_content
  - dynamic_page_cache
  - editor
  - entity_reference
  - feeds
  - feeds_ex
  - field
  - field_ui
  - file
  - filter
  - help
  - history
  - image
  - kint
  - layout_discovery
  - menu_link_content
  - menu_ui
  - node
  - options
  - page_cache
  - path
  - pathauto
  - pathologic
  - quickedit
  - rdf
  - responsive_image
  - revision_log_default
  - search
  - settings_tray
  - shortcut
  - slick
  - syslog
  - taxonomy
  - telephone
  - text
  - toolbar
  - tour
  - update
  - user
  - views
  - views_ui
  # Custom modules
  - project_custom_module
themes:
  - project_theme
  - seven

Exporting config to modules

Have a look at the devel_config project page. Essentially you are capturing the config names in your module.info file and then using drush to export the configuration into the module directory. It is then enabled when you enable the module.

Steps

  1. Build your cool feature in Drupal, add whatever additional hooks into your module
  2. Run drupal ce to export the complete site config - get the directory location
  3. cd to-configuration-sync-direcory
  4. ls | grep CONTENT_TYPE_NAME|FIELD_NAME|OR_WHATEVER and check the list of config file names - make sure you got everything - display formats whatever!
  5. Copy these names into your module.info.yml under optional - it will look something like this:
name: PROJECT module_name
type: module
description: 'Description goes here.'
core: 8.x
package: PROJECTACRONYM
version: 0.1-dev
dependencies:
  - entity_browser
  - node
  - user
  - default_content
  - config_devel
  - feeds
  - feeds_ex
  - views
config_devel:
  install:
  optional:
    - core.base_field_override.node.CONTENT_TYPE.title
    - core.entity_form_display.node.CONTENT_TYPE.default

You will want to remove the yml file extension.

You can see that there is a naming convention and package. Naming things sensibly and consistently helps a lot in projects and should be agreed at project start. It also means things you can do things like:

drush pml --package=PROJECTACRONYM --field=name | xargs -I % drush cde %

To export the config for all of the package at once (works on OSX, might need changing for *NIX)

  1. Export the config with drush config-devel-export or cde, cd-em for short - you should see the new config in your module directory
  2. To test first backup your data base drush sql-dump FILENAME.TIME
  3. drush si to refresh your config
  4. drush en MODULE
  5. Test - missed something? Re-install the old DB and re-check the sync directory as step 4 above.

Default content

At first we had this within the feature modules, and for some things this makes sense (like taxonomy terms you need as structure) but there can be dependency issues that are hard to trroubleshoot and it feels cleaner to have most of the default content (a lot of which is for test?) in their own module which can then be enabled post install as needed with drush.

We had trouble with paragraphs which will hopefully be fixed. Also content with a lot of references needs a different work flow - rather than using module.info.yml to export content by module drush default-content:export-module module_name rather use:

drush dcer node [NID] --folder=modules/custom/PROJECT/PROJECT_test_content/content

Which will spit out all the associated content, even user which you may wish to delete.

Things you can achieve using this method

  • Provide a default base config for e.g. home page block layout
  • Each feature encapsulated within a module like D7/8 features
  • Managing dependencies per module
  • Splitting out development settings into their own module rather than using split config
  • Using default content - managing content via drush dcer [NID]

Things you can't manage this way

  • Simple '1-click' deploys with everything in the sync folder
  • Site settings like site name and admin email - any config that starts system.?