I started with the code that yched had already started to port and added some more changes to it.

As yched, dopry, and bjaspan discussed via email, we're leaving out anything related to Schema API (which is going to be quite a big change) for now and just trying to get a functional 6.x version of CCK working using the old method of creating and updating tables.

Here's what I've gotten working so far and what I know still has problems:

1) Content Copy is completely broken still, don't even attempt to install it. The multi-step form and the forms api changed and it needs a careful look at what is wrong with it.

2) As per our email, we did try to use Schema API for the static tables, node_field and node_field_instance. That much should have been simple enough to be working OK but the tables are not getting installed.

3) There are still some miscellaneous variable undefined errors and that sort of thing.

With this patch I can do a clean install of 6.x, then install CCK (other than Content Copy). The menus are working and I can get to where I should be able to start adding fields, but because our tables weren't created, it's not possible to go any further.

So I'm posting this as-is so whoever else has time to look at it can try to take it a bit further.

CommentFileSizeAuthor
#29 cck_6x_port.txt17.96 KBkarens
#23 cck_26.patch86.82 KBkarens
#6 cck_25.patch12.85 KBkarens
#5 cck_24.patch19.68 KByched
#3 cck_23.patch9.42 KByched
#1 cck_22.patch23.24 KBkarens
cck_21.patch17.76 KBkarens

Comments

karens’s picture

karens commented
StatusFileSize
new cck_22.patch23.24 KB

Got a message from bjaspan pointing out the problem with table creation -- you need a single drupal_install_schema() with the module name not the table name. That got the tables installing right. I also found that hook_menu() for fieldgroup wasn't updated and removed the t()s from the menu items. I'm going to commit these changes so far to HEAD. I'm attaching a patch so you can see the changes that were made.

Now you can install the modules (other than Content Copy) and get to the menus, but there are quite a lot of error messages still to be tracked down.

yched’s picture

yched commented

Cool :-) Thanks Karen, I'll see if I can push it a little further this week end.

yched’s picture

yched commented
StatusFileSize
new cck_23.patch9.42 KB

I committed a first round of (mostly FAPI3-related) bugfixes.
Fields overview and Display overview forms are less crowded with errors (field overview still does not list fields...)
The field edit form seems to have its own share of issues :-)

That's all I can tackle for today - I'll try to add more tomorrow.

Patch attached, showing the commits I just made to HEAD.

karens’s picture

karens commented

BTW yched, note that hook_init() in 6.x is not the same as in 5.x. In 6.x there is now a hook_boot(), which is the one I think we need to avoid using and hook_init() is OK for including Views and Pathauto. Core modules are using hook_init() in 6.x as a place to add their css files so hook_init() is now safe to use. The things that used to need hook_init() now go in hook_boot().

yched’s picture

yched commented
StatusFileSize
new cck_24.patch19.68 KB

True - I must have said something like 'this will be good for us in CCK' when I saw that one get in, and then forgot...
Pathauto inclusion makes me nervous :-)

I fixed some more stuff, menu / FAPI3 / isset mainly, focusing on text.module for now. Still a few glitches here and there, but the thing actually seems to work rather well now - field add / edit / remove, node edit / view, fields and display overviews - yay ! That will probably be all for the week-end, though.

Committed to HEAD, and outlined in attached patch.

karens’s picture

karens commented
StatusFileSize
new cck_25.patch12.85 KB

I did a little more work. I got Content Copy at least to the point where it doesn't create a fatal error and found and fixed a few other miscellaneous errors. For some reason the Content Copy menus won't show up, though.

The big change that needs work is that the nodeapi 'submit' op is gone, and probably should be replaced by a '#submit' element in hook_form_alter(). And the 'validate' hook can raise errors but not alter values, probably because it doesn't have access to $form_state. So probably nodeapi 'validate' should go into hook_form_alter(), too so we can put values in $form_state. However, if we make those changes, then the arguments being sent to content_widget_invoke and content_field_invoke are completely different than they are now, in other words I think we have to do some re-architecting of those processes.

So that's where I got stuck. Here's a patch and this much is committed.

moshe weitzman’s picture

moshe weitzman commented

the Actions patch which recently landed added nodeapi('presave') which is same as old nodeapi('submit').

see http://drupal.org/node/144132#passing for notes on how to persist info from validate handler. the arguments for these functions changed a lot so the docs might be lagging.

karens’s picture

karens commented

Yes I saw the changes on the way 'validate' works, and it looks like we need to make $form_state available to the widgets and fields so they can use it. I didn't see 'presave', so that's good to know.

So, do we want or need to make $form_state directly available to the fields and widgets? If so, I think we need to switch to using the #validate element in the form instead of nodeapi's validate, then we need to pass $form and $form_state along (instead of $node? along with $node?) when we do widget_invoke and field_invoke. That's probably the cleanest route for the future -- making more use of FAPI -- but it will change the API for fields and widgets.

And if we do that, do we want to do the same thing with 'submit' -- use the form element instead of nodeapi?

The current methods pre-date FAPI and were due to be rewritten anyway, but I was hoping we could wait and do that in a 2.0 version down the road and not have to figure it out right now...

moshe weitzman’s picture

moshe weitzman commented

I think it is being overly generous to shield field modules from any API change during the D6 port. So passing $form_state sounds valid to me. I'm not speaking from a code level though, just an interested observer.

i'm OK with switching to #validate handlers as opposed to nodeapi('validate') but some in the drupa community are not too fond of that sort of thing. they say it is "too form focused".

yched’s picture

