Right now we can't move basic fields of any content type (groups, title, body, etc.) into a field group by dragging. Making them to move into a group would be really user-friendly and will make it more flexible and powerful. It will also increases flexibility to theme CCK content types, which I think will make life easy to many of the drupal themers.
There are many users requesting for this feature - http://drupal.org/node/354849 .
I can also contribute to the development of this feature but just don't know where to start. All are invited to share their views and help.

Regards
Pankaj Kumar Sharma

Comments

KarenS’s picture

KarenS CreditAttribution: KarenS commented

Repeating a reply from yched on another issue to indicate why this may not happen:

Non-fields into groups : so far we always replied by a won't fix.

fieldgroup D6 (both 2.x and 3.x) currently acts directly in form_alter. This means that the form structure is changed during FAPI form processing. If we allow non-fields within groups :
- any 3rd party module willing to act on a non-field (say, hide core node title), needs to consider whether its hook_form_alter() runs after or before fieldgroup_form_alter()
- depending on how #tree is configured up the form structure, this might or might not alter the structure of $form_state['values'], which would badly break validate and submit handlers that deal with the non-field at hand.

D7's field_group module does allow non-fields within groups, because we made sure it acts on #pre_render, that is: only at display time, once FAPI processing is over. Thus : D7 field_group is a generic "entity form organizer", not specifically related to field or non-field elements.

With some work, I guess this behavior could be backported to D6 fieldgroup (I'm not sure of the exact status of #pre_render in D6). But in turn, it's hard to predict what existing 3rd party code, relying on fieldgroup's current modus operandi, would break.

KarenS’s picture

KarenS CreditAttribution: KarenS commented
Assigned: pankajshr_jpr » Unassigned

Also 'Assigned' indicates who is planning to work on it, not who asked the question :)

pankajshr_jpr’s picture

pankajshr_jpr CreditAttribution: pankajshr_jpr commented

Thanks KarenS for such a useful information. I think still the task can be done in two ways-
1) #pre_render will surely affect the current 3rd party modules willing to act on a non-field. A better solution can be if fieldgroup_form_alter() always runs after all hook_form_alter() . And this will alter the form structure of basic fields only if they are not altered by any of the modules. I think it will not affect any third party module , they will continue to function as they are functioning right now.
Also from the node - http://drupal.org/node/354849 , it seems that the validate and submit handler are not having any problem by calling form_alter to alter the structure of $form_state['values'].
Can you please suggest what ways can be used to achieve this?

2) A separate module can be written based on fieldgroups to achieve this functionality. And users will be warned not to use any 3rd party module willing to alter basic fields along with this module :). Although it doesn't seems like a good solution, so I am willing to go for 1st.

pankajshr_jpr’s picture

pankajshr_jpr CreditAttribution: pankajshr_jpr commented

anyone else to suggest ?

KarenS’s picture

KarenS CreditAttribution: KarenS commented

I have no suggestions. It is very hard to do and I don't have time to figure it out. Things like changing the weight of the fieldgroup module will break other modules that have been functioning with it like this for a couple years.

pankajshr_jpr’s picture

pankajshr_jpr CreditAttribution: pankajshr_jpr commented

Thanks KarenS, no problems. I am trying to figure out how to achieve this, will keep posting here if get stuck in any problem.

donquixote’s picture

donquixote CreditAttribution: donquixote commented

#pre_render will surely affect the current 3rd party modules willing to act on a non-field.

How that?
Those that just do form_alter will not be affected.

But, to be 100% sure, we could make it optional, or an alternative module.
Even if we do not make this an optional extra module, then as long as the admin does not intentionally move the respective non-cck field into a group, nothing will break.

I did not look at the D7 code, but this is how I would do it:
Give each form element an additional attribute '#fieldgroup_parent', which can have a value like 'group_something'. Then on pre_render we sort these elements into the specified parent, if this parent element exists.
We only do this on non-cck fields, for the rest we use the old fieldgroup behavior - to minimize the breaking existing stuff.

doublejosh’s picture

doublejosh CreditAttribution: doublejosh commented

Simple technique just for re-arranging display?
For example this doesn't work...

function MY_MODULE_nodeapi(&$node, $op) {
  switch($op) {
    case 'view' :
      switch($node->type) {
        case 'MYTYPE' :
        case 'MYOTHERTYPE' :
          $node->content['group_MYGROUP']['locations'] = $node->content['locations'];
          unset($node->content['locations']);
        break;
    break;
  }
}

Am I going to have to create a Computed Field?