This is a placeholder for an update I'm making to CCK Fieldgroup Tabs 6.x.
Basically CCK Fieldgroup Tabs alter the structure of the $form by nesting fields underneath ['fieldgroup_tabs'] in "tab" fieldgroups. While this works fine for normal form submissions, some cck field elements do AHAH calls that are not aware of this, and often place their updates into the wrong area of $form or error out completely.
Lucky for us, Drupal 6 has the wonderful hook_menu_alter(), so we can override the callbacks and point them to new "modified" versions that know to check for elements within tabs.
AFAICT there are just 5 possible locations (at this point) where the element can be found currently:
- Directly in the form (no Fieldgroup, no Tab)
- Grouped in the default 'basics' Tab
- Grouped in the default 'basics' Tab in a Fieldgroup
- In a Fieldgroup in the form
- In a Tab
So this initial update attempts to find the appropriate position for the updated element. It does so for the two AHAH callbacks I've come across so far:
- CCK Multivalue fields (any cck field that allows you to "Add another item")
- Imagefield/Filefield upload elements
If/when CCK gets multi-level fieldgroup nesting this will have to be looked at again.
Feel free to post any bugs to this issue.
Comments
Comment #1
nedjoThanks for flagging the issue.
I wonder if we could avoid part of this problem by acting in e.g. a #process callback rather than directly in form_alter. Our changes are for presentation purposes and should be done as close as possible to the rendering.
Comment #2
nedjoProbably it's #after_build we need.
Register an #after_build callback, do our reformatting there.
Comment #3
Moonshine commentedAhh... Well it would certainly be nice if tabs would stay out of the way as long as possible. (like #pre_render if possible :) ) Although I'm not sure it would really help the AHAH callbacks, as they have to work with a cached $form that will already be structured/processed either way.
Really it seems like a flaw in the AHAH callbacks to me. Each callback must locate the position of the element it's changing in the cached $form, but they do so without any real universal approach or logic. CCK and Imagefield/Filefield just check if the element is in a Fieldgroup. If it isn't found, then it's assumed to be right in $form. Thus if the element is in a tab, or any other structure, there will be trouble. Even the "nested fieldgroups" being worked on for CCK would require changes for these callbacks.
If nothing else, even a well written function to recursively find the element inside $form would be fine if all the callbacks used it.
After getting burned on a couple CCK changes last month, I've just been laying low waiting for CCK "combo fields" to get wrapped up and to see if there is some final word on nested Fieldgroups (as there are a couple approaches being tossed around). I'm curious to see how these might affect the things, and thought it might be a good time to jump in if they required AHAH changes as well.
In the meantime, hopefully this will keep things usable... I won't shed a tear when it can be removed though :)
Comment #4
Moonshine commentedHmm... Actually it looks like the form is cached after drupal_process_form() but before #pre_render. So there may be hope after all :)
Comment #5
zmove commentedI didn't see this issue when I posted mine here
/subscribe.
Comment #6
verikami commentedsubscribing :-)
from duplicated: #320030: Can't see uploaded files - CCK arays for them are empty
and (in my opinion related): #342076: Patch for hiding tabs if there's no text in the tab
Comment #7
recrit commentedI am using some Flexifields and have tried to get Fieldgroup Tabs to work for my node edit form. They do not render properly and from this post I believe the AHAH callback is the issue. Is it possible to add a fix for Flexifield callbacks similar to what has been done for the Filefield?
Comment #8
nagarajugoli commentedComment #9
nedjoTabs are now created at pre_render and this has solved the issue for all the AJAX functionality I've tested.