yched commented

Actually, before even realizing we had to change some stuff in the validate area, I was in favor of moving widgets to the FAPI #validate, #value (data massaging) and #submit (barely used currently) model as of now, and dropping 'validate' and 'submit' ops for hook_widget. Widgets _will_ be more FAPI oriented (basically FAPI 'elements') eventually. I agree with moshe about moving there as soon as the D6 port, regardless of whether we go further towards CCK2 right now or not. Saying 'This is D6, my friends' is fine by me.

The way I see it, once node submission handling is out of 'widget' level and into 'field' level, we're out of FAPI area, and I think hook_field ops can remain as is (with cck's $items as param). If content.module needs to hook 'general' validation and submission through global #validate and #submit callbacks on the node form, rather than with current nodeapi ops, I think it should belong to content.module to translate from $form_values to $items. This feeling should be backed up with actual code, probably :-)

moshe weitzman’s picture

moshe weitzman commented

just playing devil's advocate here ...

if we move save handling to #submit fapi handler, then a direct call to node_save() will not work as one would hope, and data import scripts (for example) will become more complex. today, one can just build up a $node object and call node_save($node) and it all works for cck types. not so if we move to #submit model. we will force people to use drupal_execute() instead. i'm OK with that, but just want to get everyone thinking about this.

yched’s picture

yched commented

Ah, right, I did not get that part in your previous post. This can't be IMO. Breaking things $node = node_load($nid); $node->foo = bar; node_save($node); is a great step backwards. So I guess field saving has to be triggered by nodeapi. (This does not interfere with the FAPI approach for widgets, though.)

Well, I probably won't be able to progress much on this tonight, I'd like to get back to the (unrelated) 'batch node access rebuild' patch before it's definitely too late :-)

yched’s picture

yched commented

Committed a small bunch of php warning fixes around text and number 'allowed values'
Plus renamed content_validate and content_submit to make it clear that they now intagrate in FAPI workflow.

Alas, I hit the 'commit' button before thinking of rolling a patch to outline the changes in this thread...

karens’s picture

karens commented

I'm working on this a bit this morning and thinking about where to put the 'submit' handling. Does it make sense to differentiate between widgets and fields here, i.e. 'submit' handling for fields should be in nodeapi (which we can do with 'presave' I think), but 'submit' handling for widgets should be in FAPI? If we move widget handling to use more FAPI (or only FAPI), that's effectively what will happen anyway. But I think that's OK since I think widget handling should revolve around things like altering values in the database to the format needed by the widget and back again, which isn't needed on node_save() anyway.

Anyway, I'm going to try to move this forward and I'll post back here later, but in the meantime if anyone has any thoughts about this, I'd like to hear them.

moshe weitzman’s picture

moshe weitzman commented

i think that split makes sense.

for even more self contained widgets, they could use the #process element to make changes that only affect own field. search for #process at http://api.drupal.org/?q=api/file/developer/topics/forms_api_reference.h.... that will work for simple widgets, but not complex ones. .. or i don't know what i'm talking about which is certainly possible.

karens’s picture

karens commented

I think we should definitely move in the direction of using #process and #submit and #validate on the widgets themselves. The question is do we change the widget code so the widgets are doing it themselves and have CCK quit processing widgets, or have widgets define things as they always have and have CCK massage widget settings info into #process functions? The first will require a bigger change to the way widgets are defined, which may require some education of widget module developers, but fits better into the big picture of pulling things out of CCK and into core where ever possible.

My initial thought was just to get things working as they always have and then revisit this, but we already ran into problems since nodeapi 'submit' is gone. As soon as I started working on optionwidgets I found that things are broken with the new methods and I think it would work better if optionwidgets was handling #validate and #submit for itself.

What I'm running into with optionwidgets is that 'process form values' gets called twice, by hook_validate and by hook_submit. The first time the widget alters the keys, then the second time keys info is lost. Since both callbacks to 'process form values' look the same to optionwidgets (there is no context for the widget to know if it is validating or submitting) it's hard to make it do the right thing.

karens’s picture

karens commented

BTW, since we're getting close to having working code now, I started making small commits of related fixes, with explanations, instead of big commits of lots of unrelated fixes. So I haven't posted patches here, but you can see the diffs in the cvs logs.

karens’s picture

karens commented

I'm quitting for now. I went ahead and split widget and field handling so widget_invoke uses FAPI validate and submit and field_invoke uses nodeapi validate and presave. I also got rid of a second call to widget_invoke 'process form values' which seems unnecessary at best and which breaks things for modules that make changes to $items, like optionwidgets.

With that and a number of other fixes to undefined and badly defined indexes and variables, optionwidgets, nodereference, and userreference are working. They haven't really been put through the wringer, but worked for me.

Still to do that I know of:

1) Preview is not working for optionwidgets, nodereference, or userreference. Simple fields seem to be OK in preview, though.

2) Need to think about how and whether and where we want to set #process, #submit, etc on individual widgets.

3) The multi-step form in Content Copy needs to be rewritten to work with the new method of doing multi-step forms.

4) Need to start incorporating more of Schema API.

yched’s picture

yched commented

AAMOF, I got back to the D6 port last monday but did not get a chance to commit anything because my home internet access was down until tonight... I merged my changes with yours and committed them. Some parts we ended with the same code, some others I missed, some others I added (mainly E_ALL warnings) :-)

Fieldgroups work OK (with a few glitches still noted as TODO, and a bit of code inherited from 4.7 that really should be refactored now)

