On 18 Aug 2006, at 02:29, Derek Wright wrote:
also, given that CCK in core is basically crippled as it stands (no fields) and yet CCK in contrib doesn't work w/ CCK in core, and flexinode isn't going to be ported to either 4.7 or 4.8 (according to ber), i have serious concerns about freezing. dynamic content types are essential for basically every real drupal site i'm dealing with. if core isn't going to provide fields, we absolutely *must* have a plan for working fields in 4.8 contrib (and further acknowledge that core basically requires contrib to be functional 95% of the time).
Imagine that the CCK was not in core, and that the CCK in contrib would continue to be crippled during the 4.8/5.0 period. That would be an even worse scenario, wouldn't it? It is pretty clear that getting a proper CCK implementation into core is a big task. It might not be apparent to some, but the past two years we've been slowly rewriting Drupal core around the CCK, and we're tackling one CCK hack/workaround after another. It all started with the forms API in Drupal 4.7; being able to extend and validate forms was a requirement for the CCK. Now, in Drupal 4.8/5.0 we'll have structured body arrays, required to properly output CCK node types. We're also shipping with basic (non- extensible) CCK types. Not to mention various of the smaller steps; the ability to rename the 'Title' field to give one example. Just like Drupal 4.7, Drupal 4.8/5.0 will be a huge step in the CCK's direction. We're paving the path and so far we've been good at it. :-) There is a certain irony in the fact that the contrib CCK might be broken. Normally, the size and the complexity of the contrib CCK should shrink and shrink until, ultimately, there is little or nothing left from the contrib CCK. As a result, it should become easier and easier to maintain. That said, I agree that the current situation is not optimal and that we'd greatly benefit from having basic support for CCK fields in core. The reality is that it will probably take another release to get it right, and that it will take several more releases to add polish. Of course, you never know. We still have two weeks left, and there is a lot that one can do in two weeks ... (It wouldn't be the first time this release cycle that Eaton, jaza or chx come forward with a big chunk of CCK code.) It is dangerous to postpone the code freeze in order to get more stuff in core: it takes time to implement this, and as far as I know, no one is currently working on a patch to get basic field support into core. If there was a patch and the commitment/willingness to finish it before the code freeze, the situation might be different depending on the state of such a patch. Right now, there is no code to justify such a decision. -- Dries Buytaert :: http://www.buytaert.net/