4. CONFIG MANAGEMENT IN
D8
This talk is based on my own experiments
...and kind of pretending they’re done :-)
5. CONFIG MANAGEMENT IN
D8
This talk is based on my own experiments
...and kind of pretending they’re done :-)
https://github.com/tizzo/system_settings
13. Current Pain
No way to store data centrally without loading on every page
No central API for exporting (though ctools can provide most of
the plumbing)
14. Current Pain
No way to store data centrally without loading on every page
No central API for exporting (though ctools can provide most of
the plumbing)
No way to know about configuration (or content) dependencies
26. Relations
Allow settings to be associated with each other, and other things
throughout the system
Currently there are 3 relations
27. Relations
Allow settings to be associated with each other, and other things
throughout the system
Currently there are 3 relations
Entity
28. Relations
Allow settings to be associated with each other, and other things
throughout the system
Currently there are 3 relations
Entity
Groups
29. Relations
Allow settings to be associated with each other, and other things
throughout the system
Currently there are 3 relations
Entity
Groups
Modules (and themes)
32. Entity
Bad name (not an entity API entity)
Identifies a “thing” with a “type” and an “name”
33. Entity
Bad name (not an entity API entity)
Identifies a “thing” with a “type” and an “name”
Tracks
34. Entity
Bad name (not an entity API entity)
Identifies a “thing” with a “type” and an “name”
Tracks
requirement relationships between other settings (and maybe
even content?)
39. Groups
Essentially just “tags”
Allows you to get all of the settings from a given form, etc.
Allow hierarchy
Commerce => Payment Gateways => Authorize.net
45. Modules (And Themes)
Track dependencies
requires
required by
Register update callbacks
Allows module to say “when this changes, please let me know”
50. Settings Log
Records all settings changes: old setting & new setting
Serially increments
Log position stored in settings api (separate from the log)
51. Settings Log
Records all settings changes: old setting & new setting
Serially increments
Log position stored in settings api (separate from the log)
This lets us sync the log and then run update.php to apply
them until we’re back in line
54. New Interaction Models
Replay settings changes (every change can be replayed one after
another)
One way sync from dev to staging, move the log and run
update
55. New Interaction Models
Replay settings changes (every change can be replayed one after
another)
One way sync from dev to staging, move the log and run
update
Settings are replayed one by one, callbacks fired if necessary
56. New Interaction Models
Replay settings changes (every change can be replayed one after
another)
One way sync from dev to staging, move the log and run
update
Settings are replayed one by one, callbacks fired if necessary
Work offline and then “push” every settings change that you
haven’t yet modified to the central system (either over services or
putting config in code)
60. The Final Frontier
Features-like system for exports in core
“Locked” sites where settings can’t be changed all “clicky
clicky”
Perhaps “locked” settings can’t be changed all “clicky clicky”?
61. The Final Frontier
Features-like system for exports in core
“Locked” sites where settings can’t be changed all “clicky
clicky”
Perhaps “locked” settings can’t be changed all “clicky clicky”?
Settings replication over web services
62. The Final Frontier
Features-like system for exports in core
“Locked” sites where settings can’t be changed all “clicky
clicky”
Perhaps “locked” settings can’t be changed all “clicky clicky”?
Settings replication over web services
“Push” settings from one site to another
63. The Final Frontier
Features-like system for exports in core
“Locked” sites where settings can’t be changed all “clicky
clicky”
Perhaps “locked” settings can’t be changed all “clicky clicky”?
Settings replication over web services
“Push” settings from one site to another
Relations “Masks” to export “slices” of configuration
67. Known (expected) Issues
Requirements on a specific value instead of on a value existing
Preventing deployment if stuff is missing
Conflict resolution (if we try to “magically” move things around)
68. Known (expected) Issues
Requirements on a specific value instead of on a value existing
Preventing deployment if stuff is missing
Conflict resolution (if we try to “magically” move things around)
This doesn’t. Settings are atomic and if one thing sets a
setting and another changes it, it has been changed.
69. Known (expected) Issues
Requirements on a specific value instead of on a value existing
Preventing deployment if stuff is missing
Conflict resolution (if we try to “magically” move things around)
This doesn’t. Settings are atomic and if one thing sets a
setting and another changes it, it has been changed.
System currently puts all settings in a single db table (harder to
read & maintain... performance concerns...)