Panels 3 and multiple node type fields.

I think the patch needs a bit more thought/work:

1) I believe it should be possible to build the array of fields using functions that manage cached data rather than using CRUD.

2) The label used for the title of the fields exposed to Panels would have to use the widget label, which is what the site admin may easily recognize, I think. It doesn't make sense to include the node type here. Maybe something like "@field_type: @widget_label (@field_name)"?

3) $info['category'] = 'Content'; would have to use t().

4) The rendering callback needs to use the node type to load the $field struct. Otherwise, if the field is shared, that $field struct may be related to a field associated to a different type that contains different per instance settings. Since the node type is not part of the Panels content type, it could be extracted from the node given in the context. Also, a check should be made to see if there's a node, if not, just return nothing.

5) While we are touching the rendering callback here, we may also wish to initialize the $block object with new stdClass().

6) In regards to the fact that this patch would change the panels content type identifier, I think we need a word from Yves, Karen or Michelle. May we break backwards compatibility here?

Here's a patch that intriduces the fixes described in #2 + similar fixes for fielgroup integration in panels. Multigroups are ignored here, and that will be implemented by the multigroup module itself (CCK3).

Please, test with Panels 3. Feedback is more than welcome. Let's see if we can move this forward. Thank you all.

Patch re-rolled.

Please, note the identifier of fields exposed to panels is now the field_name only, it was type + field_name.

It would be nice if someone could create a panel for node view and try to add a few fields. Works? Looks good the name of the fields in the "Add content" section?

Thank you very much for the feedback. :)

Re: "I'm not too fond of fieldgroups still being type bound..."

The namespace for field groups is the node type, not like fields which are global. We may have different groups named "group_a" in more than one type. So, we need to key the field groups with "node type + group name".

Re: "It would be nice if fieldgroups was more like fields..."

Not sure what you mean here. Could you please elaborate?

Then, I think I'll commit the patch in #5. The keys for fields/groups exposed to panels are ok now, and the rest of cck/panels integration features can be enhanced on separate issues with Component = Panels Integration. It's easier to manage them that way in the issues queue.

Well, committed the patch in #5 to CCK2 and CCK3.

Please, open a separate issue for discussion of further improvements to the CCK integration with Panels 3. The original issue reported here is fixed.

In CCK, field groups cannot be shared between several content types as you can with fields. Hence, this should be reflected when exposing the field groups to Panels. That's why I changed the label to '@group in @type (standard field group)'.

Event if several field groups have the same name on different node types, each fieldgroup is different. Each one belongs to the node type where it is defined.

If you need to add a field group to a Panel, you will probably need to create a panel for each node type, or one particular field group will not be rendered on some nodes, just because the field group does not exist in their node type definition, even if the field group has the same name on all node types. Each field group is a different entity for CCK. Field groups cannot be shared in CCK. This is a CCK constraint, not a CCK/Panels integration issue.

Sorry, but I can't see new dev version for cck3.

@La_ntegral: The CCK3 dev release is not visible in the CCK project page due to its "experimental nature". You should look at the "View all releases" link.

Here it is: cck 6.x-3.x-dev

@markus_petrux: ahhh, I'm sorry, I saw June 7, 2009, but can't see "first released". :-) Thanx.

As markus said, each field group is a different entity for CCK. We only enforce no group name uniqueness within a given node type, but the fact that several fieldgroups have the same name is purely "coïncidental" for the system - unlike field names: the fact the two fields with the same name appear in two note types has a very strong meaning (the field is shared)

I do see the value of presenting 'two groups with the same name' as 'two instances of the "same" group' within Panels: it lets you draw a common 'structure' between node types (or some of them). You do that already with regular node templates using the $GROUP_NAME_rendered variables.
Note that those "instances of the same group" can quite possibly contain very different fields, though, so I'm not sure of the consequences, and not familiar enough with Panels and CCK / Panels integration to get a clear idea. So, er, just saying :-)

If we expose field groups to Panels using only the group name, then when you create a panel for more than one node type, you have no control on which field group you wish to render, because if the name of the group is shared, then it will show for all nodes, but since these groups are different things, we end up on a situation where we cannot choose which group we wish for each type. You have to be able to choose which group you wish for each node type, just because each group is a different thing, even if it has the same name on different node types.

If we expose field groups to Panels using the node type+group name as well as only the group name, then this is going to cause confusion. The Panels UI for choosing an element is pretty limited, and we may have a lot of fields and field groups here already.

IMHO, if you need to expose a field group for all types, then you can expose them yourself to panels. You just need a module that implements the same thing as the fieldgroup module, but just for the groups you wish. I mean, this particular use case can be solved using a custom module.

One side effect of this patch is that any panels existed with the old subtypes, they completely break. =(

Should we open to provide a hook_update_N() to migrate existing panels?

However, I have no idea on how that could be done. I haven't looked at how panels stores data internally... then we would be touching panels data from a CCK hook_update_N(), which is something I'm not sure it's wise to do.

This change has not seen an official release of CCK, so maybe it is still time to work out something. Suggestions?

I have used techniques, in the past, where I look for previously valid subtypes that are no longer valid, and transform them so that at least they can continue to work. Since I'm working with this kind of thing right now (I intend to submit a patch to CCK to improve the UI on the Panels integration a little) I will see if I can make that work while I"m at it.

It looks like this change broke Advanced Profile Kit. So, at the moment, APK isn't compatable with the dev version of CCK. I'll get it fixed ASAP but then that means it won't be compatable with the stable version. Are you folks planning 2.5 any time soon?

Michelle

@Michelle: As far as I can tell, no, there's no planned new release of CCK any time soon.

@merlinofchaos: Thanks for looking into this.

I think the problem is the content type names that have changed from node_type-field_name to field_name. So maybe there's a way to alter this in the ctools/panels database?

@Michelle: Is there any other thing that's broken?

Whoops, I had this tab open while merlinofchaos and I were discussing on IRC and didn't realize he had posted. I only know it's broken from talking to him; I've been unknowingly testing against an older version of CCK. I'm going to take some time either this afternoon or this weekend and update APK and will see if there's any problems.

Thanks,

Michelle

In addition to cleaning things up so that old panes will continue to work, this adds a simple icon for fields, capitalizes the name so that it fits the style, and moves everything to the 'Node' category on add content so that we don't created unnecessary categories. I like the expectation that things attached to nodes will appear in the node category.

The icons go next to their associated .inc file; so icon_cck_field.png goes in includes/panels/content_types and icon_cck_field_group goes in modules/fieldgroup/panels/content_types

I tested, confirmed that it fixes APK, and doesn't cause any other issues that I can see. I did only test it with one content type, though.

Michelle

Committed patch in #24 (including the icons) to CCK2 and CCK3.

Thank you very much, and sorry for the noise.

Thanks!

Michelle