I had not tried optionwidgets, but stumbled on the 'process from values twice' issue too for other widgets (selects) and fixed it differently, but I think your split (widget ops -> FAPI, field ops -> nodeapi) makes perfect sense, and I kept it rather than my code. Actually, I agree that we should move widget ops to FAPI #callbacks altogether, and let them out of content.module. Let's call it next step ?

I was waiting to be able commit my code before sending a mail to bjaspan, to let him know that we had reached the point where he could jump in for the Schema stuff if he's still willing to. This is all the more valid now :-)

yched’s picture

yched commented

BTW, I added back maxlength validation on text.module : it does not interfere for textfields because with the maxlength HTML attribute you cannot type more chars than allowed anyway, and it is needed for textareas (rows > 1) where that attribute does not exist.

karens’s picture

karens commented

Try creating a textfield that should have no maxlength by leaving maxlength empty. You will get a form error on anything you try to do because form.inc is checking if maxlength isset(), which it is, then limiting the text to a length of NULL, making it impossible to save the form. That's why I put the 255 characters in there instead.

karens’s picture

karens commented

Never mind about the problems with form.inc balking on NULL values, that just got fixed in core yesterday so you're right it is now OK. I would still check maxlength in CCK only when core is not checking it (for the textarea field) both because there is no reason to run the same check twice and because when it fails it is confusing to tell whether it is failing the CCK test or the core test.

karens’s picture

karens commented
StatusFileSize
new cck_26.patch86.82 KB

yched is now working with barry on incorporating Schema API into the port and I am adapting the widgets to use FAPI handling. I have the FAPI handling changes partially done, but they still need more testing before I commit them. However, I decided to post my current patch for comments, if any, on the approach I'm taking. Here's what's changed:

1) Each widget module declares its own hook_elements(), where it identifies its #process, #element_validate, etc callbacks for each of its widgets. To make this work as well as it should, I made sure the widget types match the element names (and element names must have the module as a prefix), so options_select became optionwidgets_select and text was broken into two widgets -- text_textfield, and text_textarea. Those fairly simple changes were made as updates in the install files.

2) Each widget module adds to hook_theme() any elements declared above. All titles, labels, and descriptions, and fieldsets are moved from the widget processing to the theme (something that probably should have been done before now).

3) Each widget module creates a separate callback function for each processing step, i.e. the expansion of the field into all its multiple parts is done in the #process function, validate is handled in the #element_validate function, etc. This eliminates all the switches and if..then code in of the hook_widget() function which makes the code much easier to follow and maintain.

4) To make $field info available in the FAPI processing, I had each widget add '#field' to each custom form element to hold the field array. This way the $field info will be available as a part of the $element in all #process, #submit, etc. callbacks.

5) Once all that code was removed from hook_widget, hook_widget really no longer needs an $op, since it just has one purpose -- to add a field form element to the form. So I refactored and simplified content.module to remove widget_invoke and instead just put the code to call hook_widget() directly into content_form().

6) I started passing $form and $form_state to content_form() instead of $node, to take better advantage of FAPI processing possibilities.

7) I also had to make some changes to the way default values are handled, since that was the one other way that widget_invoke had been used, so I added the name of the function to use for default values to widget_info(). Widgets that use the default handling use 'content_default_value' as the function. Widgets that want to use custom handling can insert a different callback name there. This also has the advantage of making it easier for developers using the core modules as examples to see how to add their own handling.

yched’s picture

yched commented

Wow. I did not actually take the time to look closely, but this sure sounds impressive.

With all this refactoring (and API breaking), do you think now would be a good time to move 'multiple' values form handling to content.module ?
Having widget simply return the form element for _1_ value would open the door to a few of the most awaited feature requests (ajax 'add new value', min/max number of values, and ultimately consistent and bug-free multiple value management for all field types).
Requires some discussion, obviously (non minor impact on all parts of the code, some widgets - selects - are 'multiple' per se, etc...) but I just wanted to have your feelings after this first pass of FAPI upgrade.

I'll try to commit my work in progress about Schema API shortly.

yched’s picture

yched commented

Minor detail from a quick browsing through the patch : in theme_nodereference_select(), the fieldset for the noderef select when field is multiple is probably a copy/paste error, since select widget is inherently 'multiple'.

I would have thought we could make use of the FAPI '#value_callback' property added in http://drupal.org/node/121620, to handle the old 'process form values' step - at least that's the way we sold that patch to Dries :-). I even thought maybe it could alleviate the need to declare our own _elements() ? (quite possibly being naïve after all...).

karens’s picture

karens commented

Yes, probably copy/paste errors in nodereference and elsewhere, much of this has not been really debugged yet.

Re multiple values handing, yes I do think this would be a good time to try to add this in since we're changing the API already. However, I don't have any good ideas about exactly what to do with it.

Re #value_callback, I have played around with this many different ways and basically we either use #value_callback or #process, but not both. I also originally thought we could do this with only #value_callback, but I'm not so sure, and #process is more flexible I think. I also wondered about calling hook_elements(). We still don't have to do it, we can just add #process, #theme, etc to the form element, but as I tried out different ways of doing this I finally decided it made the most sense to just go ahead and use FAPI standards instead of coming up with some system that is semi-FAPI but not really FAPI. That forces us to declare themes for our elements, which we really should do anyway, and moving all the translated values to the theme layer made a lot of sense to me.

moshe weitzman’s picture

moshe weitzman commented

The new widget flow sounds very clean and logical. Great work, Karen.

yched’s picture

yched commented

