Panels (2) integration for CCK

i'm asking myself the same question
any hint please ?

Panels 2 is exactly designed for those kind of things - except that the functions exposing CCK fields to the Panels 2 API still have to be written. Patches very much welcome for that.

Or, you can implement your own hook_block in a custom module of yours, which needs to do something like (untested...)

if (arg(0) == 'node' && is_numeric(arg(1))) {
  $node = node_load(arg(1));
  if ($node->type == 'the node type you expect') {
    $field = content_field('the field name', 'the type name');
    $formatter = 'the formatter you want to use for display'
    $items = $node->$field['field_name'];
    foreach ($node_field as $delta => $item) {
      $node_field[$delta]['view'] = content_format($field, $item, $formatter, $node);
    }
    $block['content'] = theme('field', $node, $field, $item, FALSE, TRUE);
    return $block;
  }
}

(OK, actually writing it makes me think that cck should provide a function that displays the value for one field :-) )
Then you also have to set your field to 'hidden' is the 'display field' tab on your content type settings, so that the field does not appear in your node body.

Ah, writing pseudo code... Fixed a few bugs :

if (arg(0) == 'node' && is_numeric(arg(1))) {
  $node = node_load(arg(1));
  if ($node->type == 'the node type you expect') {
    $field = content_field('the field name', 'the type name');
    $formatter = 'the formatter you want to use for display'
    $items = $node->$field['field_name'];
    foreach ($node_field as $delta => $item) {
      $items[$delta]['view'] = content_format($field, $item, $formatter, $node);
    }
    $block['content'] = theme('field', $node, $field, $items , FALSE, TRUE);
    return $block;
  }
}

Subscribing

sub.

Here is a patch which adds integration for CCK into Panels.

This allows the adding of individual fields to panes in Panels for greater control over the layout of the content.

Take a look and let me know.

Gordon - you are a master of the understatement. Great work!

My only concern about this is that an implementation with loads of fields will overwhelm the panels UI. An alternative is to offer one content item which uses configuration to pick its actual field. But then the formatter is dependant on that choice so we get into messiness.

I'm quite happy to just go with this simple implementation for now and leave the next generation UI for later.

I'll try to test this out soon.

Thanks,

The main problem is that ATM panels will not let me see the node types which are attached to the context so that the fields can be cut down to just the relevant fields.

I talked to merlin this morning, and he is going to add this ability to panels so we can reduce the number of fields.

Subscribing, for greatness.

I sort of agree with what Moshe is saying, although I understand it's "swings & roundabouts" - personally tho, I think if we can reduce the number of "top level" panels 2 components, it will make the interface less confusing. So perhaps to that end it is better to have just one component which can be added to multiple panes and then configured there. That, I suspect, would also allow for easier configuration of these panes/blocks after their initial addition to the panel page?

Thanks tho, I needed this today!

Great, thanks for tackling this gordon !

Current 5.x-1.x code already has some amount of panels integration (fieldgroups as panes, contributed by Michelle, and noderef / userref as relationships). Could you therefore roll your patch against that latest version (where we already have a content_panels.inc file)

About one single 'CCK field' entry for all field panes (with the actual field being a setting) :
Agreed that it would be best. The ideal solution would be some custom js to dynamically update the list of formatters depending on the selected field - that's basically duplicating activeselect or hirearchical_select, though...

Another gotcha with using one single 'CCK field' entry for all field panes (with the actual field being a setting) is that, once you've added several such panes, you don't know which is which in the 'Content' tab UI until you open it's settings popup.
(that's a more general gripe I have with current Panels2, which D6 Views2 UI nicely solves, but that's another story)

I think this is what yched is saying, but to reiterate - if I am performing a node override in panels 2, and adding node specific content settings, if I try to add content, I have the ability to add ANY of the custom fields, not ones that just relate to the node type in question.

I don't know if this is something that can easily be rectified though, it's just an observation. All I know is, I'm looking at "image image image" in the config, from one field used on three content types, and I don't really know what to do next...! :)

