Voting starts in March for the Drupal Association Board election.
- Too many interdependencies between the base system and the module/hook system, especially in the System module:
- bootstrap levels prior to DRUPAL_BOOTSTRAP_FULL
- registry (class autoloader)
- cache system
- most other subsystems
- Too many interdependencies between modules.
- Some base system features are not really required to run Drupal, but there is no way to remove them from loading without hacks (altering them out etc.)
- Some "required" modules are actually not required to run Drupal (e.g., Node), but there is no way to remove them without hacking core.
- Overloaded System module.
- Low-level subsystems cannot be fixed or refactored without simultaneously refactoring others.
- New dependencies are added without proper documentation or considerations about consequences.
- Many chicken and egg situations where dependencies are recursive/mutual.
- Large runtime code-weight for rarely or never used features.
- Inability to unit-test most subsystem code, since dependencies cannot be mocked.
- Core include files: Files in /includes/*.
- Module system: the ability to load modules and invoke/define hooks.
- There should be a clear dependency chain without recursion or mutual dependencies (file A and file B should not both depend on each other, nor module A and module B).
- Functionality that is early in the Drupal bootstrap process should not depend on functionality that comes later in the process.
- Functionality in core include files should never depend on functionality in modules or on the module system.
- Functions related to one purpose should be grouped/isolated/encapsulated into one file.
- Files that contain functionality that is not really required to run Drupal should not be automatically loaded on every site, but should be in optional modules or classes that can be auto-loaded/enabled when needed.
- All files should use a consistent, unique namespace for their functions (even include files).
(many of these are closely related, there are a lot of ways to cut spaghetti)
- Remove dependencies between include files. E.g., module.inc and theme.inc can both depend on another include file, but not on each other.
- Remove dependency on the module system from core include files.
- Remove dependencies between modules by making a new module that both can depend on, or by making the dependency one-way.
- Regroup core include files into coherent groups of functions related to the same functionality.
- Move functionality that depends on the module system into modules.
- Move functionality that is in include files, but not required to run Drupal, into a module (or a stand-alone class).
- Move functionality out of System module that is not required to run Drupal.
- Move functionality in modules that does not depend on the module system into stand-alone classes.
- Move hard-coded required modules into installation profiles and make them optional.
- Rename functions in core include files to use corresponding namespace; e.g., module.inc uses module_*().
- Perform very closely related dependency resolutions, fixes, conversions, and clean-ups.
See also issue tag queue: http://drupal.org/project/issues/search?issue_tags=Framework%20Initiative
- We may add new modules with no administration screens; the modules screen and help system are not well suited for this yet.
- [possibly more to come]
- This is a lot of work, we need help!
What this is not
We are NOT talking about the following:
- removing modules from core
- having a separate 'framework' download from the Drupal CMS.
However if you are interested in these topics, then you want to help this effort, because it will make those topics possible, whereas they are currently not.
- Proper unit-tests for subsystems in core can be written.
- Faster resolution times for critical bugs: they can be fixed in an isolated way.
- Simpler to backport functionality to previous versions, since it's better encapsulated.
- Ability to use parts of core as components in other applications.
- Ability to incorporate components from other libraries and PECL more easily (e.g., Zend framework/Symfony3).
- Ability to omit unneeded functionality instead of altering away or hacking it out.
- Ability to build our own PECL extensions for low-level subsystems to replace user-space code with C (optionally).
How does this fit with other initiatives?
The WSCCI and CMI initiatives aim to modernize outdated parts of core. They are mainly aiming to do so 'from the ground up'. However there is a lot of low hanging, large, and very smelly fruit between the ground and the sky.
How can I help?
If you are subscribing to this issue and want to help, note that there is a very long list of issues linked from the opening post that are dying out for reviews, re-rolls or initial patches so it should be easy enough to find somewhere to start.
If after looking at that list you don't know where to start, grab catch on IRC (#drupal-contribute), or just ask around, and we'll try to help you find something.