I committed the current state of the Schema API port

I opened a separate thread for that in http://drupal.org/node/167945 - lets keep this one FAPI-related, there's plenty to discuss already :-)

karens’s picture

karens commented
StatusFileSize
new cck_6x_port.txt17.96 KB

Attaching our IRC discussion about the FAPI changes so it doesn't get lost. I did lose the very first part of it, but most is here...

karens’s picture

karens commented

I just committed the first round of changes to FAPIize the CCK widgets. Based on our IRC conversation and other ideas and conversations we've had in the past, I implemented the following basic ideas:

1) The content module will now rely on FAPI to do most of the widget processing. Widgets will call hook_elements to register elements that other modules can use. Therefore widgets will have to add #process, #value_callback, etc to handle whatever processing they need. There is no longer any reason for the content module to create methods to do things that FAPI can do.

2) The content module will take over responsibility for multiple values processing. Widgets will only create a single form element, making the widget code much simpler and easier to understand. The content module will call hook_widget() as many times as necessary to create the full multiple valued field array. This will also make it possible for the content module to create a standard method for setting the number of multiple values that can be created and add other features related to multiple values, like javascript code to dynamically add more items.

3) The widget elements will be completely agnostic about where they are being placed. The content module will handle placing them on nodes, but elements can be combined or placed anywhere, so long as some kind of $field array can be passed to them to tell the element what title, description, and parameters to use. It should be possible to write custom code to place them elsewhere, like on user forms.

More Details

The current widget code is a bit of a nightmare to write and understand -- lots of switches and if..then loops and logic related to understanding the difference between single and multiple form elements. In the current code, widget_invoke() is called repeatedly with various operations like 'pre process', 'form', 'post process', 'validate', 'submit'.

In the new code the content module analyzes the widgets and figures out if they're single or multiple and how many are needed, then invokes hook_widget() once for each delta value. The content module builds out the form with $field['field_name'][$delta']..., The widget doesn't need to do anything but create a single element each time they are invoked. You won't even see '$field['field_name'][$delta']' anywhere in the widget code any more.

For widgets with complex needs, hook_widget() passes a reference to $form and $form_state to the widget so the widget can do anything with the form it needs to in addition to passing back its element.

To make the widgets completely agnostic about where they are placed, all hard-coding of things like 'value' and 'nid' is removed. Instead the widget expects the field to tell it the column names to use in the element. Getting rid of the hard-coding of those names and letting the content module handle field-specific things like setting the $field['field_name'] makes it possible for widget elements to go anywhere. For instance, nodereference and userreference now use the optionwidgets select widget for select elements, and any other module that needs a select could do the same thing. Selects in CCK are complex because you have to transpose multiple values into a single option list when the form is created, then create multiple form elements from the results when the form is saved. Optionwidgets does all that work, no need for other modules to replicate it.

TO DOs

There are a number of things not yet working right. I haven't found a good method for removing empty multiple values. I can set them to NULL in form state, but they're still there and the field happily goes ahead and saves them.

Nodereference and userreference autocompletes still need more work. The selects seem to be (mostly) working OK.

yched’s picture

yched commented

This is *so* great.
I'll be mainly offline for the next 2 weeks, but I'll be sure to grab the code and help test and debug if needed.

Thanks and kudos for this Karen :-)

yched’s picture

yched commented

Just gave the diffs a quick reading - looks plain awesome.
You also generalized text and number fields 'allowed values' into content.module ? Really cool - I guess there are some field types (imagefield... ?) where we'd want to have the feature not appear though ?

Also, in content_elements(), is '#columns' => array('value') really required for the content_multiple_values (fieldset) element ?

karens’s picture

karens commented

What I did with allowed values was implement a hook, so a module that wants to use the select element can implement hook_allowed_values() to return an allowed values array. If there is no hook, the code checks content_allowed_values(). But there may still be ways to make it work better, it's just something to start with.

And I don't suppose content_multiple_values needs #columns, but there may have been a reason that I'm forgetting now. Still a number of things like that to figure out, but it's a start.

I did some more work on userreference autocomplete and nodereference autocomplete. They are another example of combining elements since they use the text_textfield element instead of creating their own. I think I've got nodereference working now, still something quirky going on with userreference...

robloach’s picture

robloach
he/him
commented

How is the CCK Drupal 6.x port coming?

karens’s picture

karens commented

See http://drupal.org/node/177892, the notes from DrupalCon for a summary of the status.

rickvug’s picture

rickvug commented

subscribing.

karens’s picture

karens commented

Just committed some major changes to the D6 port:

Change schema to store field column and module info in the field settings table so we have a way to clean fields up after a field module is uninstalled and rework all code to retrieve that info from the database instead of using module_invoke('database columns'). See http://drupal.org/node/97861 for some of the discussion about why this was needed.

Also did some major restructuring to move most existing field crud processing to content_crud.inc. This still needs more testing and is not the final API, but it is a beginning.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

subscribe

psicomante’s picture

psicomante commented

cool, subscribing

karens’s picture

karens commented

I posted this to the g.d.o issue, but I'll repeat it here. The HEAD version of CCK (designed for Drupal 6.x) is ready to be tested and debugged by anyone with an interest in working on it. It is absolutely *not* ready for production yet, and practically anything in it could change unexpectedly if we find problems, so use it only on development sites.

catch’s picture

catch
he/him
Primary language English
commented

subscribing as well so I can keep up.

misty3’s picture

misty3 commented

subscribing

Anonymous’s picture

Anonymous (not verified) commented

subscribing

