Voting starts in March for the Drupal Association Board election.
- I possibly re-invented the wheel here, but wanted to focus on what makes sense for the new config design.
- Also, let's do before or after that, as it further simplifies system list handling.
- Essentially, this patch here doesn't try to paint lipstick on a pig, but starts to revamp the theme extension state from the reversed, lowest point in the system... (ZOMG... my eyes are still bleeding from the code I had to look through)
- config() does not load from or actively use the file system - but: it supports $conf as override.
- Separate config objects for modules and themes, since they're being used in different spots. Store the list of enabled modules / themes only as keys, the values are weights for modules, meaningless for themes. Most information comes from the modules themselves because system_list and system_get_module_info are already cached. So, there's no need to store information readily available anywhere. Store schema_version into the K-V store.
block: '-5' [...snip...] demo: '0' [...snip...] minimal: '1000'
stark: '1' bartik:: '1'
- There is also some overlap with — given that themes are handled almost identically to modules with this patch here, a generic extensions manager becomes a lot more simple + possible.
PASSED: [[SimpleTest]]: [MySQL] 42,090 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 42,094 pass(es). View
PASSED: [[SimpleTest]]: [MySQL] 42,084 pass(es). View
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/system/system.install. View