1. System Settings API
A look at a draft API for storing System
Settings

2. There’s CODE!

3. There’s CODE!
• That’s gold right?

4. There’s CODE!
• That’s gold right?
• project as it stands now:

5. There’s CODE!
• That’s gold right?
• project as it stands now:
• http://github.com/tizzo/system_settings

6. There’s CODE!
• That’s gold right?
• project as it stands now:
• http://github.com/tizzo/system_settings
• mainly an alternative backend for
variable_set and variable_get

7. The Mission

8. The Mission
• Expand on the great work on exportables
by getting the system (or something
similar)

9. The Mission
• Expand on the great work on exportables
by getting the system (or something
similar)
• Make everything exportable by default

10. The Mission
• Expand on the great work on exportables
by getting the system (or something
similar)
• Make everything exportable by default
• Provide Drupal with a robust way to
identify and replicate features

11. Hierarchy

12. Hierarchy
• Settings can be specified in

13. Hierarchy
• Settings can be specified in
• hooks

14. Hierarchy
• Settings can be specified in
• hooks
• overridden in the database

15. Hierarchy
• Settings can be specified in
• hooks
• overridden in the database
• overridden again by alter_hooks

16. Hierarchy
• Settings can be specified in
• hooks
• overridden in the database
• overridden again by alter_hooks
• finally overridden in settings.php

17. Features

18. Features
• Everything exportable and overrideable

19. Features
• Everything exportable and overrideable
• Pluggable storage backend

20. Features
• Everything exportable and overrideable
• Pluggable storage backend
• Change management

21. Features
• Everything exportable and overrideable
• Pluggable storage backend
• Change management
• Rich settings metadata

22. Metadata

23. Metadata
• Metadata is stored so that settings can be
related to one another

24. Metadata
• Metadata is stored so that settings can be
related to one another
• We can identify all settings related to a
content type or to a given module

25. Metadata
• Metadata is stored so that settings can be
related to one another
• We can identify all settings related to a
content type or to a given module
• Settings no longer build up in the database
(settings no longer associated can be
purged)

26. Metadata

27. Metadata
• Metadata can be specified simply by
defining the unique key of the each entry
(either simple or compex)

28. Metadata Structure node
entities
view
commerce
modules
views
commerce_something commerce
groups
views
value

29. Metadata Structure node
• A single setting is
entities
view
atomic structured commerce
data and self modules
views
contained
commerce_something commerce
groups
views
value

30. Metadata Structure node
• A single setting is
entities
view
atomic structured commerce
data and self modules
views
contained
• Contains all of its
commerce_something commerce
groups
relations and its views
value
value

31. Metadata: An Individual
Relation
node
type
relation story
requires
required
by

32. Metadata: An Individual
Relation
node
• Each relation has a type
unique key (simple or
complex) and an relation story
arbitrary set of additional requires
data required
by

33. Change Monitoring

34. Change Monitoring
• Each time the cache is rebuilt a version of
each setting stored during the last cache
build is compared to the version generated
now

35. Change Monitoring
• Each time the cache is rebuilt a version of
each setting stored during the last cache
build is compared to the version generated
now
• If a change is detected (whether because of
code or database) callbacks can be
triggered to respond to the change