Controlling field must be visible on 'view' to hide the controlled fields
| Project: | Conditional Fields |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | fixed |
This block of code in hook_nodeapi() has some logic that I'm trying to understand:
<?php
// The controlled field is not in a group and is not in the form for other reasons. Skip.
if (!$controlled_group && !$node->content[$field['field_name']]) {
continue;
}
// The controlling field is not in a group and is not the form for other reasons. Skip.
if (!$controlling_group && !$node->content[$field['control_field_name']]) {
continue;
}
// The controlled field is in a group and is not the form for other reasons. Skip.
if ($controlled_group && !$node->content[$controlled_group]['group'][$field['field_name']]) {
continue;
}
// The controlling field is in a group and is not the form for other reasons. Skip.
if ($controlling_group && !$node->content[$controlling_group]['group'][$field['control_field_name']]) {
continue;
}
?>I think the code is doing what it was designed to do -- if either the controlling field or the controlled field isn't visible in the form, then the code that follows, which hides controlled fields, doesn't get a chance to run.
The case that I'm concerned about is the one where the controlling field isn't visible (because it's configured in CCK not to appear in full node and/or teaser view). Even though it's not visible, I still want it to control the visibility of the controlled fields that are configured.
Now that I'm thinking about it -- why would any of those "skip" conditionals make sense? If a controlled field already isn't in the $node->content array, why would it matter if control passed down to the checks below? I suppose it's a performance gain in that case...
So, the question really is -- why must the controlling field be visible in order to hide the controlled fields?
And one last thing -- this module is AWESOME. I was making a last ditch effort to find some code to heist while implementing a small subset when I found this thing. Thanks for taking the time to contribute this module -- it is much appreciated.
#1
To simplify this -- I'm wondering about the 2 "controlling field" comments and their related logic:
// The controlling field is not in a group and is not the form for other reasons. Skip.and
// The controlling field is in a group and is not the form for other reasons. Skip.I think there's a missing word so "not the form" should read "not on the form" -- but what I'm wondering about is -- why should we care if the controlling field isn't being displayed on 'node view' (this code's not dealing with the form)?
#2
As I think about this I still can't come up with a good answer, so I'm pretty sure this is a bug. I will provide a patch.
#3
#4
#5
Anyone care about this besides little ol' me?
#6
Attached is a patch that fixes this bug ... if indeed it is a bug, which it seems like to me.
#7
The patch from #6 is working perfectly.
Changing status to reflect the testing we have put it through.
Is this module actively maintained? Some response in this thread would be a good sign.
#8
Fixed in dev, thanks. Don't even know why I put those two checks there.
@marcp: sorry for not mentioning your patch in CVS, I regret that I had forgotten that you had provided it already (I found the issue by myself when hunting another bug).
@bonobo: yes, the module is maintained, but not very frequently. I try to keep updating cycles once every few months. I hope in the near future to be able to update it more frequently.
#9
peterpoe - you are on a roll this week, thanks for all the updates/fixes!