Edit: further to this, it seems that no matter what CCK fields I try to add to the panel, I get an error message saying "deleted/missing content type content" :(

FYI I have a node override (path = node/%) panel, with several content types enabled to be overridden.

@NikLP : this is rather what Gordon is mentioning in #5

#5.....?

I have updated this to 5.x-1.x-dev. So now we have both groups and fields.

Like I said we cannot restrict the fields displayed based upon the node type which is specified in the context. This is something that Earl is look into for the next release of Panels.

"we cannot restrict the fields displayed based upon the node type which is specified in the context"

Yeah, I ran into this same issue with groups, which is why you get every group on the site to choose from and one of the reasons why I decided to do groups instead of single fields. If he makes that change to panels, I'll make the change in the groups part, too, so you only see ones you have a context for.

Michelle

The only consolation was that if the node context is not present it would not show the fields.

Patch #15 installed and runs really well

This is a super amazing tweak and arrived the same day as I was fishing for some kind of a fieldgroup panels block thing. I am stoked.

Groups seems a great compromise if you want to avoid the Token Module syndrome with screenfulls of "OMG why would I want to do that" options. Configurable, Clean, Nicely formatted, minimal downside.

Thanks again Gordon. You *are* the Bonzer

R3

Ok cool and the gang - is there any way to get *any* contextual information onto the fields tho? Like, a field description on hover, or something like that? I appreciate that other people can say "we can't do that" (re context) but I don't understand why this is a limitation...?

The context simply isn't available to the settings dialog. When you're in the funciton that defines the form for that dialog there's nothing there to tell you the context. No variable, no parameter, nothing to hook into. All you have access to is system wide things.

Michelle

Do you mean like the when you add node content it gives you a popup to edit the node?

I won't have time to fully test this myself, so I'll need to rely on someone savvy to mark this RTBC :-)
Once this is in, I guess it would be a good time to finally release 5.x-1.7...

"Do you mean like the when you add node content it gives you a popup to edit the node?"

I was referring to the fact that it isn't clear what the fields actually are a lot of the time. I have fields which are used in multiple content types, and these seem to be appearing multiple time - for example, I have three instances called "image" on the content add dialog, and there is nothing to discriminate between them.

Also, when I add any cck fields to the panel, I get "incorrect/missing value" or something similar, so I can't tell from that, either, which is rather annoying - I actually have to add by guesswork and save/view the panel! That's a panel issue tho I assume...

This is exactly what I've been looking for - I guess.

Could someone tell me how to use the patch?

Thanks

It would probably best to keep individual fields and groups along in the same category - if we stay on the 'one entry per field', this probably deserves a CCK-specific section on its own, meaning fieldgroups should be moved over there (they currently are in the generic 'Node Context')

Additionally, if someone is in the mood to provide icons for these two pane types, please feel free :-) (not a blocker for the patch, obviously)

I'm not seeing the 'shared fields appear multiple times in the Add Content popup' behavior mentioned by NikLP

@Patsbrady : see http://drupal.org/patch/apply

#23 As I have said in #8, and #15 the context parameters are not past to the content choosing. I have spoken to merlinofchaos about this and he is going to add this into the next release. Then we can add this to cut down the fields and groups to only display those that belong to the current context.

Thanks for working on this, gordon! :)

Merlinofchaos and sdboyer are seriously considering adding (a dependency on) Hierarchical Select to Panels 2. They want to use it for Panels' Taxonomy stuff, but later possibly also for other things. Perhaps this would be another motivation to do so, and that would solve your UI complexity issue.

We should consider this carefully, because it will break people's panels if we later decide to change the way panes types are exposed (and providing an upgrade path from CCK that updates existing panels might not be easy / desirable)

I have a couple ideas to make this a bit easier to use:

1) Add the field name after the label and the field type as a prefix, the way we do when we name fields used in views, like 'Text: Description (field_my_description)'. It takes up more room but gives you a bit more idea which field is which if you have a number of fields with the same or similar labels. (I think this is what NikLP is referring to above -- if you have several fields used in different content types that are all labeled 'description' or 'image', it's impossible to tell which is which). This makes things more consistent with the Views handling, which might be helpful, too. Some of this could be moved into tooltips that would show up when hovering, others would need to show up in the display.

2) We could create a separate category for each content type with the fields (and groups) used in that content type instead of putting them all in one big category of 'Fields'.

Both of these make the selection much bigger and messier than it is now, but would make it a lot easier to figure out what you're doing. And if we do #2 with a separate category grouping for each content type and there's some way to get context into this later, we can then hide all content type categories except the one that applies.

I think these would be fairly easy changes. I'll could make a patch if anyone is interested in this approach.

KarenS:

1) Yes that's what I meant :)

2) I don't suppose it would be too strenuous to have all content types visible that were in context - if this isn't possible for whatever reason, it shouldn't be too hard to have collapsible boxes for each type...?

Thanks.

@NikLP

#2a - As has been mentioned several times, the conext is not available to the config page. So unless you want the computer to just make a guess, that can't be done.

#2b - Collapsable fieldsets require JS/jquery AFAIK and that's tricky to use when you're already inside a js popup. It may be possible to do but I don't know how easy it would be.

Michelle

Here's a patch that puts fields into groups by content type. It also adds tooltips for each field that tells you the field type and the field name.

I left fieldgroups alone since I couldn't figure out how to put them into categories with fields but still give them their own callbacks.

I think it actually looks pretty clean and easy to understand -- it doesn't seem overwhelming to me even with all the fields showing.

Did more cleanup -- added a title callback so you can see the name of the field on the panels page without opening up the settings. I think this is looking reasonably good, except that it would be nice to move the fieldgroups into the same groupings now used for fields, but that could be done later.

I also think this is an approach that will be forward compatible when we are able to tell the context, since we can just limit the displayed content type groupings to the one that matches the context.

I could go ahead and commit this if it seems like a reasonable approach. Not sure if yched is around or not, if so, what do you think?

I like the sound of it but can't actually give it a test until later today as I'm about to leave the house.

Michelle

To make this easier, here are a couple screenshots. The first shows several content type field groupings on the panel popup selector and the second shows how you can see the fieldgroup and field names in the panel without opening up the settings.

(I just made some more changes to the patch to show the fieldgroup name for fieldgroups in the same way we show the field name for fields.)

What is "Node ID" in the first screenshot? The second screenshot looks good to me.

Also, can you verify that the sea of checkboxes at admin/panels/panel-page/settings looks sane. It would be odd if the same field appears multiple times there under different content types.

"Node ID" is the context passed in by Panels and matches the way the other node context items display in the panel (like node content).

Not sure what 'sea of checkboxes' you are referring to, I don't see any such sea of checkboxes at that url, nor do I see any 'settings' page that shows the fields as checkboxes.

Never mind about the 'sea of checkboxes', I figured out what you meant. Each field shows up once for every content type, and since the content type is not in the name, you can't tell the difference, so we should add the content type to the name, or do each content type in its own group if we do it this way.

So answering your question, yes, if we do this fields used in more than one content type will show up more than once. Do you think that is a deal-breaker? Most people won't see this screen very often, not as much as the one where you add fields to panels.

I guess this is OK. If we wanted to fix it, I suppose we could add a category for 'Multiple content types'.

Karen, seems just fine to me - feel free to go ahead with this.

Just looked at the screenshot. Am I understanding right that each field will end up as a seperate content type in the main popup? And that each field will show up for each node type? Yikes, that will be a huge mess on my site. I have 10 content types each with about 15 fields and a few with even more fields. That popup is already overflowing with all my views and custom types and such. I really don't want to see 200+ entries for fields in it!

For groups, I made just one content type, "CCK Group" and you clicked on that and then used the option there to choose which group to add. Is there some reason why that couldn't be done with fields?

Michelle

Michelle, it's really the same as gordon's patch, except that he has all the fields in one big group and I have them separated by content type which makes them easier to read. We *could* do one field icon to represent all fields and one fieldgroup icon to represent all fieldgroups, but then you would have no way to select specific fields or fieldgroups that can be allowed or not allowed on admin/panels/panel-page/settings -- it will be all or none.

More importantly, that means we need multi-level form handling in the field popup. Even the Hierarchical select is not really enough to handle this because you really need a multi-step form to do this. You need a three-step process -- first pick a content type (or have one given to you), then present a list of all fields for that content type and pick one, then present a form of all the info you need for that field. Even if you munge #1 and #2 together and show all fields regardless of content type, you still need another step to select info appropriate to that field.

I'm not even sure this kind of multi-step form is do-able in the current UI, at any rate I'm not sure *I* know how to do it.

We don't have a single 'Views' icon that lets you choose which view you want, nor is there a single 'Block' icon from which you choose a block. Showing all your choices in the popup is consistent with the way the rest of Panels works.

I won't do anything with this patch until we have some consensus on this, so I'll see what others have to say.

