Be able to create fieldsets

There were some other requests like this and I tried to find them all to reference everything to the same thread, but can't find them now.

+1 on the idea, I think it will be important to be able to do some kind of grouping of fields in both the input form and the node view. I don't think it will be that hard to do, but I don't think it can really be addressed until other core work has stabilized (like database structure, some sort of process for how output is going to be themed, and decisions about whether themeing will be the work of content.module or the field module.)

Anyway, I think this needs to stay on the radar screen for later.

Very good and useful idea...

+1 from me too - currently my CCK forms are a complete mess and this would be very welcome.

I add myself to the queue :)

this cool (but also logic and quite necessary from a ui point of view) feature would probably save people from writing custom modules just to display a more user-friendly submit form!

+1 for me too

also +1 from me - would be a really nice feature.

I will start working on this in the next days.

Are new features still welcome in cck (4.7?). Of course I would provide a patch against cck cvs too.
Or should I try to implement it as a separate module?

I started some work on this (see my post at http://drupal.org/node/63240). I have a process working to create the groups but am still working out ways to get the view to display the grouped fields (the form works fine because of the form api). It also needs a way to assign weights to the groups and to allow them to be collapsible or collapsed.

I took the approach of making it a separate module. That keeps the cck code simpler and I don't know that everyone needs this. I'm headed out of town so won't be able to continue on this until I get back, but I will clean it up more when I return. If it is needed sooner, I guess I could post my still-incomplete module as a starting point or example, but I'd rather wait until it's cleaned up a bit more...

BTW fago, that is not intended to keep you from creating something yourself if you want to, especially if you need it working right away. I just want to let you know that someone has at least taken a stab at this.

ah, great.

It would be nice if you could share your incomplete code, because I need it quite soon and it makes more sense to join forces.. So I would improve your module rather than creating another one.

However I don't care that much about grouping the view.

as i've indicated on the devel mailing list, i'm way into this feature. ;) if folks could start posting their incomplete code as patches to this issue, that'd be a great start. also, note that eaton has a patch for core that would allow the node body to be rendered via a structured array, much like the FAPI $form array. i think this would completely solve the remaining problems KarenS mentioned in #7. see http://drupal.org/node/74326 for more. that patch is currently RTBC (ready-to-be-committed), so i'm guessing it'll be committed in the next few days. once that's done, i think it should be entirely possible to get this into the HEAD version of CCK (which there is now a copy of in core! -- see http://drupal.org/node/62340 for more on that). given that CCK now lives in core (i guess we're calling it "CCT" for now -- Custom Content Types), i'm moving this issue into a different issue queue. i'd still be interested in seeing this in the 4.7 version of CCK itself, but we can worry about backporting it later.

i guess the "field.module" (the CCK fields and input widgets) still isn't in core at all. ;) therefore, moving this issue was a little premature. let's see the feature added in CCK itself (i'd still vote for doing it in 4.7, in fact) and once the CCK/CCT field stuff is in core, we can worry about moving the issue into that other queue...

I needed a working solution so I wrote one.. I've created a project for it:
fieldgroup

It works already, however it only cares for the node editing form.
Field groups can be set to be collapsible and can have descriptions.

@KarenS: Perhaps you could base your more advanced features (access rights, presentation) on my module, or separate them in your own module, which is invoked through my module?

I'm closing this issue, as there is a solution now.

Sorry for the delay in responding, I've been out of town. My effort is in my sandbox at http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/karens/fieldg.... My goal was to create groups of fields both for presentation and access control so I can create an admin-only group of fields that other users cannot edit. I then was trying (not really succeeding) to get the view to create the same groupings as are used in the form. I added two tables -- one to describe the groups and one to link fields to groups.

Looks like we were posting at the same time. I'll take a look at your module fago.

It is reasonable to me to have this functionality in core CCK, so lets reopen this until this feature is deemed worthy or not.

So, has anyone used fago or karen's modules? Any feedback?

Since nodes are rendered by drupal_render() in HEAD, it is now simple to group fields for presentation in addition to the form.

I've used fago's fieldgroup module and it has worked fine so far. I agree that this functionality should be included in CCK core. I haven't used the module by KarenS yet.

I quit working on this when fago created the fieldgroup module, so my effort is probably not the one you want to use :-)

Would it be possible to make a fieldset dependent on a select list or radio button, so that you'd see certain ones based on what is selected higher up in the form?

If jonbob is willing to have this feature in cck core, I could have a look at it

Fieldgroup works fine for me too, thanks fago so very indispensable feature!

Drupal 4.7.2

KarenS - any feeling about whether this feature is core worthy? i think so.

Yes, I think it probably is, but it kind of skirts the edge of what I'm supposed to be doing (i.e. add no new features). If we get other votes for adding it to core, I would have no problem with that. It does seem to be a fairly indispensible feature if you're using more than one or two fields, and it would probably be helpful to others to have it packaged in with the core modules.

yep, I also agree that it would be core worthy.

@fago, if we add this to core you won't be able to commit changes to it yourself any more, and I don't have any ability to make you a committer. Would that be any problem? Also, can you check if any update is needed for 5.0 and get that in and tested?

i can certainly grant fago commit access to the main CCK module if that's desired. please don't let that stop progress on this front. ;) i'm sure Jon* would be cool with that, especially if there's an agreement that fago only commits to the fieldgroup stuff directly, and only commits to other parts of the code after the usually issue/review/RTBC cycle from other CCK developers (which is basically the agreement i have with Dries et. al about project*.module).