jrabeemer’s picture

jrabeemer commented

subscribing

murz’s picture

murz
Primary language English
Location Yerevan, Armenia
commented

subscribing

cfennell’s picture

cfennell commented

subscribing

trungdong’s picture

trungdong commented

subscribing

cabbiepete’s picture

cabbiepete commented

subscribing

s.daniel’s picture

s.daniel commented

subscribing

harriska2’s picture

harriska2 commented

subscribing

jmarki’s picture

jmarki commented

subscribing

yojoe’s picture

yojoe commented

subscribing

tormu’s picture

tormu commented

subscribing

ximo’s picture

ximo commented

subscribing

ronald_istos’s picture

ronald_istos commented

subscribing

freakx0’s picture

freakx0 commented

subscribing

Island Usurper’s picture

Island Usurper commented

OK, I've got a project I'll test CCK on. I'll be sure to let you know if there are problems.

rayarub’s picture

rayarub commented

Subscribing as well.

Beau Gunderson’s picture

Beau Gunderson commented

subscribing

aozuas’s picture

aozuas commented

subscribing.

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
commented

Folks - you can stop subscribing and start testing, IMO. I'm using it on a test site without problem. Typical "may eat your baby" precautions are still there (i.e. back up data often) but it's mostly working and in need of testers.

See http://drupal.org/node/157176#comment-629200 (20 comments ago).

yched’s picture

yched commented

Right. It's also true that we have not communicated much since then.

Here's a summary of the current roadmap :

- CCK HEAD is currently functionnal for D6, most probably with quite a few bugs, and *without* a working D5 upgrade path.

- We will be done with CCK 2.0 API-breaking changes once the formatters refactoring patch lands - this should happen in a couple days if no concerns are raised in the thread.

We will then create the CCK 6.x--2.x branch, and officially call for testers. It will also be a perfect time for contrib field authors to start porting their modules and report any troubles.

- Next phase will be about bugfix and providing an upgrade path, before publishing a first beta release.

- Ideally, we'd like to be able to complete a set of simpletests for the db storage engine and the new field CRUD API before tagging a stable release. A GHOP task, claimed by Corsix, is under way to lay the grounds for this.

yched’s picture

yched commented

Forgot a major task before a final release : Views integration.
Obviously, we depend on Views on this. I think Views in its current state lets you programmatically define views, but we probably need at least a semi-working Views UI for exhaustive testing.
This task can probably start at some point after D6 branching but isn't likely to be completed for the 1st CCK beta.
I'm also not sure how Views 1.x D5 -> 2.x D6 updgrade path will work, and if this will require some work from modules exposing views info.

Short summary :
(dates are only personal rough estimates, without any sort of commitment, and stay under the usual "it's ready when it's ready" rule...)
- CCK 6.x--2.x branch : frozen API, with bugs, no D5 upgrade path, no Views integration
in a few days
- CCK 6.x-2.0-beta1 release : hopefully fewer bugs, working upgrade path, maybe semi-working Views integration ?
2nd half of february ?
- CCK 6.x-2.0 stable release : critical bug free, Views integration, hopefully simpletests for db storage.
some time in march ?

moshe weitzman’s picture

moshe weitzman commented

We should really shoot to release CCK before Drupalcon. Otherwise, we'll have lots of finger pointing as to why Druapl6 is not yet unusable and so on. Only 4.5 weeks to go.

CosmicVoyager’s picture

CosmicVoyager commented

subscribed

jystewart’s picture

jystewart commented

subscribed

aren cambre’s picture

aren cambre commented

subscribe

rudegrrl401’s picture

rudegrrl401 commented

subscribe

arturpl’s picture

arturpl commented

subscribe

dellis’s picture

dellis commented

subscribing

fm’s picture

fm commented

subscribed.

karenm’s picture

karenm commented

subscribed

wayland76’s picture

wayland76 commented

A beta version of Views 2 appears to be available, so you can play with that now if you like :).

yched’s picture

yched commented

True, and if you check latest CCK HEAD, you'll see that we already have :-)
Early steps yet, but what's in does work..

jrabeemer’s picture

jrabeemer commented

Great work. I say go ahead and post to main project page. That will get more eyeballs on it for testing and bug reports.

zach harkey’s picture

zach harkey commented

subscribed

Antoine Lafontaine’s picture

Antoine Lafontaine commented

subscribed

mrgoltra’s picture

mrgoltra commented

subscribe

udienz’s picture

udienz commented

subscribe

konsumer’s picture

konsumer commented

subscribe

JMowery’s picture

JMowery commented

Subscribing. Hopefully you guys can knock this out of the park. I really am starting to need it, but can wait.

gellpak’s picture

gellpak commented

Subscribe

Soulhuntre’s picture

Soulhuntre commented

Glad you guys are working on this. Frankly the CCK is the primary reason Drupal is so useful. I am a bit confused what the point was of even releasing D6 without CCK and views as well as a working access control system (aka ACL).

Island Usurper’s picture

Island Usurper commented

Sometimes I feel like I'm in the minority because it took me so long to find out how useful CCK and Views are. For this reason, I don't feel like Drupal 6 is terribly handicapped by not having them yet. Of course, I realize I'm still working with D5 until Übercart gets done. However, I probably found out more of how Drupal works because I didn't let another module do it for me.

Think of it this way: it gives designers a chance to relearn how to theme Drupal before deadlines begin to spring up all around.

JMowery’s picture

JMowery commented

