Disallow reserved field names

would you hardcode that blacklist or generate it from looking at the fieldable info of a node?

Wouldn't it be more flexible to use a hook or callback for this so any module can specify names that should not be used? Maybe on a bundle by bundle basis (the name is OK on a page bundle but not OK on my custom bundle).

I'm gonna try this one (see http://drupal.org/community-initiatives/drupal-core/fields)

I think some historical info may still need to be hardcoded, but the rest should be available from the fieldable info. Adding a hook or callback would likely add unneeded load for little benefit, as field creation is a statistically rare occurrence.

Thanks, Frederic!

IIRC the motivation behind this issue was #367595: Translatable fields and the possible "language" property.

I'm not sure why a separate hook should be needed since hook_fieldable_info() can return a list. Do we want to call a hook for non-fieldable modules to return data about fieldable entity types? Seems odd.

We have to figure out what to do if a "reserved name" shows up in the banned list after a field with that name already exists.

Currently neither node nor user makes any attempt to prevent this kind of problem. If this turns into an impossible rathole, then we don't really have to deal with it either.

Field creation is a statistically rare occurrence, so doing a bit of extra work to make sure it is set up in a way that will create other problems has no big cost. And a field that uses a name that some other module expected to be able to use could create potentially significant problems, so it seems like it has a good cost-to-benefit ratio.

Sure it hasn't come up so far, but we're going down a path we've never been on before adding fields to everything and making all kinds of things that were not fields before into fields. I have no specific use case, but was thinking about something like a modules that work together to do complex processing (i.e. ecommerce or finance) that need to know that any fields with specific names are 'their' fields. And the Node module could protect 'body', 'teaser', and 'title' and the User module could protect 'name', 'mail', and 'password' as well using the same method.

We don't have to do this of course, but there is very little cost to creating a flexible way to let modules tells us what names are not 'allowable' instead of using a hard-coded list that later breaks something.

I'd tend to think the safest way to prevent those clashes is to promote naming conventions, like : 'prefix your fields with your module's name - if you don't do this, don't come crying'. Core-defined fields could possibly be a safe exception (body, teaser, title), for legacy's sake.

OK, I'll back down on this idea. Just thought it was worth exploring.

I'm also thinking that per-module protected names only need to be protected (if they do at all) within an object type. e.g. suppose that node module protects title. Why should I not be able to create a field named title and just not attach it to nodes?

For object properties (such as 'language', if we end up using that) that apply to *every* object with fields attached, the Field API would flat out prohibit it as a field name. That was the original point of this issue.

Maybe we should hold off until we actually have such object properties used globally by field api.

also need to think about what to do when adding a new module that reserves a name already in use. for instance, one creates a ->location field, then later installs the location module.

Re arron #10 : The fields added through the UI will all have a forced prefix (probably 'field_' to stay consistent with CCK D6 names)
Modules need to follow good practice and prefix the fields they create by the module name to avoid name clashes.

Note that we just made an exception with 'body' field (instead of 'node_body'). That's probably OK here (really more straightforward for this very common field), but that doesn't set contrib up for good practice...

OK, sorry it took me so long for so little, but here is a first attempt, just to make sure this is really what this request is about.

Rerolled with added simpletest.

The last submitted patch failed testing.

Rerolled against today's HEAD.

I'm wondering if this whole issues counts as over-engineering, and we should just go with the plan in #7.

The last submitted patch failed testing.

The last submitted patch failed testing.

Why did it suddently stop passing ?

The last submitted patch failed testing.

Revised version for today's head.

The last submitted patch failed testing.

Rerolled from root..

The last submitted patch failed testing.

Patch format problem. Grrr.

I *think* the "Fields in core" tag needs to be added

Code style cleanup, improved comment (we do not reference d.o issues in code), and slight test improvement (use test_entity, not node, as part of the test case). Otherwise, works.

Minor nitpicking, but shouldn't we say ""...from the "test_entity" bundle" instead of "....from the "test_entity" type" ?

No. The revision id key is defined by the entity type. A bundle is just a name for a collection of fields to load at once.

Cool, I committed this to HEAD.

It's hard to tell from the replies above if we need to expand this out to cover more instances or not, but for now marking fixed.

Automatically closed -- issue fixed for 2 weeks with no activity.