Dries Buytaert wrote:
Yes. In fact, I beleive the only solution is the other way around: Release with less stuff in core. The less changes, the easier it is to keep in pace with all our contribs. And in the same time, put less pressure on upgrading. If stuff (contribs) is not ready, we should not tell people to upgrade.
We had this discussion before, and I still disagree. I believe that CCK+view is what the next generation of open source CMSes will look like. They have the potential of being the heart of Drupal. For Drupal to get to the next level, they have to be in core so that everyone can rely on it as well as build on it.
This particular field feature, however requires a big rewrite for CCK, again. If CCK would do it *properly* (see above), it would mean a big rewrite to remove of one of the core concepts in CCK: making nodes. I suspect this might mean a complete rewrite, after all.
Please elaborate. What would you rewrite, and why? What is not properly done in core that is a showstopper for full CCK support?
This is what an offhand look at content.module suggest needs to be done to me... 1) Everything done in content.module to date as far as node type creation needs to be stripped out. 2) the field specific menu items needs to be integrated with the new node.module menu. 3) content_node_info, content_access go the way of the dodo, superceeded in node.module 4) integrate content.modules node hooks using hook_nodeapi 5) titles on forms need to be moved into node.module, and out of content type modules.(seems like they already should be but page.module sets $form['title'] along with the other node type modules. There a no show stoppers here, except maybe removing title fields from the forms in node type modules since they are handled by hook_node_info && node.module sets the label accordingly.
So this leaves us a long period in 4.8 with 1) a hacked up, patched up flexinode and 2) a heavy under development replacement for it, CCK. None of wich I would advice any (sane) person on his/her production site. Result: another release without a production-ready system for dynamically build (with fields) nodes.
Note that there are 3 systems here: (i) flexinode, (ii) contrib CCK and (iii) core CCK.
I can't speak for (i) or (ii) but if they are "hacked up" then their maintainers are to blame -- at least to a certain extend. I can only speak for (iii), and I think you're overly pessimistic about it.
1. We made an almost insane amount of progress since Drupal 4.7, and we might make more progress by the time we freeze the code. (Go folks, go!)
2. The lightweight CCK that is in core is fully functional. Sure, you can't add extra fields yet but there are many valid use cases where you don't need additional fields.
the important part of cck is that you can have fields... right now you just have flexible node naming and node type creation.
3. It is probably at least another 2 months until Drupal 4.8/5.0 gets released. That means that there is plenty of time left to fix (i) and (ii), and to a lesser extend (iii). It's only 3 months since we released Drupal 4.7, and it is another 2 months until we might release Drupal 4.8/5.0. maybe fields.module will be working by then... I'll see if I can get a head ready field.module together today if JonBob hasn't already.
4. The work we have done in CVS HEAD should be beneficial for (i) and (ii) so I'd like to believe that these modules become less "hacked up". I don't think there was enough public communication between the people working on cck and cck's inclusion in core, to allay FUD. I had a lot of it until I just dug into content.module to see how the changed in core actually affected it, and how hard they would be in to intgrate, and its not as bad as I suspected.. There still remains a question of whether we modify node_load to contain content.modules node hooks, or do it through nodeapi.... integrating it all into node, would make core a bit fatter, but would get rid of a layer of inner loops. My personal opinion is let field.module live on its own using node api until field type modules mature. We can look at moving the rest into core after the next release if it's deemed a good idea.
I don't see this as a reason for postponing a code freeze. But I do see this as a reason for concern in a more general way. Especially since the problem seems to become structural. with the rapid growth of Drupal one would expect the overal quality, amount and feature-richness of contribs and themes to improve. I don't see this happening ATM! discussion at drupalcon? Its no reason to stop the code freeze, but some 'improvements' may appear to be hinderances. Especially since no one to date has taken the time to express to the community as a whole how simple the modifications required to content.module to create field.module really are.
.darrel.