Funny.... I've never seen that page before. Didn't know it was there. I don't really get what it does, though. I just looked at it and "mini panels" isn't checked yet I have no problem adding new mini panels to my panel pages.

I don't know how to make this work with that page. I'm not sure _what_ a good UI would be, unfortuantely. That's one of the reasons why I initially just added the groups integration and didn't go to the field level. I don't think that throwing all the fields into one popup at once is a good idea, though. Especially when it's repeated per content type. You're talking of potentially hundreds maybe even a thousand fields on complex sites. There's got to be a better way. Maybe one of the UI experts can weigh in on this?

Michelle

I had to run out for a while and that gave me a chance to think more about this. A couple ideas:

1) We break this down by content type -- add a panels icon for each content type to represent all the fields and fieldgroups in that type (which will make it possible to include or exclude fields from panels by content type, which seems like it might be useful.) That's a lot less than showing all fields, but broader than trying to represent all fields in all types in a single form. Then in the form we show all the fields in that content type. At that point a hierarchical select would be nice to show a second drop-down to select the field formatter based on the selected field, but since we've limited it to just the fields in that type, we could probably come up with one way or another to show all the options.

2) Your comment about mini-panels got me thinking that we need to have a way to put a group of fields into a mini-panel, that could in turn be included in a node panel, so whatever we do for the node form needs to work there, too.

I saw something that there is supposed to be an API for declaring default mini panels in the same way you declare default views. (I've been trying to figure out how to get it working but haven't so far). Anyway, does that lead to anything useful? Like creating a default mini-panel for each content type that starts out with a pane for every field in the type. Then you can use the mini-panel UI to delete and re-arrange the fields as you like. Just thinking out loud...

KarenS: why would Hierarchical Select *not* be able to solve this? You just create a virtual 3-level hierarchy (that's *very* easy to do):

content type > field > formatter

where "field" is displayed as "Field type: field name". Problem solved?

Wim Leers, mostly because I'm not sure that's all we need that is specific to the field. Initially the only thing we do differently from one field to another is the formatter, but I could see various fields adding in various other kinds of settings of their own that are specific to the kind of field they are, and that could take a second (or third) level form.

Maybe I'm just getting ahead of myself, hierarchical select would be very helpful, at least to get things started.

I think maybe I missed something along the way here. What is this "formatter"? I thought this was just a matter of you pick a field and put it on the panel and it displays there just like it would on the node. Are you talking about having different display settings available like on the display tab when you edit the node type?

As for #44, mini panels use the same UI as panels pages. I don't know about under the hood but from the user perspective the only real difference is that mini panels become blocks and can be put into other panels. I'm not sure making a default mini panel for each content type is worthwhile. I think you'd generally want to use the panels page ability to override the node/% path and just add the fields to that. What might be handy is some sort of button where you can say "add all fields for this node type" and have it automate adding each field as a seperate panels content type. I don't know if that would be enough of a time saver to be worth the effort of coding it, though.

Michelle

The formatter is the display option, which varies from one type of field to the next. Like dates which have a number of different ways you might want to display the date, and imagefields which have different size images. When you add fields to Views, you select a formatter for the display, and we'll need to do the same here, but you have to know which field it is before you know which formatters should be used as options.

On the mini panel, I was thinking that creating a default mini-panel for each content type that has all the fields for that content type already in it would save you from pulling each one up individually and adding it -- a process that could take quite a while if you have a lot of fields. As I said, I'm just thinking out loud about what possibilities there are to see if there are any creative ways to use this.

Actually what would be really nice would be a default node page that has everything that a node already has on it already pre-loaded as separate panes so you can easily change the layout and drag and drop everything into whatever format you like, but that's something Panels would have to initiate....

Anyway, I think we're down to either showing all the fields in the initial popup or using something like Hierarchical select. I hate to add a dependency on another module, but if Panels is going to require it anyway, then it's OK.

@Wm Leers -- how far are we away from being able to use hierarchical select? What would it take to make that available? Would you want to show it off by making a patch?

sub

The pics in #35 look great. This is all we need to make this sane until Panels actually can offer context. All seems fine to me. Will test right now and come back and complain if it doesn't work! ;p

Thanks Karen :)

Edit: slightly confused; "I just made some more changes to the patch" in #35, but there is no patch attached at/after that point - have you edited the patch as attached in #32, #33 ... or what? :/