I honestly have a similar feeling to what Soulhuntre stated. Slowly iron out all the bugs, and then have a huge release where everyone is upgrading. I actually installed Drupal 6, and have reverted back to Drupal 5 because of this issue entirely.

Domodel’s picture

Domodel commented
Assigned: Unassigned » Domodel

subscribe

scottrigby’s picture

scottrigby
he/him
Primary language English
Location Brooklyn, NY
commented

Subscribing - thx. Looking forward to this!

tomski777’s picture

tomski777 commented

subscribe

hass’s picture

hass commented

subscribe

jpewert’s picture

jpewert commented

subscribe. great job you're doing, btw!
I have only started using Drupal yesterday, but am already really excited at what it can do out of the box after endless time of trying to convince WordPress that it is a CMS. CCK promises to be sliced bread 2.0 to me.

sfranchi’s picture

sfranchi commented

Subscribe

Ryan Palmer’s picture

Ryan Palmer commented

Subscribing

kkkkkkkkkkkkkkkkkkkkkkk’s picture

kkkkkkkkkkkkkkkkkkkkkkk commented
Project: Content Construction Kit (CCK) »
Version: 6.x-1.x-dev »
Component: General » accessibility
Assigned: Domodel » kkkkkkkkkkkkkkkkkkkkkkk
Category: task » support

I have just installed drupal-6.1. I get the following message each time want to install.
"
The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.

If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider's database server is running. For more help, see the handbook, or contact your hosting provider.

The mysqli error was: Can't connect to MySQL server on 'thesuperiorweb.com' (111).
"
Can any guru come to my aid?

stevenpatz’s picture

stevenpatz
he/him
commented
Project: » Content Construction Kit (CCK)
Version: » 6.x-1.x-dev
Component: accessibility » General
Assigned: kkkkkkkkkkkkkkkkkkkkkkk » Unassigned
Category: support » task

Please do not hijack issues.

encho’s picture

encho commented

- CCK 6.x-2.0-beta1 release : hopefully fewer bugs, working upgrade path, maybe semi-working Views integration ?
2nd half of february ?

Guess we have to wait a little bit longer...

disterics’s picture

disterics commented

subscribing

Florian R’s picture

Florian R commented

subscribe

wayland76’s picture

wayland76 commented

As a followup to comment #95, I'd be interested in knowing whether the views integration is done, and whether we get a development version to play with :).

yched’s picture

yched commented

Curent HEAD has the *beginnings* of a Views2 integration layer.
It is far from complete (notably it has no filters and no sorts), but what's in there does work.

As for the D6 branch and alpha release, we're pending on http://drupal.org/node/218973

pjb’s picture

pjb commented

subscribing

wuf31’s picture

wuf31 commented

subscribing

Freso’s picture

Freso commented

Subscribing. :)

huayen’s picture

huayen commented

Subscribe.

plexato’s picture

plexato commented

subscribe

wayland76’s picture

wayland76 commented

yched: thanks! Great to know where we're up to. I also understand the delay now -- #(%&* CVS. :)

zilla’s picture

zilla commented

wow - GREAT work - i was thrilled to just see this come up in the new modules for 6x!!!

brianV’s picture

brianV commented

subscribing

gerritvanaaken’s picture

gerritvanaaken commented

subscribed as well.

Roxpace’s picture

Roxpace commented

Sad that Views is delaying everything so much

hass’s picture

hass commented

I thought it is the refactoring of the directory structure that delays most...

hatsch’s picture

hatsch commented

subscribing

schuyler1d’s picture

schuyler1d commented

subscribing

Otaci’s picture

Otaci commented

Subscribe

robin monks’s picture

robin monks commented

Subscri....you know ;)

idflorin’s picture

idflorin commented

I have much patience ...I fish ... Subscri....

jaredm’s picture

jaredm commented

sub

duckpuppy’s picture

duckpuppy commented

sub

crsneil’s picture

crsneil commented

subscribe

Roxpace’s picture

Roxpace commented

Can people stop writing subscribe ? Make a decent comment instead of that

zilla’s picture

zilla commented

@roxpace - because drupal.org doesn't have a notifications system in place for users to follow threads without commenting, this has unfortunately become the de facto way to pull an issue into one's own tracker for updates...not the greatest way to do it, but it's pervasive on the site

fm’s picture

fm commented

@zilla - Is there a better way? Please let us know. Though I participate in this ad hoc notification system, I acknowledge it is inefficient and annoying. Subscribing to all issues for a module isn't better, but that's the only alternative of which I'm aware.

Imho, the Drupal community outgrew this site's current configuration about 2 years ago. The site is not well organized, nor well configured.

zilla’s picture

zilla commented

@fm (and others) sure, anybody could use a service (free) like www.changedetection.com or www.followthatpage.com or others, but that's tedious...at any rate, trying to NOT hijack this issue, may post for discussion over on general forums shortly. this site needs to let me 'bookmark' modules as well as threads' versus just tracking everything i've ever written and browsing that way...

waby’s picture

waby commented
Category: task » bug

hi, playing around with d6 cck.

the date select lists works fine, but cck is not updating date/time fields in the database, its just left null.

also, is it possible to merge the hour and minute fields in the db together? even though they are two select lists for times. (probably not that big an issue)

zilla’s picture

zilla commented

@waby - i posted a similar issue (error on line 199, nulldate issue) over on date module

the reply is that the current focus is CCK - once that's fixed up, attention will shift to date and calendar...for now,i'm just using it to create the non-working form layout...

aren cambre’s picture

aren cambre commented
Category: bug » task

