Drupal 8 CMI Masterclass

Get Started. It's Free
or sign up with your email address
Rocket clouds
Drupal 8 CMI Masterclass by Mind Map: Drupal 8 CMI Masterclass

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. questions

5.1. should we be using tools like config split to separate config into different sections?

5.1.1. no, try to build groups of related changes, treat it like code

5.2. Do you get warned when importing if eg. a module is missing from the codebase?

5.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

5.2.1.1. It reports to the screen what the exact problem is

5.2.2. In future

5.2.2.1. might check if you're running same Drupal code version, eg. 8.2. For core and contrib modules

5.2.2.2. Validates if a database update needs doing

5.3. Where to store config directory - security wise

5.3.1. Only allow webserver to access certain files, prevent it accessing yaml files

5.3.2. there are some scripts available where all code is outside the webroot

5.3.3. Moving all PHP files outside of docroot

5.3.3.1. node/2767907

5.3.3.2. Do this for security

5.3.3.3. We need asset transportation to work this out well

5.3.3.4. config_install rather than 'true' have  path pointing out

5.3.4. There isn't a generic approach to security in PHP

5.3.4.1. Composer can bring in issues

5.4. People coming from Features, not sure how to approach CMI concerning modules that should be dev only

5.4.1. Do we level things? ie. how do we split config?

5.4.2. We should have ability to opt out from config, eg make devel not enabled on prod

5.4.2.1. should have ability to opt out from config

5.4.2.2. Per environment settings?

5.4.2.2.1. environment config:

5.4.2.2.2. config split

5.4.2.3. We should have it so that modules can be marked as development modules

5.4.2.4. we want to be able to have site modes

5.4.2.4.1. dev/ prod / etc

5.5. Are API keys config?

5.5.1. Stored not in config, or secure unreadable config

5.5.1.1. drupal does not yet have secure config

5.5.2. use an override in settings.php

5.5.2.1. call different sub files

5.5.2.2. set environment variable in apache

5.5.2.3. and apache environment variables

5.6. config file anomoly

5.6.1. eg image field with hidden title, when was pushed to prod in config it was no longer hidden

5.6.1.1. Showed that config was imported correctly

5.6.1.2. Might have been part of the problem / bug that CA was experiencing concerning yaml files

5.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)?

5.7.1. Where site editor is editing on live site

5.7.1.1. Dev has responsibility

5.7.1.1.1. Bring db back, reg export config

5.7.1.1.2. Treat 'live' like another developer, need to manage changes made there

5.7.1.1.3. Dev takes on the complexity of a live site

5.7.1.2. Where do you want to put control?

5.7.1.2.1. Need an environment where this is managed

5.7.1.3. These changes - how much are they config and how much are they something else?

5.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

5.7.1.5. There is a config read only module that locks down live changes

5.7.1.6. Config override system

5.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'

5.7.1.7. System sites file

5.7.1.7.1. Can set config overrides, eg to site name,

5.8. features in d8

5.8.1. is a module builder

5.8.1.1. config that you want to share

5.8.2. it's possible to have software that builds graph of your config and dependecies, relationships

5.8.2.1. should be able to group config better than ever before

5.9. ensuring certain settings don't get pushed into git and deployed, e.g. stage_file_proxy

5.9.1. provide config export command rather than using other module

5.9.1.1. Using drush:  --skip-modules

5.9.1.1.1. lets you skip, eg. devel module

5.9.1.1.2. still sometimes kicks out config?

5.9.1.1.3. store lists of modules in a script, have custom drush commands

5.9.1.1.4. what happens if you skip views?

5.9.1.2. work on one thing in a branch, don't exclude something because you'll be working on it later

5.9.1.3. use git ignore?

5.9.1.3.1. This doesn't fit core extension problem

5.9.1.4. Web hooks for environment?

5.9.1.4.1. eg like web hooks from Acquia

5.9.1.4.2. How does it switch off the modules?

5.9.1.5. Some people are writing config split modules, but not many ready, can be convoluted and present instability

5.9.1.6. Can it be in settings file?

5.9.1.6.1. But first of all modules need to be able to opt out, eg Devel

5.9.1.7. Have to think about dependencies

5.9.1.8. Dealing with this problem

5.9.1.8.1. 1. Get list of things that mention module

5.9.1.8.2. 2. What's in config itself

5.9.1.8.3. 3. Core extension

5.9.1.9. At the moment, many people are removing a module before doing config

5.9.1.9.1. What about its settings?

5.9.1.9.2. Might forget to

5.9.2. This is a problem that needs fixing

5.10. Any plans on exporting single components? If one day we could do something like: drush cex views.machine-name-of-my-view ?

5.10.1. In the UI there are options for this

5.10.1.1. Can do this on prod site?

5.10.2. do config edit in drush, then can write it to anywhere you want, including a module

5.10.3. Issue: Would this be too granular?

5.10.4. How about a module that gives you ability to create patch of difference between your dev and prod configs

