Following the design sprint, drawing on what we had discussed, Yves, Karen, and Nedjo tried to map out some of the structure of a core patch and the accompanying short and longer term changes to CCK fields.
Specifically, we discussed the following approach:
- In the immediate term, make small changes as feasible to facilitate longer term changes, e.g., move CCK modules into their own directories in CVS.
- Working in CCK HEAD or possibly a D6 branch, do as much as possible of the work of preparing the patch for core in the form of refactoring the CCK package. This should be possible because we are preparing a new set of APIs that will be isolated in their own files and won't immediately require large changes to existing Drupal core code. We avoid the work of rolling patch after patch.
Core patch structure
What concretely will a core patch look like?
- New required core API module, Field. While initially implemented for nodes, it is abstracted to facilitate later application to other entity types.
- Field types
- Could be implemented in a shared module, Field Types, with the various core field types in a single module. Alternately we stick with the current approach, one module per field type.
- Whether one or more modules, do they need to be required? Initial feeling is, many or most may need to be required.
- We could consider UI tweaks to the modules admin page to e.g. collect field type modules together.
Short term CCK steps
- Move all CCK modules to their own directories (except content?). Issue: http://drupal.org/node/218973.
- Branch 6.x
- Likely after branching, create new field module (in its own directory) and move field CRUD API from content module to field module. Content module eventually becomes a purely UI module.
- In Field module, implement
hook_nodeapi()as is currently done in CCK to implement fields CRUD. When we get to the point of a core patch, this hook implementation will be replaced by calls innode_load(),node_save(), etc.