UI element to delete or re-activate inactive field instances

Here is a first stab at a patch that implements a deletion UI for inactive fields.

• Adds a second param $include_inactive to content_types() to optionally include inactive fields with the returned content type information.
• Throw this flag at various points in the admin UI so that disabled fields can be displayed and managed.

Patched against DRUPAL-6--2 branch of CCK. A quick check with simpletest show that all tests pass.

I'm supportive of this idea. We never created a UI for re-activating inactive fields because no one imagined there would be any reason non-developers would be messing around with that kind of thing. But providing this capability to solve an important Features issue that can't really be solved without it might be a reason to add this functionality, even this late in the D6 cycle.

I'm not the only maintainer, so I need to see if the other maintainers have any objections or concerns.

Well, problem is that this column has a meaning right now : the field is inactive because it uses a widget that doesn't exist anymore.

Hacking other meaning in that column, aside from making the column name completely irrelevant, means we cannot tell which field is disabled because of a missing widget (cannot be simply re-enabled) or because of user choice (UI or Feature definition).

It seems what we're talking about here is a whole new, separate feature that lets users disable or re-enable fields at will, based on a new, dedicated db column. We're not in the case of taxonomy, where Features had to hijack an existing column because taxo is core.

+ IIRC, in the past, 'disabled' fields (the ones we currently have, i.e because of a missing module) have been identified as a real pain in the butt, in terms of how do we deal with them and do the housekeeping work in a world with full citizens (enabled fields) and half citizens (disabled fields).
Part of this is because of the missing module, which means there's a part of the behavior that we don't know anymore - and this would not apply here.
But still, for every piece of code that relies on 'do something with this node type fields', you now need to ask "do I want enabled fields only (node forms, displayed nodes...) or disabled ones also (db reshuffle operations, update functions...) - or possibly disabled ones only".

Can of worms ahead...

I agree that changing the meaning without some agreement is not such a good idea.

In this issue, however, we're simply talking about a UI for deleting disabled fields, not a UI for disabling fields themselves. At the moment, if a field becomes disabled because its widget module ceases to exist there's no way to get rid of it. If that widget module got nuked off the face of this earth a user is stuck with that field and the disabled messages until he or she decides to run some queries against her database.

It's worth considering this issue/patch without concern for what Features is up to atm -- that can be a separate discussion where I think it is of legitimate concern that Features might alter the widget_active flag where it really shouldn't be.

Good point, in the Features module we should be sure not to turn back on disabled instances if their field or widget modules aren't available.

But as yhahn says, adding a UI for *deleting* fields that have been disabled still makes sense and should break nothing about the process of enabling/disabling field modules.

It actually fixes a current problem, where someone might have installed a module and created fields with it that were never used, and then uninstalled the module (or the module has become unreliable or unusable) and they have no way to permanently delete those inactive fields.

"But as yhahn says, adding a UI for *deleting* fields that have been disabled still makes sense and should break nothing about the process of enabling/disabling field modules."

True. I did take the warnings out a little quick :-). A UI to deal with disabled fields is definitely welcome, that's a topic we never set out to address properly...
Will try to review soon, but Karen, please feel free to beat me to it !

I went to try this out and found an edge case where it won't work right. I have a situation where I have a field that is shared across several content types and I inactivated one content type that we won't be using anymore. It turns out that the content_inactive_fields() function won't identify that situation, it is looking for inactive *fields* not inactive instances. So I added a similar new function called content_inactive_instances() which will find inactive instances even if the field itself is still active because it has other, active, instances.

I am going to apply this patch with that change and see if I run into any other problems.

subscribing. This is really quite important.

Publishing a workaround would be helpful too.

Subscribing.
Would be great to have this - rather not mess round in the DB to remove unneeded fields.

Subscribing. +1 for publishing a more correct and comprehensive workaround, too. I'll share mine, but it may not handle all cases.

Here's what I did in the database, with a hypothetical content type "foo" and a field named "bar". Luckily, in my case, the field I removed from the feature was only used by one content type. I'm not sure what I'd have to do if the field were used in multiple types (and therefore had its own storage).

BEFORE YOU TRY THIS YOURSELF: BACK UP YOUR DATABASE! If the commands below don't work for you, and you mess up your database, you can restore it from the backup.

Using the mysql command line:

1. Drop the affected field column from the content type:

alter table content_type_foo drop column field_bar_value;

2. Delete the affected field from content_node_field_instance and content_node_field:

delete from content_node_field_instance where field_name='field_bar';
delete from content_node_field where field_name='field_bar';

That seemed to take care of it for me.

JWHat and I spent some time with this. We found that the content_inactive_fields() function is implemented in dev CVS (although it is not in use) and merged the current patch to work with it.

One small issue that still lingers is that if you have one field with two inactive instances and you delete one, it deletes the field entirely. This happens in content_field_instance_delete() under the comment: 'If no instances remain, delete the field entirely.'

On a sidenote for #10, be careful if you run those queries on fields with instances in multiple content types. content_node_field_instance has a type_name column that you should probably be using.

I should probably subscribe to this.

subscribe

Subscribing.

sub

Have a look at CCK manage inactive fields.