5.11. With install profile

5.11.1. We discussed this earlier (find it in mindmap and link it here with an arrow)

5.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

5.13. in the future media entity will be included

5.13.1. we should have a decent media browser in core

5.13.2. needs UX and design considerations

5.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.

5.14.1. try to use modules to manage the content, eg default content

5.14.2. there's not a generic solution yet

5.14.3. Can we expand on event dispatcher?

5.14.3.1. Want to deploy vocab terms as part of deployment strategy

5.14.3.1.1. look at default content module

5.14.3.1.2. deploy, run updatedb, config importer, default config import?

5.14.3.1.3. keep content and config layers separate

5.14.4. entity reference fields - reference nodes of same type and has default value. Can't create node before the entity reference field exists.

5.14.4.1. be careful of getting self-referential loops in code

6. config sync process

6.1. Module installation

6.1.1. Changes

6.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.

6.1.1.2. Do the numbers on the modules mean anything?

6.1.1.2.1. Numbers are module weight

6.1.1.3. Do modules get installed/uninstalled in the same way by config sync and any other method?

6.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.

6.1.1.4. What happens if you install a new module?

6.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.

6.1.1.5. How do we enforce dependencies when there is no implicit code dependency?

6.1.1.5.1. You can depend on themes, content and other config

6.1.1.5.2. Depending on config can allow you to depend on node types - so your view can add it’s dependency

6.2. Reviewing the changes

6.2.1. The config sync UI is in need of improvement.

6.3. Challenges

6.3.1. paragraphs

6.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.

6.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.

6.3.2. soft dependencies

6.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.

6.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.

6.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.

6.3.3. Default content

6.3.3.1. There is a default_content module in d8, but it is not core.

6.3.3.2. WIthout default content there are many problems that cannot be solved. We cannot have a working site out of the box.

7. experiences

7.1. CA has been using CMI for 6 months

7.1.1. Initially tried to use features

7.1.1.1. Things got broken and we found circular dependencies.

7.1.2. Building on a site created by external agency

7.1.2.1. initially working with full tarball of config

7.1.3. Now using a sync folder outside of the devroot

7.1.3.1. have been using a module to automatically export

7.1.3.1.1. config_tools

7.1.3.2. Saves some basic commands

7.1.3.2.1. Simplify the process to get more new team members on board

7.1.3.2.2. This has added some of the wrong files

7.1.3.3. Has made code review difficult as the file formats have seemed to be diferent

7.1.3.3.1. Have been having issues with file formats not being consistent

7.1.3.3.2. The yaml config itseld seems to change

7.1.3.4. Does the automatic export break the mental model for preparing config?

7.1.3.4.1. If things are automatically exported I don't have the time to prepare my commits for peer review

7.1.3.4.2. To make peer review easier, it is good to commit at stages.

7.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.

8. Drupal basics

8.1. Make sure that modules have tests

8.1.1. If a module does not have tests you don't know what is happening

8.1.2. Are you willing to write your own tests?

8.1.3. If it's just decorative, then tests may not be critical

8.1.4. A module that changes basic configuration processes needs testing

8.1.5. There is an Automated Testing tab on d8 modules. Look at the test results.

8.1.5.1. Test types in d8

8.1.5.1.1. simpletest

8.1.5.1.2. phpunit

8.1.5.1.3. all of these test types will be run on D.O,

8.1.5.2. Phpunit tests run very quickly

8.1.5.2.1. You can run them directly from within phpstorm

8.1.5.2.2. tests dont exist within the src folder

8.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.

8.3. Shield icon by a module

8.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.

9. Getting a site to accept config

9.1. config installer (sort of install profile)

9.1.1. injects itself into install process

9.1.1.1. lets us upload config

9.1.1.1.1. doesn't run a standard install, runs a config import. can't mismatch UUID or profile.

9.1.2. avialable at 'Configuration Installer' on drupal.org

9.2. Config install based install profile

9.2.1. solves the problem: how do I create a new instance of my site

9.2.2. make a specially prepared install profile for your project

9.2.2.1. Can have configuration as part of an install profile

9.2.3. exports are written into the profile config sync dir

9.2.3.1. any updates to the base site update the profile

9.2.3.2. Keeps your profile up to date dynamically

9.2.4. patch in core - not standard yet

9.2.4.1. requires some code in install file

9.2.5. validates module dependencies

9.2.6. There's a talk online from Drupalcon New Orleans demoing and discussing this

10. CA Summary of new workflow

10.1. drush cex with skip modules in bash profiles

10.1.1. careful of bugs in skip modules

10.1.1.1. customise scripts as you experience problems

10.2. Get git commits packaged up - eg do config files just before pull requests

10.3. try active config tools with the new patch

10.4. package up modules that are not for config into a feature, then switch off feature?

10.5. won't see yaml files in commits unless they are exported

10.5.1. will say what's changed, get chance to review changes

10.6. config tool encourages you to just create a commit, devs need to review changes that have been made