cheers,
-derek

I would have no problem with not being able to directly commit code any more, but of course I would keep on maintaining fieldgroup in core if it is desired.

I can upgrade fieldgroup to 5.0 in the weekend.

@fago - any progress on fieldgroup 5.0, and/or fieldgroup in cck itself

sry, I've been quit busy these days.

I've just ported fieldgroup to 5.x. It seems to work for me - but please test it carefully. I've not integrated new features like output-grouping yet.

I had some troubles with the branches and their releases, however creating the 5.x branch worked so hopefully release creation is working for it too.

FYI: i helped fago fix his tag vs. branch woes, so fieldgroup should be happily generating 4.7.x-1.x-dev snapshots now (next cron job fires in about an hour).

yep, everything is working fine now, thanks dww.

the fieldgroup 5.x module is working for me, however wnorrix had troubles with it:
http://drupal.org/node/100808

Any further testers?

@derek, can you go ahead and give fago commit access to CCK? Also, what needs to be done to get rid of the separate project page once this is done?

@fago, as soon as you are comfortable with it, why don't you go ahead and commit it. We are currently maintaining HEAD, 5.x, and 4.7 branches. Looks like you'll need an info file, too. Not sure what to do about the readme.txt. Probably just add whatever is still relevant to the CCK readme.txt since there's not much to it.

i just granted fago commit access to CCK.

good question about the stale project node once he commits everything into CCK core. there are a handful of issues still in the queue (some active), that i guess should be moved into the CCK queue along with the code. ;) there's no good admin interface yet for doing these sorts of bulk issue reclassification (though we certainly need it in many cases). for now, it's not *that* many, so i guess you can just reclassify the live ones manually.

after that, we should probably just unpublish the project node.

cheers,
-derek

OK, fieldgroup is now officially a part of CCK core. Thanks fago for a nice addition, and thanks derek for you help!

seems like we should unpublish all of the old fieldgroup project's release nodes in the short term. in the medium term, once everyone's migrated, we should just unpublish the project itself. any objections to step #1? btw, thanks for moving all the issues and disabling the issue queue, that's perfect.

-derek

Makes sense to me. @fago, any reason not to do this?

no, please do it!

done. i also disabled releases on that project (under "Advanced options" in http://drupal.org/node/78555/edit/releases) so none of the release-related links show up on the project page, and the project will no longer show up on the project browsing pages.

cheers,
-derek