What is the future of node and user reference fields in Drupal 7?

Polishing a field type takes time and effort, and a module in core gets frozen for 2 years, so unless a specific need for noderef / userref fields arises to migrate a specific core feature 'as field', they will probably stay in contrib.

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

Has a contrib project been started yet? Where to?

Will there be a base "entitiy_reference" module on which nodereference and userreference and "vote_reference" and "comment_reference" can be built?

Has a contrib project been started yet?

Nope. Current CCK 7.x branch contains in-between code for noderef and userref, with the beginnings of an initial D7 port that is now quite out-of-date anyway...
Any taker is welcome to grab this and upgrade the modules for D7 ;-).
Although I'm wondering if we should take the opportunity of the D6-D7 reshuffle to make markus's noderelationships module be the one and only 'noderef' module in D7. I've always considered that noderef would deserve it's own project outside of the CCK pack to fully flourish anyway.

Will there be a base "entitiy_reference" module on which nodereference and userreference and "vote_reference" and "comment_reference" can be built?

I'm skeptikal. Currently noderef and userref are 80% duplicates, but would be kind of difficult to actually merge. I briefly looked at this several months ago and quickly dropped. Maybe the first steps of a generic notion of 'entity' in core D7 makes this more doable, but that's highly uncertain. + I guess each '{entity-type} reference' needs its own specific features... Core's 'taxonomy term' field is actually a 'taxo term reference' field, and would be difficult to merge with a nodereference field...

I'm marking #626072: Entity reference as a duplicate of this issue. And I'm going to re-open here, so it can be discussed this feature in regards to D7...

Although I'm wondering if we should take the opportunity of the D6-D7 reshuffle to make markus's noderelationships module be the one and only 'noderef' module in D7. I've always considered that noderef would deserve it's own project outside of the CCK pack to fully flourish anyway.

Actually, Node Relationships module works only for Nodereference fields (not for user reference), and I think it's pretty tied to Node references (that's why I opted for a module name like Node Relationships). My plan was to just port the module to D7 at some point in the future. I never thought about the possibility to fully replace Node reference module, and it's hard for me to say it could be coded from a generic approach as to work for any kind of entity.

I think it would more easy to approach if entity references for D7 are implemented on their own module(s), and then we can see what can we do with Node Relationships. It seems to me this is more do-able than trying to make NR work for everything. This point of view of mine is probably conditioned by lack of time.

I think a generic 'entity reference' providing features as rich as noderef + noderelationships is very likely pipe dream at this point. D7 just saw the beginnings of a notion of 'entities', we cannot really say we have a unification layer, this will probably happen in D8+.

There's more gain IMO in merging noderef + noderelationships in a single, full featured module focusing on nodes.
User reference has always seen much less feature requests, meaning it is much less used; comment reference exists in contrib but has a fairly small install base. The future will tell if some gorgeous entity types emerge in contrib, that would strongly motivate a feature-rich 'foobar-entity reference' field, and thus raise the question of abstracting the features of the 'noderefNG' module to entities, but for now, nodes are still the big thing.

Entity support is indeed new and limited. I will be forced to make cck reference modules for drupal 7 regardless, I may look into the entity thing a bit more, if it works out I might do up a contrib module for drupal 7. It may require a few workarounds and entity specific coding which defeat the elegance of having such a module :/

How about a new title for the new direction of the discussion?

Would an entity_reference module be more doable if it followed a views-like model of extendible classes that define widgets and handlers?

I've done some work to get the head code working again with core by removing the UI bits that went into core. We are left with nodereference, userreference, fieldgroup, and some custom methods for defining things like allowed values that core won't support. We also still need a home for content permissions, since that is not in core. So there are several bits that need to live in CCK for D7 one way or another.

I don't have all the changes in yet, but just committed a number of updates. Anyone interested is welcome to continue the work. I'm only able to work on it here and there, but I'm working on the port of Date to D7 and so I'm trying to get all these bits working as I go.

Re: "home for content permissions"

http://drupal.org/project/field_permissions

Discussed here: #501404: Field Permissions in Core

We also still need a home for content permissions

It seems that the content_permissions module we shipped in CCK D6 is now superceeded by markus's wa href="http://drupal.org/project/field_permissions">field_permissions, for which he has already started a D7 port. So, markus, same question as above for noderef : do you think your field_permissions.module can be "the" successor in D7 ?
I mean, field access is hook-based, so there can obviously be several field access modules out there for different use cases, but is there a point in keeping those two ?

Other than that, crosslinking to a critical D7 task to allow a fieldgroup module to work in contrib: #616240: Make field UI screens extensible from contrib

I'm trying to finish Field Permissions for D6 (FP) as soon as possible. If you look at it, you'll see it goes a bit further than Content Permissions (CP). I tried to reproduce all role-based permissions for nodes applied to fields (create field, edit any, edit own, view any, view own). And these permission types should only be enabled per field, when really required, not all or nothing as it happens with CP.

Once the version for D6 is done, the port to D7 could be completed. To do so, we had to work on something that was still missing in D7: #597832: Add $obj_type, $object arguments to field_access() to enhance the context for hook_field_access(). That's what makes possible to check for create/edit own/view own. And things like CCK Private Fields.

I'm afraid to say if FP can be considered "the" successor of Content Permissions. I guess this is something that depends on those working directly in Fields in core, and the community itself.

I didn't see that discussion about field permissions. I think the answer is that field permissions can be the successor so long as there is an upgrade path for anyone using the D6 version of the code.

I use userreference a lot, so I want to see it live on somewhere. And we still need fieldgroup. And the CCK UI had some methods to do things not appropriate for core, like using php code to define an allowed values list (needed so people using that in D6 will have an upgrade path, if nothing else). And some module has to handle the upgrade path for fields. Will that be done in core or by CCK? I've seen various discussions but don't know where it ended up.

And some module has to handle the upgrade path for fields. Will that be done in core or by CCK? I've seen various discussions but don't know where it ended up

Well, the latest state of this topic is at #366364: Upgrade path for D6 CCK fields. Latest activity was webchick saying "this should live in core", and me replying "I don't see why or how". Other than that, no actual work has started on this, and I'm afraid it doesn't really fit in my schedule right now :-(.

tag

I need node_reference for a project, so I have to put some work on it so that it is at least marginally usable on HEAD. Anyone interested in working on it too, feel free to get in touch. I hope to submit a few patches today and in the next week.

Here is the first one:
- _node_reference_potential_references_standard() converted to DBTNG and with a bit less code running in degenerate cases
- node_reference_autocomplete() converted to latest D7 API.

Result: autocomplete path node_reference/autocomplete/<field_name>/<string> is now supposed to work.

Also, upgraded prio to normal, since the field is currently just not usable.