Drupal 8 CMI Masterclass

Get Started. It's Free
or sign up with your email address
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? Node, comments, users - content State and cache

3.2.4. What about the 50% use case? Taxonomy terms? Are they content or config. We have to make a call. 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 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. If you are a single developer, it’s easy. Just tar it and copy it. 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 The config table is exported to simple config can only be one instance of a simple config in the site’s settings. For example, you can only install a module once.

3.5.2. config entity 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. if we don’t we have no way of detecting configuration deletes. 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 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. Do the numbers on the modules mean anything? Numbers are module weight Do modules get installed/uninstalled in the same way by config sync and any other method? Almost. The config import does not use the default config from the module, otherwise all the rest of the steps are the same. What happens if you install a new module? 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. How do we enforce dependencies when there is no implicit code dependency? You can depend on themes, content and other config 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 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. 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 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. 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. 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 There is a default_content module in d8, but it is not core. 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 Things got broken and we found circular dependencies.

6.1.2. Building on a site created by external agency initially working with full tarball of config

6.1.3. Now using a sync folder outside of the devroot have been using a module to automatically export config_tools Saves some basic commands Simplify the process to get more new team members on board This has added some of the wrong files Has made code review difficult as the file formats have seemed to be diferent Have been having issues with file formats not being consistent The yaml config itseld seems to change Does the automatic export break the mental model for preparing config? If things are automatically exported I don't have the time to prepare my commits for peer review To make peer review easier, it is good to commit at stages. 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. Test types in d8 simpletest phpunit all of these test types will be run on D.O, Phpunit tests run very quickly You can run them directly from within phpstorm 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 lets us upload config 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 Can have configuration as part of an install profile

8.2.3. exports are written into the profile config sync dir any updates to the base site update the profile Keeps your profile up to date dynamically

8.2.4. patch in core - not standard yet 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 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 It reports to the screen what the exact problem is

10.2.2. In future might check if you're running same Drupal code version, eg. 8.2. For core and contrib modules 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 node/2767907 Do this for security We need asset transportation to work this out well config_install rather than 'true' have  path pointing out

10.3.4. There isn't a generic approach to security in PHP 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 should have ability to opt out from config Per environment settings? environment config: config split We should have it so that modules can be marked as development modules we want to be able to have site modes dev/ prod / etc

10.5. Are API keys config?

10.5.1. Stored not in config, or secure unreadable config drupal does not yet have secure config

10.5.2. use an override in settings.php call different sub files set environment variable in apache 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 Showed that config was imported correctly 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 Dev has responsibility Bring db back, reg export config Treat 'live' like another developer, need to manage changes made there Dev takes on the complexity of a live site Where do you want to put control? Need an environment where this is managed These changes - how much are they config and how much are they something else? Configuration management - Prevent importing to a site that's been imported to before that has had changes - lets you know live changes have happened There is a config read only module that locks down live changes Config override system 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' System sites file Can set config overrides, eg to site name,

10.8. features in d8

10.8.1. is a module builder config that you want to share

10.8.2. it's possible to have software that builds graph of your config and dependecies, relationships 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 Using drush:  --skip-modules lets you skip, eg. devel module still sometimes kicks out config? store lists of modules in a script, have custom drush commands what happens if you skip views? work on one thing in a branch, don't exclude something because you'll be working on it later use git ignore? This doesn't fit core extension problem Web hooks for environment? eg like web hooks from Acquia How does it switch off the modules? Some people are writing config split modules, but not many ready, can be convoluted and present instability Can it be in settings file? But first of all modules need to be able to opt out, eg Devel Have to think about dependencies Dealing with this problem 1. Get list of things that mention module 2. What's in config itself 3. Core extension At the moment, many people are removing a module before doing config What about its settings? 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 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? Want to deploy vocab terms as part of deployment strategy look at default content module deploy, run updatedb, config importer, default config import? 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. be careful of getting self-referential loops in code