This is an outline how we're using the
devel_config module to enable configuration in a way like a bit like
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.
drush sion a regular basis without shuddering (hey it's not D7 days anymore!)
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
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.
drupal ceto export the complete site config - get the directory location
ls | grep CONTENT_TYPE_NAME|FIELD_NAME|OR_WHATEVERand check the list of config file names - make sure you got everything - display formats whatever!
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)
cd-emfor short - you should see the new config in your module directory
drush sql-dump FILENAME.TIME
drush sito refresh your config
drush en MODULE
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
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.
drush dcer [NID]