Something I did wrong? I did "patch < panels_6.patch" in /sites/all/modules/cck - content_panels.inc from gordon's patch is there already.

[me@superhost cck]$ patch < panels_6.patch
(Stripping trailing CRs from patch.)
patching file content_panels.inc
Hunk #1 FAILED at 1.
Hunk #2 succeeded at 24 with fuzz 2 (offset -16 lines).
Hunk #3 FAILED at 168.
Hunk #4 FAILED at 191.
Hunk #5 FAILED at 352.
4 out of 5 hunks FAILED -- saving rejects to file content_panels.inc.rej

If the patch is rolled against HEAD, can someone update dev or something? Otherwise non-cvs people are boned here (like moi).

Ta!

Edit: I get similar results trying to patch #32, #33 over gordon's patch, clearly I'm missing something here, but without any instructions on this thread it's impossible to test.

You don't apply one patch to another, that won't work, you have to patch directly against the code that the patch was rolled against, which should be cvs HEAD.

(Note that we just did a major re-organization of CCK head, so I hope the patch will still apply, but I think it will).

Anyway, if there is disagreement about whether all the fields should be shown in the popup, it doesn't matter since we'll have to make a different patch.

KarenS: So I need to get CVS HEAD and patch #33 against that, ignoring gordon's patch, yes?

Sorry for the newbishness, but this will get tested as soon as I can get there.... (several hours have already passed! :p )

KarenS: merlinofchaos and (especially) sdboyer were very enthusiastic about it, mostly for the Taxonomy integration, something else that I forgot, and possibly this very issue (Panels integration). I haven't been on IRC the past 1.5 week due to massive loads of school work, so I'm not sure what their current view is. It's definitely not a final decision though.

I'll write a patch this weekend.

Rolling panels_6.patch against 5.x-1.x-dev from 6 Apr 2008 actually worked eventually - think there may have been some weird issue with the copy of the patch I got... bah.

subscribing

Thanks for the patches. I've tested Gordon's and Karen's, and both work pretty well, not sure yet which menu arrangement i prefer.

However, for me at least, they don't seem to work for ImageFields and FileFields. You can set up the field ok, but it just doesn't display anything even if the field contains a value.

subscribing

subscribing and looking forward...:)

#33 is working great for me - love it so far. I have succeeded already with imagefield, and also mediafield (w/mediafield_display).

If you are having trouble with fields displays, be sure to check that you are selecting any formatter in the pane config, where necessary; for example, I have an audio track with 1pxOut player enabled. This was appearing as "normal" (Flash object) when I was showing it through the "node content" widget, but with just a time/download link when rendered in a pane via the cck field exposure method. I had to select the formatter of "1px out player" in the pane configuration to fix this problem.

Other than that, I've had no issues. If you are struggling with this, I suggest you read the MyPlay article and panels docs to work out some of your other options.

Thanks NikLP, your comment made me try things again with different versions.

I was using the dev (5.x-2.0-rc8) version of imagefield with a patch added to allow a link formatter. When i revert to the older version it seems to works fine, now i will see if its the patch that is causing the issue or some changes in the module.

*edit* - i reapplied the patch to imagefield 5.x-2.0-rc1 and it works fine.

I discovered that the problem was due to the rc8 version (with ajax upload) of imagefield having a custom view handler, and the code in both above patches do not support this.

There are two things missing, both in the content_admin_render_cck_content function.

On approx line 119 there is a missing line:
$field_types = _content_field_types();

Then a few lines below on 134
$function = $field['type'] .'_field';
should be
$function = $module .'_field';

I've attached a new version of Karen's patch with these two changes.

subscribing

I'm still thinking about the option of using hierarchical select. The advantage is it would greatly reduce the number of icons in the panel selector to just a single 'field' icon instead of one for every field. The disadvantages are additional dependencies, not just a dependency on hierarchical select, but also on jquery interface and jquery update. That's a lot of dependencies. I assume the dependency on jquery interface and jquery update will go away in the D6 version, so it gets more palatable there. I think that's just too many dependencies to introduce for the default implementation of Panels 2 integration. Without knowing what Earl's plans are for Panels 2, my guess would be that he would be thinking the same thing and that he might wait until D6 to require it if he does require it.

Hierarchical select is still interesting because there are often requests for things like this and it would be nice to have a CCK hierarchical select field (has anyone worked on that?) But that's another issue.