Reverting category. waby: your concerns should be opened as new issues, not tacked on to this one.

jeffvogelsang’s picture

jeffvogelsang commented

sub

phano’s picture

phano commented

this is a decent subscribe ;-)
as you can see the number of subscription, the official release of CCK for D6 will be a real event!

ogi’s picture

ogi commented

subscribe

karens’s picture

karens commented

An update for anyone following this thread, we now have Views 2 integration generally working in the D6 version of CCK.

Views 2 code is ALPHA quality and is literally changing every day, and we are keeping up with the changes in CCK. The alpha 3 version of Views will NOT work with CCK any more, you need the latest development version. And you will need to keep getting the latest development version of both CCK and Views at least until there is a beta release of the Views 2 code.

zilla’s picture

zilla commented

@karens: would you mind posting links to the page where we can download latest dev versions of both CCK and Views? and do those links change dynamically (e.g. if they don't appear in update status)

wayland76’s picture

wayland76 commented

I think you have to check them out from the Drupal CVS. You can do this with any CVS tool, as an anonymous CVS user. If you Google the Drupal site, you should come up with something. You'll want either a "cvs export" or a "cvs checkout". The export is set up so that it's easy to use the code. The checkout is for if you want to change things and contribute back.

zilla’s picture

zilla commented

yup, just realized that, you can do it by browser too for those interested - go to cvs.drupal.org find module, go into any file and up top will be a link to download head...

hass’s picture

hass commented

CCK Dev: http://drupal.org/node/96064
Views Dev: http://drupal.org/node/95897

amy_cgi’s picture

amy_cgi commented

subscribing

rvk’s picture

rvk commented

subscribing

creamyhorror’s picture

creamyhorror commented

subscribing, thank you guys for the work you're doing

Chris Bray’s picture

Chris Bray commented

+1 for a subscribe feature....

jrglasgow’s picture

jrglasgow commented

subscribing

dmurphy’s picture

dmurphy commented

subscribing =)

dmurphy’s picture

dmurphy commented

subscribing =)

redben’s picture

redben commented

tracking

changed’s picture

changed commented

subscribing

flickerfly’s picture

flickerfly commented

sub

corcken’s picture

corcken commented

subscribing

paperfield’s picture

paperfield commented

subscribing

DanBollinger’s picture

DanBollinger commented

subscribing. Looking forward to seeing this in action!

Slim Pickens’s picture

Slim Pickens commented

subscribing

cjeich’s picture

cjeich commented

subscribing.

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented

Wow. This is the largest number of "subscribing" comments I've ever seen. More popularity proof I guess :)

People who would like to see the Hierarchical Select available for more CCK fields as a widget (only content_taxonomy is supported right now), e.g. location can already start working on that right now. The API won't change when I port it to Drupal 6, so your efforts won't be in vain; your work will be usable in both the Drupal 5 and Drupal 6 version of CCK!

drewish’s picture

drewish commented

I'm looking at the code for the user reference formatters in HEAD and wondering if I'm just missing something or if this is a bug:


/**
 * Theme function for 'default' userreference field formatter.
 */
function theme_userreference_formatter_default($element) {
  $output = '';
  if (isset($item['uid']) && $account = user_load(array('uid' => $item['uid']))) {
    $output = theme('username', $referenced_user);
  }
  return $output;
}

/**
 * Theme function for 'plain' userreference field formatter.
 */
function theme_userreference_formatter_plain($element) {
  $output = '';
  if (isset($item['uid']) && $account = user_load(array('uid' => $item['uid']))) {
    $output = $account->name;
  }
  return $output;
}

Where are the $item arrays defined?

yched’s picture

yched commented

@drewish : this was a bug - I saw and fixed it a few days ago, current 6.x-1.x should be ok

drewish’s picture

drewish commented

@yched, my bad, i though i'd just cvs up'd. so one other thing. it seems like multiple modules cannot supply field formatters for the same field type... i'm working on getting the D6 imagecache patch working with quicksketch's D6 imagefield patch and the imagefield formatters are all that's left at the end of _content_type_info(). i've put some debugging statements in and it seems like at some point it's overwritten. any ideas on that?

yched’s picture

yched commented

@drewish : woops, that's probably because of http://drupal.org/node/246560, that I committed a few hours ago.
I just reverted it, could you check it's working better ? (If not, let's deal with this in a separate issue)

drewish’s picture

drewish commented

@yched, great that fixed it.

now i'm running into another issue though the imagecache formatters would like to know the node's id so that they can have a scaled image that links to the node. the D5 field formatters reference $item['nid'] which doesn't seem to be coming in in the $elements array. should i try to get quicksketch to put that into the $item during imagefield_field($op='load')? or is there some way to figure that out based on the contents of the $element array? i don't know if it'd be helpful to see the patch: http://drupal.org/node/232624#comment-807703

drewish’s picture

drewish commented

never mind that last question, i talked to quicksketch and he added it to his patch: http://drupal.org/node/224813#comment-807747

rjleigh’s picture

rjleigh commented

subscribing

prbass’s picture

prbass commented

tracking - not even looking at D6 until this is ready!

cwagar’s picture

cwagar commented

sub

bobman83’s picture

bobman83 commented

subscribing, D6 is sooo incomplete without this :)

mikeque’s picture

mikeque commented

I am building a new fairly low-scale content website with Drupal 6, and have been waiting for a non-beta release of CCK and views. I am hitting some walls in using plain unmodified Drupal 6. Is anyone using these for real production in Drupal 6? Or would that be a big mistake?

