field_info_field only works for active fields - document that

Sorry for not being clear:

If you give file_info_field the name of a field that is inactive (but not deleted), the function will return nothing.

As of now, the documentation only states "$field_name can only refer to a non-deleted field." which to me suggests that it could refer to a non-deleted, but inactive field.

So, I guess the sentence should be changed to "$field_name can only refer to a non-deleted, active field."

It might be that the original intent was to return a field array also for inactive fields (for then, the function can be used to check if a certain field exists before attempting to create it). If that is the case, the implementation needs to be changed.

Okay, then it is only the documentation that needs to be updated.

However, given this intended behavior, field_delete_field only deletes instances of fields that are active, not those of fields that are inactive.

Calling field_delete_field on an inactive field will mean that the field itself will be marked for deletion, but not its instances. Also, unless I am very much mistaken, the data for the field will also not get marked for deletion. This is so because field_delete_field uses field_info_field to figure out what the storage engine is, and what bundles have instances. Since, on an inactive module, field_info_field will return void, the isset tests in field_delete_field will evaluate to FALSE.

So if the field to be deleted is active, field_delete_field will mark the field for deletion, as well as all its instances and data. If the field is inactive, only the field will be marked for deletion. This seems like inconsistent behavior to me, and should at least be documented.

Given the current behavior, deleting an inactive field will always result in orphaned instances/data---is that really what is intended? For one thing, it makes field_delete_field pretty useless in uninstall hooks (where the fields will always be inactive, because the module will be deactivated first). Maybe I am missing something, or am trying to use field_delete_field wrongly.

Hm, I do understand why a function like the current field_info_field can be useful for certain things, but it seems to be a really bad idea to use it in something like field_delete_field ... essentially that means that there is no way (except directly going into the database) for a module to delete its fields on uninstall. Or at least, to do so without orphaning instances and data. That is not too bad (==does not directly break) if the field in question does not have its own table, but if it does, re-activating the module will throw an error for trying to create a table that already exists.

As it stands, at least one core module (comments) uses field_delete_field and so orphans it's instances on uninstall.

I was about to open a separate issue when I found #943772: field_delete_field() and others fail for inactive fields.

There is a patch, but no activity since October 23 ...

I doubt that the other issue will make a change to field_info_field() ... the point of this function really seems to be to only return fields that "you can do something with". The patch in this issue basically avoids using field_info_field() for the deletion stuff, which is as it should be, in my view.

Maybe we should also add a reference to field_read_fields() as a means to also get deleted and/or inactive fields?