I don't want to introduce dependencies, but it would be nice to have a way to use HS if it is enabled, so I have one more idea to play with to create a single huge selector that has all formatters for all fields where you select both at once, with a way to make it look nicer if HS is installed. I'll post a patch and screenshots later today if I can get it working. If not, I'm leaning toward the original patch (#33 with the changes at #62) that has all fields in the panel selection.

KarenS: I didn't get to write that patch this weekend, because I got very sick (no food would stay inside…). I hope to write that patch somewhere in the next few days.

Some remarks for your concerns:
1) the jQuery Interface dependency could be removed if I included the code for the 2 effects that I use in HS' code.
2) the jQuery Update dependency is not too bad IMHO: *a lot* of jQuery-related modules require it. However, if I manage to get 1) done, it's possible that I won't need to depend on jQuery Update anymore (IIRC, I depend on jQuery Update because jQuery Interface requires it).
3) There's a Hierarchical Select widget for CCK, albeit not *really*: it's supported for the content_taxonomy module, but it works through form_altering. I will make sure HS will be available as a true CCK widget in the next version of HS.

And your suggestion is exactly what I was going to say: use HS as a progressive enhancement, to minimize the dependencies.

I now have this working with a single field icon in the panel settings that lets you choose both a field and a formatter in the settings. I also added in the fixes noted in #62, which were still needed (good catch!) and I did a bunch of code cleanup -- got rid of references to 'cck' and simplified some of the function names and renamed them to match the file name to make it easier to tell where the functions originate if there are problems later.

I did *not* try to incorporate hierarchical select. I'll let Wm Leers try to make a patch for that when he's able.

I also did not do an extensive testing, just made sure all the options were showing up where they should and that you could add fields and fieldsets to the panels, and that everything has useful and logical titles.

I have gone ahead and committed this to make it easier to get reviews for whatever other fixes are needed. It needs to be thoroughly reviewed before we add it to an official release.

Note that as a part of the code cleanup I renamed some things, so panels you already created will probably not work any more and you'll need to delete and re-create any CCK fields and groups in those panels. And you may have to empty the panels object cache to get the new fields to show up. I figured it was OK to rename things since this isn't in an official release yet.

I just added the patch from #62 to the 5.x-1.x-dev version of CCK (Apr 6).
I looks great! Wow! But i wonder if i am not using it correctly.

I did a node override of my event content type which has several CCK fields. I wanted to show all the fields in the left hand column except for one image field on the right-hand column. So i chose the node ID content (with extras) for the left column and the image field for the right column. But the imagefield shows up in both columns (of course).

I realize that i could add just the node content on the left with no extras and add all the extra CCK fields, but then i am missing the time field and timezone fields from the event content type. What is the best way to go about doing this?

@gracearoha - Please don't change the issue settings.

@Karen - I don't have time to test this right now... Does this affect my fieldgroup patch? If so, I'll need to put a warning on the Advanced Profile page or I'm going to have a lot of confused users.

Michelle

@Michelle - yes, I changed the group name and function names to be simpler and omit the use of 'cck'. I was assuming there was nothing in production using this yet, since this is a new patch not yet in a CCK release and Panels 2 is still officially beta (and I see advanced profile is alpha). Just glancing at your code, I think the only change is that I changed what you called 'node_cck_group' to 'content_fieldgroup'. I can't be sure there aren't other ramifications, but I think that's it.

@gracearoha -- don't use patch #62 -- that patch is a direction we didn't end up going. Use the latest CCK dev version which has all the changes committed to it, no need to patch anything. You'll need the latest development version which you can get right now from cvs or tomorrow in the development nightly snapshot tarball.

Changing the status so people don't keep trying to apply a patch, but this still does need reviewers.

@Karen - Yeah, my patch to CCK actually came from Advanced Profile and it's been in use for months with a lot of users. I'd better get a warning up on the project page until I have time to update advprofile to match. I'll grab the dev snapshot tonight when the kids are asleep and check the effects.

Thanks,

Michelle

@Michelle, is it a big enough problem that I need to go back to your original naming? I prefer 'content_fieldgroup' to 'node_cck_group'. I was thinking this had only been in the CCK repository for a short time, but going back and looking it has been there longer than I realized.

