node and user reference fields in D7 - maintainer needed

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.

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 - part II

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: [meta] Data migration from D6 contrib CCK fields to D7 Field API. 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.

And here is the complete updated module. It seems to work rather nicely on today's HEAD.

It is submitted as a patch, but since the patch is bigger than the module itself, there's also the module itself, renamed to node_reference.module.txt to allow upload here.

Now, who's writing tests ? :-)

Looks like the patch version didn't make it. Here it is.

Wow! Thanks for all this work. Unfortunately there are lots of changes that are just tweaky things like changing spacing or adding line breaks, so reading through the patch is a bit confusing. However, as far as I can see this looks pretty good, and I'm making some related changes to the user_reference module too.

I'm doing some testing, but I suspect I will go ahead and commit this because it is certainly much closer to being right than the current code is :)

And actually critical, since the current code is unusable.

Glad to see progress here. Subscribe.

I am having problems with this patch, not sure why you apparently got past them and I can't. The main issue is that the default value widget is not getting created on the field edit screen, which then throws a bunch of validation errors with the field is saved. Are you seeing anything where the default value should show up on the edit screen with your patch and the latest code?

I don't have more time for this right now, so maybe someone else can dig into it.

I mean to say 'Where you should be able to select the default value', I'm talking about just getting the field created, not trying to use it. And if I try to create the field in the UI, it shows up on the Manage fields screen but not on the node edit screen.

OK, this patch was broken by #639428: Remove #process pattern from text field and the changes in that patch need to get incorporated here. There may be other things, but that much at least involves critical changes that are needed for this patch to work again.

Change status back, and also making this issue only about node_reference. We need a separate issue for user_reference.

@KarenS: Thanks for identifying what broke this version. I was disheartened to see a field api change had broken it only days after its creation, and wondering how to find what had been broken :-) hopefully, I should be able to restore it to working status this weekend.

It's odd, that change should not have broken this, it was to make it optional whether fields use #process functions or not, so theoretically the original code should still work. So I'm wondering if the changes to head have actually made it impossible for fields to use #process or if we just have to implement something differently.

I've spent a couple hours trying to find some combination of things that would get this working and have not been able to :(

I have to work on other things now, maybe you will have more luck.

Yes, the widget changes in core ("remove #process pattern from X.module widgets") do not change the fact that some widgets might use #process like in D6 if they want to. However, noderef widgets in D6 relied on FAPI #types defined by other widgets ('text_textfield', 'options_buttons', 'option_select'), which do not exist anymore as FAPI types.

- Autocomplete widget: implementing an "autocomplete textfield" widget from scratch is simple enough, like 10 lines of code - see taxonomy_field_widget().
- Select, radios / checkboxes: options.module widgets can be reused by adding 'nodereference' to the list of field types they support, through hook_field_widget_info_alter(). 2 lines of code. Here also, see how taxonomy.module does it.
Side note: as you noted in the patch, #639466: hook_options_list() + XSS filtering (which should get in soon) will change "pseudo-hook" hook_allowed_values() into a properly defined hook_options_list().

Sorry for the changes, but in the end you'll find the widget code is tremendously streamlined.

Meanwhile, I agree with Karen that the patch already updates and cleans up *many* things and is a great step forward as is, so I'll try to commit this later tonight. Additional fixes or refinements can be tackled in smaller patches.

subscribing

Sheesh!!

noderef widgets in D6 relied on FAPI #types defined by other widgets ('text_textfield', 'options_buttons', 'option_select'), which do not exist anymore as FAPI types

