This issue is a stub to start a discussion about how to move cck fields to core. I have also added a new issue component called 'CCK in core' that can be used to identify tasks, patches, etc that relate to that.

CommentFileSizeAuthor
#9 fapi3_test.zip_.txt10.73 KByched

Comments

Anonymous’s picture

Anonymous (not verified) commented

Would this be better played at g.d.o?

yched’s picture

yched commented

I guess the first question that comes to mind is :
do we try to incorporate CCK-more-or-less-as-we-know-it (probably cleaned up / enhanced / refactored by places), or does "CCK-in-core" means more in-depth conceptual shift like adrian's FAPI3 (http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/adrian/fapi3.pdf) ?

moshe weitzman’s picture

moshe weitzman commented

i think we have a big enough challenge getting it in "more or less as we know it". lets not try to engineer even more. my .02.

karens’s picture

karens commented

My initial thought is to create a copy of the module in core, using a different module name and different table names. Perhaps call the core module 'fields' and prefix all its tables with 'fields_'. Then have the install file check for the existance of old tables, and if so, rename them, otherwise create new, empty, tables.

I hope that will avoid all the upgrade problems we had with 5.x core using the same table name as the contrib module, and make it easy to tell if someone is using something left over from the contrib version instead of the core version.

Then I would say we clean up and debug the existing code as much as possible, but I agree with moshe we should probably not try to make major changes to it and transfer it to core all at the same time.

As to the question of whether this discussion belongs in g.d.o, it could be anywhere, but this location seems like one most people will find. We will probably end up with a number of related issues -- at least one core issue with the patch to create the core version of the code, maybe a discussion or two on g.d.o, maybe other issues here on the CCK issue queue. We can link from this issue to any others that are relevant. I just wanted to put a stake in the ground to get started.

yched’s picture

yched commented

"CCK as we know it" / FAPI3 : Fine by me - I just want to make sure Dries and core committers see it that way.

And oh yes, we do want to avoid the 4.7 - 5.0 update path nightmare :-)
the "fields_" namespace sounds like a good idea.

About the workflow. the only thing is that I fear current cck code might not be core worthy as is, and a patch to get it into core could mean rewriting anyway, only in a patch / issue queue instead of in a cvs repos, which is much less handy.

BioALIEN’s picture

BioALIEN commented

I agree with the fields_ name space idea. I think this issue is long overdue :)

karens’s picture

karens commented

I agree that the code is probably not core-worthy yet, but I would try to get it to that point here, in the CCK issues queue, before we create a proposed core patch/issue. Hopefully anyone interested in this will help out by creating patches to move that goal along since I doubt yched and I alone are going to have time to do this and also keep up with the regular issues. We could use the new category of 'CCK in core' to flag patches that are designed to get the module 'core-worthy'.

yched’s picture

yched commented

What about working on this in cvs ? Keeping all this in a patch until it finally hits core will probably be a pain.
Problem with a sandbox is that only one person will be able to commit, right ?
So maybe a special branch in CCK ? (probably not HEAD ?)
Are we allowed to open non core-version-related branches ?

yched’s picture

yched commented
StatusFileSize
new fapi3_test.zip_.txt10.73 KB

The discussion in devel list clearly heads towards the FAPI3 way.

In order to facilitate development and testing on the basis adrian laid down in his drupalCon presentation and developed in the ML, I took the 'raw-php' code available in his sandbox (http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/adrian/fapi3_...), and wrapped it in a small fapi3_test module that integrates it in drupal environment without having to patch large parts of core..

I slightly added to / modified adrian's original code to generate 'edit-form' views as well as 'display' views, and added a "translator" functions that bridges the [p] syntax used in adrian's code and the '#property' syntax used in FAPI / drupal_render current implementations.

The module allows viewing and editing a very simple 'pseudo' node on pages 'fapi3_test/view' and 'fapi3_test/edit'

As a disclaimer, it should be noted that these modifications (rather minor) are made on the code adrian posted back in september, and might not be in line with what he had in mind or with further work he might have done on this since then.

module is for current state of Drupal 6 - remove the .txt extension

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Postponed

We want this for Drupal7, but we have an awesome CCK2 in the works and we'll need to get that out before undertaking cck in core.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented
Status: Postponed » Closed (won't fix)

CCK1 in core is a won't fix, now that there is CCK2 alias #265604: Fields in core.