The only other change that might be an issue is that if you created a block it had 'cck_group' as the module name, and there is no such module, so I changed it to 'content', since the content module is the one creating it. Which brings up the issue that the panels/fieldgroup integration probably should have gone in the fieldgroup module instead of in the content module. If we were going to clean this up properly, I'd move it there and rename the block module to 'fieldgroup'.

All other changes are to internal function names and the titles used on fieldgroup elements, and those shouldn't affect anything else.

So:

1) How big a problem are these changes going to be, given that the code has been in the repository for quite a while, keeping in mind that it has never been in an official CCK release?

2) I probably *should* move the fieldgroup panels code to the fieldgroup module before doing an official release. I don't think that will affect any other modules, but it would be cleaner (and we try to keep the fieldgroup code separate everywhere else.)

Marking this back to CNW to get this cleared up.

@Karen - You do what's best for CCK. Advprofile is a _much_ smaller module than CCK and I will adapt it and make it work. It just caught me off guard. Things going on in my personal life have meant less computer time and I haven't been able to keep up with things well. I just need to find a bit of time to install the changes and see what effect it has on advprofile and fix whatever needs fixing. I've got a warning up on the project page for now.

Sorry if my post came across as complaining. I just panicked a bit because the dev version of advprofile got left in the middle of some large changes when I got pulled away so fixing this means finishing those changes as well so I can do a new alpha that works with the CCK changes. Not your fault, obviously, but just bit of a panic on my part. I'll get over it. :)

Michelle

KarenS: more HS-related news:
1) I've removed HS 3's dependency on the jquery_form module.
2) I've removed HS 3's dependency on the jquery_interface module.
3) merlinofchaos says that he's going to make Panels 2 passively dependent on HS:

merlinofchaos: WimLeers: So my thought is to make it a passive requirement, like I am doing with advanced help for Views.
merlinofchaos: WimLeers: Because it's only needed in a few places, we simply put a message in those places "you need hierarchical select module to use this tool, blah blah blah"
WimLeers: merlinofchaos: ok. And what will be used when HS is not present?
merlinofchaos: Nothing, those pieces just won't work.

I am just finishing up getting all the code moved to the right modules -- fieldgroup panels integration to the fieldgroup module, nodereference relationships to the nodereference module, etc, and I am planning to commit it tonight so it gets into the nightly tarball.

@Michelle, you didn't come across as complaining, I just wanted to be sure we weren't breaking anything we shouldn't. I see one more thing I'd like to change while we're breaking things and before too many people are using it. There is a theme in the fieldgroup integration called 'theme_panels_content_group' and the name worries me because of the panels prefix. Themes prefixed with the work 'panels' should really be in the Panels module, and there is an outside change there could be a name clash later if the Panels module tries to create a theme with that name, so I'd like to go ahead and rename that theme to prefix it with 'fieldgroup', probably just call it 'theme_fieldgroup_panel'. Any problem with that?

@Wim Leers, great to hear this about HS. I'm breaking the non-field panels stuff out into the respective modules, which simplifies the code in the content module and should make it easier to roll a patch.

My changes are committed so they will roll into the next tarball. Adding in HS support to this can be created as a new issue. Problems that come out of this code can be created as new issues since this was about adding in field support and that task is done.

@Karen - Go ahead and rename it. I'm going to have to doc these changes for advprofile users anyway. I checked and this does break the panel page so anyone that's customized theirs will need to manually fix it. I'll just add the theme function name change into the docs.

Thanks for all your work on this. Being able to select individual fields is a great addition and worth a little growing pains. :)

Michelle

I have changed advprofile to work with the new fieldgroup content type. It was just a matter of deleting the old ones and adding the new ones so not a big deal. From my minimal testing, it seems to be working fine.

Thanks!

Michelle

@KarenS: have you rolled the patch in #33 in? Cos we are using that in production now. If there's any further mods/potential to break stuff, can you let us know? Thanks.

Everything has worked fine otherwise so far, apart from Panels periodically breaking... export to the rescue ;)

@NikLP As noted in #52, #64, #66, #71 and all the comments after #33 that questioned the way #33 worked in installations where there are lots of fields, I went in a different direction to avoid having all the fields showing up in the panel selector. We now have a method where you see a single option in the selector to pick a field and then you choose the field on the second screen, and Wim Leers will make a patch to make the second screen look better if you have Hierarchical Select installed.

I just installed the latest dev snapshot (Apr 30) and am still having the same issue that i reported in #68.
Perhaps this is designed only for "pure" custom content types?