drewish’s picture

drewish commented

I've had really good luck with it so far. The problems I've had have been related to beta quality contrib fields.

madone’s picture

madone commented

subscribing.

na3s’s picture

na3s commented

subscribing

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

So now you have approx. 150 subscribers (awesome). That means: 150 testers. If you'd point us step-by-step to a patch that is currently in the spotlight, all subscribers in here could help to make a RC1 reality.

bobman83’s picture

bobman83 commented

I'm sure, there are many more waiting for this.

karens’s picture

karens commented

@sun, the biggest unresolved problems in the CCK issue queue are the ones tagged with the component 'upgrade path'. Debugging, patches, and reviews for those issues and for any other upgrade problems you run into would be very much appreciated!

priyanka07’s picture

priyanka07 commented
Title: Port to 6.x » Adding a Field to Content type
Category: task » bug
Priority: Critical » Minor

I am an intern at Appropriate IT and a relative newbie to Drupal.
When I try to add a new Text field of type select list, I am encountering a warning message but not at all times. Despite the error mssage, the field does get saved.

The message is as below:

warning:array_key_exists()[function.array-key-exists]:The first argument should be either a
string or an integer in
/home/..../modules/cck/optionwidgets.modules on
line 318.

Not sure if this is a bug, but just wanted to let you guys know about it.

stevenpatz’s picture

stevenpatz
he/him
commented
Title: Adding a Field to Content type » Port to 6.x
Category: bug » task
Priority: Minor » Critical

Do not hijack issues.

wayland76’s picture

wayland76 commented

Ok, it looks like the CVS issue ( http://drupal.org/node/218973 ) is now resolved. What else needs to happen for the 6.x port?

karens’s picture

karens commented

I'll probably tag an alpha release later tonight or tomorrow :)

wayland76’s picture

wayland76 commented

Wonderful! Thanks!

catch’s picture

catch
he/him
Primary language English
commented

Can we change this to patch needs review to encourage some testing from all the subscribers?

fwiw, latest dev upgrade went smoothly for me.

karens’s picture

karens commented
Status: Active » Needs review

OK everyone, we now have an alpha version! I know we still have bugs, but hopefully we'll get as many patches as bug reports :)

The release works with the very latest (today's) Views 2 code and I just took it for another spin to be sure it was working right before I tagged the release. Views 2 is very very cool, so if you haven't tried it yet, get ready to get your socks blown off, especially when you see what you can do with relationships using nodereference and userreference.

prbass’s picture

prbass commented

Thanks so much to everyone who has worked on this so far.

C'mon everyone, lets get testing and patching!

karens’s picture

karens commented

I knew I'd miss something important :)

I missed a small but important fix to clear the Views cache when you create new fields. That means your fields won't show up in Views until you clear the Views cache, which you can do manually on the Views Tools page. I also lost a whole bunch of translations that hass checked in right before I tagged the release. Both of those will be in the next release, probably in the next week or so, depending on how much progress we can make on getting things cleaned up.

So if you see anything important that should get fixed by the next release, please jump in and help out. Patches and really detailed bug reports with lots of information to help nail down the source of the remaining problems would be much appreciated :)

wayland76’s picture

wayland76 commented
Title: Port to 6.x » Port of CCK to 6.x
steveeq’s picture

steveeq commented

Does anyone know when the beta is coming out for drupal 6? Just wondering.

wayland76’s picture

wayland76 commented

@steveeq: Well, probably as soon as enough people post messages saying the alpha works for them, and when the bugs in it are resolved.

On that note, it's all working fine for me. But looking at the issues queue, I can see there are still open issues on the 6.x version.

steveeq’s picture

steveeq commented

Ok, I will install cck 6 on my machine, I'm rolling it out on my end. I'm a developer and I'm learning the drupal api and I might be able to contribute some help.

drewish’s picture

drewish commented

is it just me or does the D6 CCK not handle hook_nodeapi($op = 'rss item')?

moshe weitzman’s picture

moshe weitzman commented

See display fields -> advanced. thats where you maange what fields show up when $node->build_mode == RSS

drewish’s picture

drewish commented

moshe, i see the settings but no matter what i'm setting them to i'm getting feeds with only title, not body/teaser. looking at content_nodeapi()... there's no 'rss item'. searching for NODE_BUILD_RSS gives no hits...

[updated because i had some stupid typos]

karens’s picture

karens commented
Status: Needs review » Fixed

I just created a D6.2 branch and a D6.2 beta release. Don't continue to use 6.1 (which is really HEAD) since HEAD is going to be opened up for D7 work.

Marking this done, since the port is done, although there will still be bugs that need to be fixed before we do an official release.

Island Usurper’s picture

Island Usurper commented

...and there was much rejoicing.

robloach’s picture

robloach
he/him
commented

Congratulations, Karen!

Wolfflow’s picture

Wolfflow commented

Hallo Karen,

first thank you for the port. Great Job. Of corse I know that the module is in beta release but I just wnat to know if it's normal that the data I put in the Fields are not being registred in the Database.

Info: I use the CCK 6.x-2.0 beta and the Views 6.x.2.0 beta 4. I tested both very intensive on my local Server.

Cheers and Thanks for your work!!

yched’s picture

yched commented

No, it's not normal, but this issue is not the right place to discuss it.
Please open a new issue, providing as much detail as you can about the exact behavior you're experiencing.

Also note that, both CCK and Views being under active developpment / polishing, it is advised to use latest -dev releases for both modules.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for two weeks with no activity.