Of course! That's the big problem and the reason the recent changes broke this. Don't know how I could have looked at this so long without noticing that :(

I can't work on it now, but if yched gets the original patch committed, as he said, we can do some follow-up work to fix other things.

Here is a reworked version, which no longer throws errors and mostly works: the field is usable with the select/buttons inputs.

However, for some reason, the autocomplete does not work: it displays on the edit form, the value callback formats the autocomplete results correctly, but it does not yet save its input.

It's still much better than the previous version, and indeed significantly shorter.

- Fixed a few PHPdocs according to D7 standards,
- Removed a couple unneeded functions in the widget part,
and committed. Thanks !

Other remarks:

- node_reference_autocomplete_validate() might need to be double checked - IMO the error reported in #33 happens there.

- "(code comment) node_reference_allowed_values(): A problem with this function is that its result set can be as large as the whole set of nodes on a site, which can be huge."
#639466: hook_options_list() + XSS filtering should make it cleaner. That hook is only used by optionwidgets, and they need all the valid options. If there are many, then optionwidgets are not a good UI.
Other parts of the code that check a given nid (or nids) is valid, and obviously need to be more efficient than "build the full list (possibly huge); is this nid in the list", directly call _node_reference_potential_references(), which has an extend set of arguments to limit the search.

I propose we set back this issue to the original title, and tackle later adjustments and fixes in other issues

Now that the title was reset on the discussion of the future of node and user reference, I would like to chime in.

I believe node reference will come to dominate in D7, and will make term reference redundant. If you think about it, both node and term reference aim to establish a relationship between nodes. With the massive increase in node reference modules (like:http://drupal.org/project/noderefcreate, http://drupal.org/project/node_relationships) I believe this will happen sooner than later.

Also, if you create a content type that you use as a quasi taxonomy, you get all the benefits that come with nodes, that is moderation, comments, voting that are all coveted for taxonomy currently.

This is just based on my experience, as I used to be a taxonomy fan, and now started playing with nodereference, and just by creating a new content type, and adding that content type as node reference with noderefcreate, I already have a tagging taxonomy :DDD Sweet.

So even if I am wrong, either nodereferece or termreference will perish, and be merged along the way.

I am not sure about user reference as I have not used that, but I Am sure it has a similar fate to term reference :)

I double checked node_reference_autocomplete_validate(), but it seems the problem is higher up: in that function, the value is only findable in $form_state['input'][$element['#field_name']][LANGUAGE_NONE][0], which doesn't seem correct: $element['#value'], just like $form_state['values'][$element['#field_name']][LANGUAGE_NONE][0] is a array('nid' => NULL) instead of containing the value.

@fgm: right, node_reference_autocomplete_value() was not fully updated for the new form structure (not expanding to a 'text_textfield' FAPI element in #process anymore means the structure of the arry changed a bit, we don't have two nested ['nid']['nid'] elements anymore).

Committed a code fix, but no time to actually try tonight :-/

@35; you're really talking about a developer's choice in how to design/plan their site. If someone needs a term reference, then they need a term reference, and you can't tell them to convert their taxonomies to some content type. There are so many other factors in planning whether to use nodes vs taxonomy and EVERYTHING you do should be possible to reference.

This patch to the current CVS version seems to complete your fix. References are now saved and displayed properly, it seems.

@fgm: indeed :-). I"ll commit this tonight. Thanks !

#38 I Am not saying someone should use this or that. What I am saying is that I believe it is important to realise what a "term reference" actually is. I believe we can define it's purpose as the establishment of a relationship between two or more nodes.
What I am saying is that this goal is shared by node reference as well, and hopefully we will see some consolidation...

Committed #39.

Re giorgio79: I see what you mean, but taxo terms let you do 'those two pieces of content have "this property" in common' (symmetrical, pointing to an external 'property'), and noderef lets you 'this piece of content is related to that other piece of content' (asymmetrical). With taxo terms being fieldable, I think there will actually be more freedom to use taxo classification where previously you had to create a node type (because you needed to have 'fields' on your categories themselves).
Also, taxonomy is still much more natural for hierarchical classification.

There is some overlap and tactical choices, but both core's 'taxo term reference' and contrib 'nodereference' are definitely valid.

Back to the original issue:
- I don't believe in an entity_reference.module providing an 'entity_reference' field type. Not doable IMO, and doesn't make any sense for the end user either. I know I want to create a noderef field, or a userref field, I don't want to have to select an abstract 'entityref' field type, that I then need to 'specialize' into a 'node' reference, or 'user' reference in the field settings.
- I do see value in an attempt to abstract out the most code we can to an 'entity_renference.helper.inc' file, that would for instance ship with noderef, and that other 'reference' modules, whether shipped in the same bundle or in a 3rd party module, can depend on to save the hassle of reimplementing touchy or tricky code:
provide the general framework for an autocomplete widget
provide the general framework for 'display as full object using a given build mode but avoiding infinite loops' formatters
provide the general framework for 'valid referenceable objects defined by Views'
provide the general framework for 'when editing the field, let the user search potential references using a View in a popup' (as in noderelationshps module)
(the first items really sound doable, the latter might be more tricky - let's face it, not all the features built in or on top of noderef will be easily extended to other entities)

Right now I don't intend to maintain contrib modules in D7, but this sounds like a interesting direction IMO.

#42
Thanks yched for considering my point, I also understand what you say. I hope I am not hijacking this issue but since we started this discussion let me just draw attention to an interesting aspect of nodereference.

I understand your point on nodereference that it is meant to be asymmetrical. That was the original way it was meant to be used. However, I just tried this the weekend:

1. Create 2 content types:
Content type 1, lets call it "Articles"
Content type 2, lets call it "Tags"

2. Create a node reference field in Articles for the Tags content type, (with http://drupal.org/project/noderefcreate enabled) for example. This way , as new concepts are added to the articles noderef, they are created automatically, just like in free tagging.

And BAMM I just replicated a free tagging taxonomy vocabulary, without using taxonomy at all. In addition, I Get the added benefit of moderating my Tags content type which is available for nodes, but was not available for the original taxonomy. Plus, I Also get fantastic "tag" pages with voting, comments etc etc.

I can also replicate all the taxonomy views, with nodereference views... And Sayonara taxonomy module, at least for flat vocabularies.

All I am trying to say is that nodereference rocks! I understand my way of using it is not the intended way, still I think it is awesome. :PPP

Opened #658150: Nodereference D7 port to track the state of noderef D7 port.

+1 to separating these into their own module. This issue has become more of a technical discussion, so I opened #690478: Maintainer needed for D7 versions of nodereference / userreference separately.

subscribe

So is it accurate to say, as of today with D7a3, that nodereference is in the design of core, but not yet fully implemented?

I was trying to work a solution that relied on nodereference with D7a3, but it seems I'll be relegated to D6 for now.

@bam0027: nodereference is currently in cck for D7 (cvs only), but is now called node_reference instead.

Subscribing.

SUbscribing...

subscribe

subscribe.

Subscribing, and specific issue with User Reference noted here: #843608: User reference prevents node from saving due to ambiguous uid column

And a terrible Monday morning quarterback question, why the renaming of the modules nodereference and userreference to have underscores? Odds are core won't introduce a user_reference_something() function, but why introduce the chance of namespace conflict?

The renaming was Dries' idea during the code sprint when it hadn't been decided whether or not these were going into core. He preferred this name if it was going into core and we kept it from that point on. He also rename optionwidgets to option_widgets.

Aye. That name-change took me a while to figure out. I guess the plan includes an upgrade path once things are approaching stability? Is CCK gonna be ready for the D7 release? #D7CX

The reason for renaming was, according to the coding standards, we don't munge words. The D7 version seemed a good opportunity to finally comply.

It's probably worth to take note of work that started in http://github.com/chx/awesomerelationships just recently.

Stamping http://drupal.org/project/noderelationships's features onto that idea, awesomeness.

(sorry, just subscribing)

Subscribe.

subscribe

The old CCK/D6 field nodereference module supports multiple references, while the D7 module node_reference only supports single references. What's the plan to deal with multiple node references? Will there be a new module, or will node_references be expanded accordingly? I need to model many-to-many relationships between nodes, so a multiple node reference function is necessary.

Really? The multiple feature is part of CCK/Field API. I don't think a module can opt out of that. Perhaps you have not configured your field instance for multiple.

Similar ideas as awesomerelationships in a more simple way with node reference (semantic references). http://drupal.org/node/911234
(sorry only partial relevant to this issue, tracking)

@moshe weitzman (#62):
I checked out today's CVS HEAD version and I am seeing the same problem as #61.
I tried both with 7 and "Unlimited" as the "Number of values" setting and only got one Select field on the form.

Further testing showed that the problem seems to depend on the chosen widget:
"Select list" and "Check boxes / radio buttons" do not work correctly,
whereas "Autocomplete text field" works both with 7 and "Unlimited".

Subscribe.

Subscribe. Thanks. This is needed!

Tagging

Subscribe!

subscribe

So having read through this whole thread, I propose the following:

The CCK module explicitly defines the scope of the D7 module to be:

• Handling the D6 CCK to D7 Fields migration

I think everything else should be moved into separate packages:

• Maintain PHP code snippets => Complex allowed values module, http://drupal.org/project/fields_allowed_values [any takers?]
• Field groups => http://drupal.org/project/field_group [done]
• Field permissions => http://drupal.org/project/field_permissions [done]
• Content copy => http://drupal.org/project/features

The final piece of the puzzle is then relationships between entities: I don't think we should have many separate node_,user_,comment_,term_ relationship modules, everything is an entity now and we need a package to represent that. It looks like there's some great progress on this front, so my pick for the winning horse is:

• Awesome relationship => http://drupal.org/project/awesomerelationship (and see https://github.com/chx/awesomerelationships for the code)

Other points of clarification:

• The noderelationships module (http://drupal.org/project/noderelationships) provides a complex set of tools for visualising, etc, but not the actual relationship. At the moment it depends on the CCK node_relationships submodule, but I imagine eventually it would use awesomerelationship in D7.
• Features doesn't exactly do what content copy does, but I think it's a viable replacement. It could also be handled by ctools exportables at some point.
• The user_reference module in CCK 7.x-dev is broken with an "ambiguous uid" error.

I hope this helps people get up to speed with Fields in D7. Let me know if I've made any erroneous statements or assumptions.

Cheers,
Aidan

@aidanlis - thats a great summary, IMO. Thanks.

subscribe

Subscribe

subscribe

Good call, Aidan. Awesome relationships would be a great replacement for node_ and user_references. Obviously there's some work to be done on the interface, and stuff, but it's in good hands.

Would we need to then create an upgrade path from node_ and user_references to awesome relationships?

Aidan, thank you for your time to summarize the situation. I especially appreciate your reference to Awesome Relationship module. It seems promising!

subscribe

Subscribing to this important issue enable us to start migrating D6 sites to 7.

#690478: Maintainer needed for D7 versions of nodereference / userreference marked as duplicate of this issue.

OK, retitling, then.

Subscribe

Would be good if someone with the appropriate access could update the CCK project page, otherwise this issue might be a bit hard to find with the new title yched.

done

Aidan made a fairly good case for deprecating both node_ and user_reference in favour of awesome relationships. No-one has made a counter argument yet, but it seems a bit counter intuitive to call for a new maintainer if there's a possibility that their work will be for nothing.

It would be good to get two things clear (particularly from the previous module maintainers):
1. Is there anything that node_ and user_reference can do that awesomerelationship can't, or won't do? If so, is it worth maintaining the modules just for those features? Or could they be re-written into some kind of awesomerelationship addon?.

2. (assuming 1 is dealt with) What is required to get awesomerelationship up to scratch with node_ and user_reference? And will this take too long (eg. would it be better to deprecate for drupal 8.x instead)?

There are a bunch of things in 2, mostly front-end stuff that make it difficult and buggy to use at this stage, but I doubt it's anything that can't be fixed in the next few months by a handful of people.

Let's not hijack the topic. As I said a couple times in the other issues - this is a different discussion.

awesome_relationships [edit : now renamed http://drupal.org/project/relation] is still early, largely prototype-level code. It's a whole new concept and even if full of promises, there's no guarantee that it will provide a viable and usable drop-in replacement for noderef / userref, and most definitely not in the short term. It also hasn't moved much for the last couple months, so right now it's hard to pretend there's a traction.
[edit: that last point is not true anymore, chx, sun and naught101 are actively working on the module. This does not invalidate the reasoning IMO]

D7 is (really now) around the corner, and there needs to be a solid D7 solution for the use cases noderef and userref provide, *right now*, not 3 months from now. Noderef an userref are what we have, they are far from feature complete but they are solid and reliable. It's way too early to ditch them in favor of what's still only pipe dreams of a shiny future.

The D7 porting job is done. They *work* in D7 right now. They need a proper maintainer (or more...) to :
a) get on-par with D6 versions by re-add the missing bits (Views integration) and roll an official D7-1.0 release,
b) ideally, consolidate important features provided in separate D6 contrib modules (node_relationships's popup browser widget...),
c) possibly, rock the world by making a feature-rich generic 'any-entity reference field' module come true

I just say I can't be that person in D7.

subscribe

Thanks @yched! I agree that there needs to be a supported solution really soon. Some of us are working on D7 projects already, and although it's a little early, it's good to encourage people to start using D7. It will help make things stable quicker. When the new awesome lands, it'll be possible to create a migration solution for these users.

subscribing

I don't know if this is hijacking the discussion, but to answer naught101:

There's an important difference between AwesomeRelationships and *reference modules, which makes me think it may be worthwhile to have both projects, even after AR matures. That is, with AR, relationships are themselves entities. This is a powerful and useful concept, but it certainly adds overhead (in terms of performance and complexity) that may not be necessary for every project. So a lightweight field module like *ref that stores nothing more than a entity type and an entity ID may also be desirable.

I think it makes sense to keep a lightweight reference field -- that hopefully will get subsumed into core in D8 -- and have separate projects for Other Awesome Things With References.

subscribe

subscribe

I really like the lightweight node reference module but hope Awesome Relationships (now Relation) eventually blows it out of the water.

That said, with D7's release right around the corner, I need a solution that works right now, not down the road. Node References as ported now seems to work so why deprecate it?

One argument to keep node reference: The CCK 7 module's Content Migrate currently supports an upgrade path for node references. Moving my CCK fields from 6 to 7 was much easier that way. For many more novice users, I think they are going to appreciate that ease of upgrading too.

That's just my two cents. Thanks to everyone who is working on Node Reference and the Relation module.

subscribing.

Might not be a bad idea to already create the module page(s) for the two reference modules, and issues that need to be fixed.

I'm wary of taking on anything, but I'd be willing to drop in a patch or two (or three).

Note that awesome relationships is now the Relation module, but I agree that we should let that solution evolve on it's own (I too am very interested in it), while providing something that works in the meantime.

Done: project is called References

Thanks yched for #85 - full ACK.
We have built whole web applications around D6 nodereference. What we need is a rock solid and at the same time light weight solution for D7. Right now there is a eco-system of dozens of modules around nodereference which wait (hopefully) for a D7 node_reference to settle in. Let there be one standard module and others to fine tune all the widgets, popups, optics, theming, access etc.

(I just wrote these lines to a avoid a simple "subscribing" - thanks for your work everybody. I am willing to test and report bugs.)

cheers, Ronald :-)

Per #96, is this solved?

Your point at #46, at least, is solved. Not sure whethere this completely fixes this issue.

#986502: Update home page to show new References module

Nice work fgm. If you've decided to maintain the module, then the main substance of this issue is dealt with, and considering how confusing it is to read through and figure out what's going on, I reckon it'd be a good idea to close the issue, and break out anything remaining into separate issues.

BTW, I think I agree with matt2000, and can see a future for a lightweight like this module even after relation.module is mature. Let's see how it pans out..

Tagging

Categorizing.

The References project - http://drupal.org/project/references - now has a D7 dev branch and an associated tarball, so I removed the code from CCK HEAD.

Still missing from D6 : Views integration (noderef and userref 'relationships', and the 'referenceable nodes defined by a view' feature). Patches more than welcome :-)

So, see you folks over there, and many thanks to fgm for moving this forward.