I did a node override of my event content type which has several CCK fields. I wanted to show all the fields in the left hand column except for one image field on the right-hand column. So i chose the node ID content (with extras) for the left column and the image field for the right column. But the imagefield shows up in both columns (of course).

I realize that i could add just the node content on the left with no extras and add all the extra CCK fields, but then i am missing the time field and timezone fields from the event content type. What is the best way to go about doing this?

sub

@gracearoha the Event module would have to create its own Panels integration for its fields to show up separately. There is nothing we can do in CCK about that.

thanx for the confirmation, Karen. I was afraid of that.

also, i was just noticing that the formatter function in the content field doesn't seem to be working in panels or in a default view. It appears that regardless of the selection, the text displays in default view.

sub

@KarenS (#81): seen, brilliant.

Also note that updating to the cck 1.7 stable from cck 5.x-1.x-dev plus the patch in #33 has no adverse affects. Which was nice...

Great work - sub

Ok, why are people subscribing to a fixed and committed issue?! Your browser has bookmarks, people. :P

I apologize to everyone who's tracker just got this issue bumped but maybe it will be the last time. LOL

Michelle

graceahora is right:

the formatter function in the content field doesn't seem to be working in panels or in a default view. It appears that regardless of the selection, the text displays in default view.

Not sure if this constitutes a new issue or not. Feels like the same issue. Also not sure if the CCK fix is good and the rest is a new issue for Panels. I'm also kind of scared to reopen a fixed issue, but I'm trying very hard to get this whole method to work and I've hit a wall with the formatter problem.

Panels 5.x-2.0-beta3
Content Construction Kit (CCK) 5.x-1.7

In fact, the formatter function does not work outside of panels either, so it must be a CCK issue. (i am using the CCK dev version of Apr 30)
Should i create a new issue?

Confirmed that the formatter does not work on imagecache/imagecache thickbox images when using imagefield field type. Images are shown with the formatter type = 'default'. The rest of my site works though, unlike #91, I don't believe this is an issue with CCK, rather with the way the formatter variable is getting passed around in the content_panels.inc.

Aside from this, things look great =]

For the sake of completeness: Hierarchical Select implementation for CCK. It's ready to play with, but not yet ready to go in.

subscribing

subscribing

content_panels.inc has gone from CVS... why that?
It has been in CCK 1.7. I wanted to submit a patch that fixes a bug, but now I'm stuck...

Hmm... There's nothing unusual at http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/cck/content... other than it's now marked dead. I suspect it got lost in the recent directory restructuring. Should probably have been moved to includes.

Michelle

The D5 version wasn't restructured, only HEAD. I still see it in cvs in the Drupal 5 branch.

Oh, you are right. I forgot to change the branch when I looked. Yup, looks fine to me, too, now. Not sure why this issue was still active but putting the priority back to what it was.

Michelle

err... I somehow had a cvs sticky tag applied to my checkout. Sorry.
Reverting status to fixed.

If I get it right, this is about Panels 2.x integration for CCK, isn't it? It doesn't seem mentioned anywhere in this topic. The only clues where the screenshots.

Cause if it was fixed for Panels 1.x, I would have a problem having them displayed as fields. The reason for this post in a fixed issue is that I can't use Panels 2 on my production site, beacuse it's still Beta (it's either too complicated for me to set up, or not stable/secure enough.)

Thanks in advance for the answer (you may change the topic's title to reflect it), and congrats towards the content of this post!

Greetings, Arsène

Panels 1 is in maintainance and new features are going into the 2.x branch, so anything talking about adding something new would be referring to panels 2. That said, it doesn't hurt to add it to the title, so I did so.

Michelle

Almost correct: Panels 1 is actually deprecated and Panels 2.x is already considered RC quality. Dunno whether the upgrade path form Panels 1.x to 2.x works, but if not, you should report a bug in Panels' queue. Of course, test that on a development site first and backup your site in front of testing.

Oh? I didn't realize panels 1 wasn't even getting bug fixes at this point. I stand corrected, then.

The upgrade worked just fine when I did it around panels beta 2 or so. The panels_by_term view even continues to work, which was awesome.

Michelle

What's the deal with this currently? Has it been integrated? Is there a patch for the current 5.x version? I would love this feature but can't figure out how to get it!

Thanks.

The panels integration in D5 was committed a long time ago.

Michelle