1. Validation and limitations
1.1. Site UUID must be in sync
1.1.1. Getting the UUID in sync for two sites
1.1.2. You cannot use config-edit. It validates the import and finds that the UUID has changed.
1.1.3. Use drush config-set instead. This will not be validated.
1.2. Profile must be the same
1.2.1. If the profile is not the same, you cannot guarantee the codebase is the same.
1.3. There is no schema validation yet
2. Drush commands
2.1. drush config-edit
2.1.1. Opens up a system editor for the yaml
2.2. Drush config-set
2.3. Drush config export
2.3.1. Exports all config into Yam
2.3.2. drush cex
3. basics
3.1. If you never move you config from one site to another you will never need to use this feature.
3.2. what is config
3.2.1. A setting for the site and every instance of the site.
3.2.2. A view, content types, fields. Not generated by users.
3.2.3. What is not config?
3.2.3.1. Node, comments, users - content
3.2.3.2. State and cache
3.2.4. What about the 50% use case?
3.2.4.1. Taxonomy terms? Are they content or config. We have to make a call.
3.2.4.2. For core, the decision was made to make taxonomy content - have to support free tags.
3.3. Config storage
3.3.1. Config format decisions took way too long. It was not all that important.
3.3.2. Stored in table - config. Only one table. In D7 this was stored in bespoke tables, custom to each module. The Config table stores a name and serialized array.
3.3.3. 1 yaml file per config object.
3.4. Config deployment
3.4.1. method
3.4.1.1. You can choose how to get the config across sites. There was no workflow defined by Drupal. Drupal just provides an export. It is up to each project or team to develop their own best practices for getting config between sites.
3.4.1.2. If you are a single developer, it’s easy. Just tar it and copy it.
3.4.1.3. If you are a dev team, you need to use the same tools. Use git and manage the code review and merge process. When it’s in Git, you can just deploy as normal.
3.5. Types of config
3.5.1. simple config
3.5.1.1. The config table is exported to simple config
3.5.1.2. can only be one instance of a simple config in the site’s settings.
3.5.1.2.1. For example, you can only install a module once.
3.5.2. config entity
3.5.2.1. There can be many different instances of a config entity. You can only build the config entity when all the code is in place as they can pull in content. This is outside of the normal dependency management.
3.5.3. Only the simple config is installed on the config sync. Do not rely on config entities existing when you run your install hook.
3.6. What is exported
3.6.1. It’s a full site export.
3.6.1.1. if we don’t we have no way of detecting configuration deletes.
3.6.1.2. If we don’t have the full picture of the site, we can’t know what is supposed to be there.
3.6.2. Deploying config can break things. There is only some validation that is done, but there should be more.
4. bugs
4.1. Old bugs
4.1.1. Data being lost due to field deletions. Config should never cause data loss. Was being based on field names rather than UUIDs, led to problems when new fields were created that shared a name with a previously deleted field.
4.2. (Not CMI) There's a multilingual file counting bug in Drupal 8, the counting can go back to 0
4.2.1. Solve: Allow people to delete, rather than automatic.
4.2.2. Solve: Don't have a file counter
4.2.3. There's been a similar bug with images
4.2.4. Proposal: Don't use this on your site
5. config sync process
5.1. Module installation
5.1.1. Changes
5.1.1.1. Removal of disabled module state, tables there but its code not running, can’t react to events in your system. When modules get turned on and off, you will run into data integrity issues.
5.1.1.2. Do the numbers on the modules mean anything?
5.1.1.2.1. Numbers are module weight
5.1.1.3. Do modules get installed/uninstalled in the same way by config sync and any other method?
5.1.1.3.1. Almost. The config import does not use the default config from the module, otherwise all the rest of the steps are the same.
5.1.1.4. What happens if you install a new module?
5.1.1.4.1. New modules will install a new config object. This will allow the system to look at all the dependencies and make sure that they are satisfied.
5.1.1.5. How do we enforce dependencies when there is no implicit code dependency?
5.1.1.5.1. You can depend on themes, content and other config
5.1.1.5.2. Depending on config can allow you to depend on node types - so your view can add it’s dependency
5.2. Reviewing the changes
5.2.1. The config sync UI is in need of improvement.
5.3. Challenges
5.3.1. paragraphs
5.3.1.1. Paragraphs induced circular dependencies when using d8 features module. This meant that dependencies were not detected correctly. Different assumptions on packaging types are a challenge. Features is not effectively looking at content/code dependencies.
5.3.1.2. Paragraphs module makes sure that you delete content before removing the module. You need to do a hook update to remove content that is created by the module.
5.3.2. soft dependencies
5.3.2.1. Core config importer tries to make sure that content dependencies are soft. An event (IMPORT_MISSING_CONTENT) is fired when an event when something is missing. You would then be able to create a hook and generate default content when needed.
5.3.2.2. Views that depend on taxonomy terms will also impose a soft dependency on the term (content). You would then need to hook into this event. Content deployment is missing from core, so cannot be handled automatically yet. The same will apply to menus - which are content, but define structure.
5.3.2.3. All content dependencies should be soft. We could use some better reporting on these missing elements. The dependency is based on the UUID, you will be able to implement some plan to find this element if you wanted to. Without default content in core, there is no standard way to do this yet.
5.3.3. Default content
5.3.3.1. There is a default_content module in d8, but it is not core.
5.3.3.2. WIthout default content there are many problems that cannot be solved. We cannot have a working site out of the box.
6. experiences
6.1. CA has been using CMI for 6 months
6.1.1. Initially tried to use features
6.1.1.1. Things got broken and we found circular dependencies.
6.1.2. Building on a site created by external agency
6.1.2.1. initially working with full tarball of config
6.1.3. Now using a sync folder outside of the devroot
6.1.3.1. have been using a module to automatically export
6.1.3.1.1. config_tools
6.1.3.2. Saves some basic commands
6.1.3.2.1. Simplify the process to get more new team members on board
6.1.3.2.2. This has added some of the wrong files
6.1.3.3. Has made code review difficult as the file formats have seemed to be diferent
6.1.3.3.1. Have been having issues with file formats not being consistent
6.1.3.3.2. The yaml config itseld seems to change
6.1.3.4. Does the automatic export break the mental model for preparing config?
6.1.3.4.1. If things are automatically exported I don't have the time to prepare my commits for peer review
6.1.3.4.2. To make peer review easier, it is good to commit at stages.
6.1.3.4.3. If there is an automatic export, you are not in control of the commit process. So there is no clear way to review what has been done.
7. Drupal basics
7.1. Make sure that modules have tests
7.1.1. If a module does not have tests you don't know what is happening
7.1.2. Are you willing to write your own tests?
7.1.3. If it's just decorative, then tests may not be critical
7.1.4. A module that changes basic configuration processes needs testing
7.1.5. There is an Automated Testing tab on d8 modules. Look at the test results.
7.1.5.1. Test types in d8
7.1.5.1.1. simpletest
7.1.5.1.2. phpunit
7.1.5.1.3. all of these test types will be run on D.O,
7.1.5.2. Phpunit tests run very quickly
7.1.5.2.1. You can run them directly from within phpstorm
7.1.5.2.2. tests dont exist within the src folder
7.2. Try to script all your basic actions. Keep up good practice by making sure that you do all the essential actions when you need them.
7.3. Shield icon by a module
7.3.1. Means stable release. Covered by security advisory. If it has a security issue, it will be reported and fixed in private by/with security team then a fix will come out on a specified date.
8. Getting a site to accept config
8.1. config installer (sort of install profile)
8.1.1. injects itself into install process
8.1.1.1. lets us upload config
8.1.1.1.1. doesn't run a standard install, runs a config import. can't mismatch UUID or profile.
8.1.2. avialable at 'Configuration Installer' on drupal.org
8.2. Config install based install profile
8.2.1. solves the problem: how do I create a new instance of my site
8.2.2. make a specially prepared install profile for your project
8.2.2.1. Can have configuration as part of an install profile
8.2.3. exports are written into the profile config sync dir
8.2.3.1. any updates to the base site update the profile
8.2.3.2. Keeps your profile up to date dynamically
8.2.4. patch in core - not standard yet
8.2.4.1. requires some code in install file
8.2.5. validates module dependencies
8.2.6. There's a talk online from Drupalcon New Orleans demoing and discussing this
9. CA Summary of new workflow
9.1. drush cex with skip modules in bash profiles
9.1.1. careful of bugs in skip modules
9.1.1.1. customise scripts as you experience problems
9.2. Get git commits packaged up - eg do config files just before pull requests
9.3. try active config tools with the new patch
9.4. package up modules that are not for config into a feature, then switch off feature?
9.5. won't see yaml files in commits unless they are exported
9.5.1. will say what's changed, get chance to review changes
9.6. config tool encourages you to just create a commit, devs need to review changes that have been made
10. questions
10.1. should we be using tools like config split to separate config into different sections?
10.1.1. no, try to build groups of related changes, treat it like code
10.2. Do you get warned when importing if eg. a module is missing from the codebase?
10.2.1. If it can't import because of something like that, it won't allow import, needs to pass error checking before import is allowed to happen
10.2.1.1. It reports to the screen what the exact problem is
10.2.2. In future
10.2.2.1. might check if you're running same Drupal code version, eg. 8.2. For core and contrib modules
10.2.2.2. Validates if a database update needs doing
10.3. Where to store config directory - security wise
10.3.1. Only allow webserver to access certain files, prevent it accessing yaml files
10.3.2. there are some scripts available where all code is outside the webroot
10.3.3. Moving all PHP files outside of docroot
10.3.3.1. node/2767907
10.3.3.2. Do this for security
10.3.3.3. We need asset transportation to work this out well
10.3.3.4. config_install rather than 'true' have path pointing out
10.3.4. There isn't a generic approach to security in PHP
10.3.4.1. Composer can bring in issues
10.4. People coming from Features, not sure how to approach CMI concerning modules that should be dev only
10.4.1. Do we level things? ie. how do we split config?
10.4.2. We should have ability to opt out from config, eg make devel not enabled on prod
10.4.2.1. should have ability to opt out from config
10.4.2.2. Per environment settings?
10.4.2.2.1. environment config:
10.4.2.2.2. config split
10.4.2.3. We should have it so that modules can be marked as development modules
10.4.2.4. we want to be able to have site modes
10.4.2.4.1. dev/ prod / etc
10.5. Are API keys config?
10.5.1. Stored not in config, or secure unreadable config
10.5.1.1. drupal does not yet have secure config
10.5.2. use an override in settings.php
10.5.2.1. call different sub files
10.5.2.2. set environment variable in apache
10.5.2.3. and apache environment variables
10.6. config file anomoly
10.6.1. eg image field with hidden title, when was pushed to prod in config it was no longer hidden
10.6.1.1. Showed that config was imported correctly
10.6.1.2. Might have been part of the problem / bug that CA was experiencing concerning yaml files
10.7. How to manage config files that are a mix of dev-oriented (eg field def) and that done by site editor (eg contact form email)?
10.7.1. Where site editor is editing on live site
10.7.1.1. Dev has responsibility
10.7.1.1.1. Bring db back, reg export config
10.7.1.1.2. Treat 'live' like another developer, need to manage changes made there
10.7.1.1.3. Dev takes on the complexity of a live site
10.7.1.2. Where do you want to put control?
10.7.1.2.1. Need an environment where this is managed
10.7.1.3. These changes - how much are they config and how much are they something else?
10.7.1.4. Configuration management - Prevent importing to a site that's been imported to before that has had changes - lets you know live changes have happened
10.7.1.5. There is a config read only module that locks down live changes
10.7.1.6. Config override system
10.7.1.6.1. Would be possible to have a live config override that saves config into a different config 'live config', any config import wouldn't be interested in this 'live config'
10.7.1.7. System sites file
10.7.1.7.1. Can set config overrides, eg to site name,
10.8. features in d8
10.8.1. is a module builder
10.8.1.1. config that you want to share
10.8.2. it's possible to have software that builds graph of your config and dependecies, relationships
10.8.2.1. should be able to group config better than ever before
10.9. ensuring certain settings don't get pushed into git and deployed, e.g. stage_file_proxy
10.9.1. provide config export command rather than using other module
10.9.1.1. Using drush: --skip-modules
10.9.1.1.1. lets you skip, eg. devel module
10.9.1.1.2. still sometimes kicks out config?
10.9.1.1.3. store lists of modules in a script, have custom drush commands
10.9.1.1.4. what happens if you skip views?
10.9.1.2. work on one thing in a branch, don't exclude something because you'll be working on it later
10.9.1.3. use git ignore?
10.9.1.3.1. This doesn't fit core extension problem
10.9.1.4. Web hooks for environment?
10.9.1.4.1. eg like web hooks from Acquia
10.9.1.4.2. How does it switch off the modules?
10.9.1.5. Some people are writing config split modules, but not many ready, can be convoluted and present instability
10.9.1.6. Can it be in settings file?
10.9.1.6.1. But first of all modules need to be able to opt out, eg Devel
10.9.1.7. Have to think about dependencies
10.9.1.8. Dealing with this problem
10.9.1.8.1. 1. Get list of things that mention module
10.9.1.8.2. 2. What's in config itself
10.9.1.8.3. 3. Core extension
10.9.1.9. At the moment, many people are removing a module before doing config
10.9.1.9.1. What about its settings?
10.9.1.9.2. Might forget to
10.9.2. This is a problem that needs fixing
10.10. Any plans on exporting single components? If one day we could do something like: drush cex views.machine-name-of-my-view ?
10.10.1. In the UI there are options for this
10.10.1.1. Can do this on prod site?
10.10.2. do config edit in drush, then can write it to anywhere you want, including a module
10.10.3. Issue: Would this be too granular?
10.10.4. How about a module that gives you ability to create patch of difference between your dev and prod configs
10.11. With install profile
10.11.1. We discussed this earlier (find it in mindmap and link it here with an arrow)
10.12. Recommended workflow: we're currently using active config file handling to automatically export CM without using drush cex but not git config for auto commit
10.13. in the future media entity will be included
10.13.1. we should have a decent media browser in core
10.13.2. needs UX and design considerations
10.14. how best to handle mixed config and 'content' - e.g. when adding new blocks we find we have to manually create the block content, but disable, then duplicate on local to create config, which then gets deployed. Similarly with taxonomy terms and menu items. Similarly paragraphs tend to create default content entities, which does not allow config to be deleted.
10.14.1. try to use modules to manage the content, eg default content
10.14.2. there's not a generic solution yet
10.14.3. Can we expand on event dispatcher?
10.14.3.1. Want to deploy vocab terms as part of deployment strategy
10.14.3.1.1. look at default content module
10.14.3.1.2. deploy, run updatedb, config importer, default config import?
10.14.3.1.3. keep content and config layers separate
10.14.4. entity reference fields - reference nodes of same type and has default value. Can't create node before the entity reference field exists.
10.14.4.1. be careful of getting self-referential loops in code