Limit list of controller fields

I'm suscribing to this issue :

Having a free-tagging taxonomy field in a content type, or a nodereference field, just make the configuration interface unmanageable as soon as the number of terms/nodes increases... whereas the required controlling field may be another field with 3 choices only for instance.

This is a good idea. Perhaps default to having it enabled, with the ability to disable it. I will see if I can work up a patch.

Here's a patch that accomplishes this.

Each field now has an option "Allow this field to be controlling" - which is turned on by default (so it shouldn't break any existing installations). If it is clicked off, then this field does not show for conditional field settings on other fields. This setting is done per field-instance, so it does not carry across different node types.

Please review the patch and commit if it looks good! Thanks!

I just applied your patch : it works perfectly for me.

Thank you! The configuration is much much easier now...

Hi, I reinstalled the dev version of this module and realized that this patch had not been committed. Are you planning to do so?

+1
having a contenttype containing several nodereference-fields with thousands of nodes in the selectlist ;)

Sorry for the delay...
Review:
if (!variable_get('c_fields_allow_controlling_'.$type_name.'_'.$field['field_name'],1)) {
this would bloat the variables table with 1 variable per field. The variable should be a per content type array.

conditional_fields_save_field($type_name, $field_name, $conditional_field_values)
check that the parameters are everywhere conditional_fields_save_field is called.

Plus: needs syncing with dev.

Is it possible to have a setting or a link in the manage fields page itself ( a checkbox near configure delete links) ? The problem is these field config pages are already not loading due to memory issues, so I cant get into those pages to make the settings change for existing fields.

or perhaps in the conditional field config settings page of that node-type.
/admin/content/node-type/[name]/conditional

peterpoe,

Thanks for this module. And thanks for responding to this problem. We are using the 6.2.0 version rather than the 6.2x.dev version.

We are now experiencing the issue alluded to in this forum. We have many nodes related to these fields. We now get a memory overload (WSOD) when we try to access two of the fields that we have created that are part of the field series/conditional fields. And, yes, we too can't edit these fields. This is a major problem for reasons that we have to edit these fields very soon to update our site.

So my questions: Has the fix you alluded to been committed and is it part of the 6.2x.dev release? And is it safe to update, ie have their been any repurcussions upon updating?

Thanks so much. (FYI, we have made a backup to the database).

g

phantom...

I share your pain. I realize this is 16 months after the fact, but in case anyone is looking at these forums for info, there is a way to at least get into the fields without damaging things. First, disable the conditional fields module. Then you can configure the field as you want because it is not calling all the other fields and draining memory.

We are actually going to go to permissions (we use the Field Permissions module) to make the fields no longer editable on the form because removing the fields will simply clear the data. We want the data.

Hope that helps.

g

Attached is a patch against the 6.x-2.x-dev 2013-Sep-30 branch that combines the patch in #3 and the suggestion in #7 of storing the variable data as a "per content type array."