1. CMI feedback
● D.org config API overview / summary
● Demo / Examples
– Custom Config + Translation
– Environement specific (overrides + splits)
● Configuration by multisite
(site specific names, core base field overrides)
– Override existing config by modules
– Install site from existing configuration
2. Configuration vs. other types of information
● Content - site editors
● Session - user's interactions with the site
● State - Change frequently, don't need to be
deployed
● Configuration - site builders, will be deployed
● Cache - Speed up data retrieval, Tags
invalidation, Contexts
3. Configuration Storage in Drupal 8
● YAML format
● Has a schema metadata
● The site syncronize directory
– Defined in settings.php (ex. sites/default/config/sync)
– Or outside of the webroot
$config_directories[CONFIG_SYNC_DIRECTORY] = '../config/default/sync';
– Active configuration: in the database
– File system based workflow
● For modules (Only when the module is installed)
– config/install – module's installation fails if at least one of their
dependencies are not met.
– config/optional – that configs are installed only if all their
dependencies are met.
4. Configuration override system
● About
– See d.org introduction
– Always overrides and is only for reading
– Merge Deep Array with preserve integer keys
● Global overrides
sites/default/settings.local.php or sites/default/settings.$env.php :
global $config;
$config['system.logging']['error_level'] = 'verbose';
● Language overrides (Configuration translation)
sites/default/config/sync/language/fr/user.role.anonymous.yml :
label: 'Utilisateur anonyme'
● Overrides from modules (For custom purpose)
sites/default/config/sync/system.site.yml :
page:
front: /user
5. Configuration schema/metadata
● Cheat sheet
●
Each module define the type of the configuration it
ships with – config/schema/modulename.schema.yml
● See also core shema files - system.schema.yml,
core.data_types.schema.yml
● Used for
– multilingual support, translation forms for configuration
– the default persistence implementation for configuration
entities requires a configuration schema
– typecast values to their expected types
● Properties
● For debug The configuration inspector module
6. Configuration
Entity vs. Simple
● Lists of things that users can
create and delete;
● Work fine whether there are 0 or
100+ (image styles, views, etc)
● Complete set of CRUD hooks
● Easier to implement
● Can only depend on the module
that provides it
● Configuration entity dependencies
– Dependency can be: module, theme or entity (content, config)
– Dynamic dependencies - If in a view has filter to show Article
nodes, then it will also gain a dependency on the Article
configuration (node.type.article)
– Dependencies must be installed before the configuration entity
can be installed
7. – Install my_prf profile
– Copy the source config/sync
directory
– Get database uuids
– Import Configuration
● Configuration management UI, drush
● Config Override
– Environment (and/or multisite) overrides + splits
– Override existing configs by modules
● Config example module
– Working with Configuration Forms
– Defining and using your own configuration
– Translating configuration
● Allow a site to be installed from existing configuration
Until done:
– Create my_prf profile with just my_prf.info.yml. Use
core/profiles/minimal/minimal.info.yml as example
– Add as dependencies all modules from the source site
core.extension.yml.
8. Configuration Split
● Split means in some way like a partial
● Sets of configuration (a split) that will get exported to separate
directories when exporting, and get merged together when
importing
● Blacklist
– Configs and/or module's configs will be removed from the sync
directory to the split directory. Example of devel module with all his
configs (including the entry in core.extension)
● Greylist
– Configs will be copied (the current database value) to the split
directory and will not be removed from the sync directory
– Option to include dependant configs
– Option to split only when different (Excluded environment)
● Advanced Configuration Management (CMI) Workflows
9. Environment export to sync
● Splits are used for adding "dev" new files (ex. devel related configs)
● Overrides are used for "dev" specific config changes
– "dev" external services uris, site mail address
– "prd" changes go to config/sync.
– Use empty config file to delete it from "dev"
● Compare from backuped sync to
– Exported in split, from database values
– Applied overrides on sync
● Compare each other: the database version and the override
version of the environment specific configs
● Create splits, overrides from remote (ex. integ, ppd)
– Import the remote database
– Export for diff config/diff/integ
– The same way that for "dev" specifics
10. Environment import
● Local : Import with only "dev" split enabled, after "dev" overrides and
db uuids have been applied on sync
– Clean sync from overrides and/or uuids
● Remote (ex. not dev)
– Import with "integ" and "excluded" splits enabled after "integ" overrides and
db uuids have been applied
– Will drop configs from other disabled splits (ex. devel ones)
● Intended for "prd"
– Import with only "excluded" split enabled after db uuids have been applied
– No sense of "prd" split, nor "override" : the sync is intended for "prd"
● Remote delivery with keeping BO changes
– Define menus (system.menu.*) as client side configs
– Export excluded split before config files delivery (only when different)
– Import will not replace the menus user changes
– Config not in excluded will be imported
12. Configurations by modules
● Using Features Module
– Use features for packaging reusable components
– Use CMI for deployment : local (dev) => remote (live)
● Using the config override system.
– For existing configs use my_module/config/override
– For new configs, use my_module/config/install
– Get configuration from updated modules and profiles
● for import write the module's install configs (and the module's
optional ones if exist in sync) to sync then apply all modules'
overrides
● Compare (instead to write to) config/sync version of module's
configs with applied all modules' overrides (written to --destination)
to module's config (my_module/condfig)
– Feature module to export the database version - with
disabled module's overrides
13. See also
● Configuration Synchronizer
– Safely importing site configuration from updated modules, themes,
or distributions.
– requires Configuration Update Manager (like features)
● Configuration development
– auto import (into the active storage ) / export (configuration
objects into files)
– import automatique des yml du config/install (between the active
storage and exported modules)
● Configuration Tools
– Stores your current active configuration as yml in a specified
directory
– Auto commits changes to your configuration
● ...
