field_name is not right for any modules to use by default [#1422870]

I think that this request has come way too late in the development cycle, but can you create fields with a field collection namespace rather than generic ones like "field_name". By using field_xxx you have triggered this in the core Field module. IE:

function field_collection_entity_info() {
  $return['field_collection_item'] = array(
    'label' => t('Field collection item'),
    'entity keys' => array(
      'id' => 'item_id',
      'bundle' => 'field_name',
    ),
}
function field_create_field($field) {
  foreach (entity_get_info() as $type => $info) {
    if (in_array($field['field_name'], $info['entity keys'])) {
      throw new FieldException(t('Attempt to create field name %name which is reserved by entity type %type.', array('%name' => $field['field_name'], '%type' => $type)));
    }
  }
}

Comments

Comment #1

alan d. commented 19 May 2012 at 03:37

Category:	feature	» bug
Priority:	Minor	» Major

This appears to be could be causing issues to if the field is already created before the Field Collection module is enabled too, it is a major wtf.

I.e. Adding a field called field_name after enabling Field Collections throws an Exception. Having a per-existing field named "field_name" appears to be causing at least loss of functionality for the overridden field and goodness knows what else.

I'm getting hit with this as I'm looking after the Name Field module and people are creating fields called "field_name".

Please consider renaming "field_name" to something that does not have the Field UI defacto prefix "field_", like maybe "fieldcollection_name" or "fields_name".

As results are unpredictable, changing to a major bug report.

Comment #2

tim.plunkett

he/him

English

Philadelphia

commented 1 June 2012 at 01:14

I'm afraid it might be too late. But yes, this is a problem.

Comment #3

bradjones1

English

commented 15 February 2013 at 21:03

Yes, I was burned as well by the issue outlined in #1 - A field called "field_name" mysteriously doesn't work after beginning to use FC module. Alas, that horse has left the barn long ago it seems.

What's the proper disposition for this issue? Should this stay alive for a 7.x-2.x release or even an 8.x version? Seems like this could/should be fixed in a major version update down the road.

Comment #4

bleen commented 21 June 2013 at 14:28

Comment #5

djdevin

he/him

English

Philadelphia

commented 8 July 2013 at 18:47

Got burned.

Should stay alive for a 2.x release.

Comment #6

jetwodru commented 29 October 2013 at 22:36

Title:	Rename the field_name entity key - "field_xxx" are reserved by the field api.	» field_name is not right for any modules to use by default
Version:	7.x-1.x-dev	» 7.x-1.0-beta5

strongly agree, field_name is not right for any modules to use by default, why not adopt something similar like fieldxxxx_yyyy , xxxx = short module name, this minor issue could wreck a havoc to the entire site after enabling this module, thanks

Comment #7

dave reid

he/him

English

Nebraska USA

commented 30 October 2013 at 01:38

Because field machine names are limited to 32 characters only, so that would only be possible for a small number of modules with short machine names.

Comment #8

jetwodru commented 30 October 2013 at 01:57

but at least not so generic like field_name which is almost used by everyone when we 1st created our contact form, drupal.org may enforce a naming convention for each module posted with a unique 4-char (A-Z) identifier giving up to 456976 combinations, thanks

Comment #9

alan d. commented 30 October 2013 at 02:38

The default defacto standard would be MODULE_XXX. The field module uses the "field_" prefix, core uses "body", not "field_body" or "node_body" for backwards compatibility and DX. However this standard can not be followed as field_collection_XXX still clashes with the field module, albeit much less unlikely.

So "fc_something" or even just "fieldcollection" would be fine imho, personally thinking "fc_bundle" or "fc_bundle_key" for this use case to give the variable name some resemblance to its usage. Although I am just pretending to know what field_name is actually being used for here. ;)