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.

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.

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.

Rerolled against today's HEAD.

Why did it suddently stop passing ?

Revised version for today's head.

Rerolled from root..

Patch format problem. Grrr.

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

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

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.