Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The Node Reference module comes with a terrific widget that automatically fills the reference based on the URL (as seen on http://www.torontowebsitedeveloper.com/drupal-video-tutorials/drupal-7-n...).
Any chance to see it ported to EntityReference (which is great btw) ?
Comment | File | Size | Author |
---|---|---|---|
#50 | User Interface Example of Nodereference_url module | 51.18 KB | knowledges33ker |
#48 | Screenshot at 2012-02-20 14:33:57.png | 30.11 KB | rogical |
#45 | er-populate.jpg | 55.62 KB | amitaibu |
#44 | Screenshot at 2012-02-02 10:55:47.png | 30.75 KB | rogical |
#26 | er.jpg | 36.62 KB | amitaibu |
Comments
Comment #1
kmajzlik CreditAttribution: kmajzlik commentedi would love that :)
Comment #2
Damien Tournoud CreditAttribution: Damien Tournoud commentedAre you talking about http://drupal.org/project/nodereference_url?
If so, what's the difference with the more generic http://drupal.org/project/prepopulate?
Comment #3
hgurol CreditAttribution: hgurol commentedYes, he is talking about the http://drupal.org/project/nodereference_url
I dont know the difference with the http://drupal.org/project/prepopulate
Well, one difference I can tell; Node Reference URL has a stable D7 release and more actively maintained, while Prepopulate doesnt have release yet, not even a stable beta, and not as actively maintained.
How similar are these modules?
Comment #4
timofey CreditAttribution: timofey commentedPrepopulate module won't work because it can only fill the fields that are exposed to the user, who is creating the content.
It cannot populate the Allowed Values for a field or generate a value in a field, that is uneditable. On the contrary, nodereference_url, displays the url value in the field, disallowing the user to edit it.
Comment #5
Shadlington CreditAttribution: Shadlington commentedSubbing
Comment #6
mansspams CreditAttribution: mansspams commentedSubbing as well. This looks like task for sub-module, since we will be dealing less with entity references and more with fields and widgets.
Comment #7
leovw CreditAttribution: leovw commentedI am subscribing to this too as this would definitely be useful
Comment #8
droath CreditAttribution: droath commentedThis will allow you to pass arguments to the entity reference widget. This patch doesn't have all of the features the "Node Reference URL Widget" module has, but it has basic support for auto-populating the entity reference widget from a value in the URL.
Example:
Reference single.
Reference Multiple. (Autocomplete tags style widget)
Comment #9
Fidelix CreditAttribution: Fidelix commentedTo the maintainers:
What's the probability of this feature getting into the next version?
Comment #10
rogical CreditAttribution: rogical commentedPrepopulate has many bugs for D7 currently, and seems not very much active.
An entity reference url widget is very much need.
Comment #11
Yuri CreditAttribution: Yuri commentedI think the same functionality as Node Reference URL Widget can be obtained with Rules.
There is a very neat module, Rules Link (http://drupal.org/project/rules_link) which adds a link to an entity (or in a view) which can trigger al possible rules you can think of.
So one option would be to store the referencing page url as a rules variable, redirect to the node/add or other entity create page, populate a field with the variable. Or, you can combine it with the solution in #8.
Another similar module is the Rules Link Event (http://drupal.org/project/rules_linkevent) although less stable (alpha).
However, having a ready to use Entity Reference URL Widget module would be better.
Comment #12
bofrost CreditAttribution: bofrost commentedPatch #8 works good!
Comment #13
amitaibuI think a better solution would be doing something like in #1299174: URL parameters are not taken into account if there is no field access -- Implementing "default_value_function" callback.
Comment #14
amitaibuNo tests, because it's the end of the day ;)
Comment #16
amitaibuPatch had a white space.
Comment #17
amitaibuCorrect status
Comment #18
droath CreditAttribution: droath commentedI have one suggestion and it would be to strip out the "field_" from the field name when referencing value(s) in the URL.
Patch currently:
http://localhost/node/1/edit?field_test=1
My suggestion:
http://localhost/node/1/edit?test=1
So I rerolled patch #16 with this simple addition.
Comment #19
nicksanta CreditAttribution: nicksanta commentedI think the suggestion in #18 is potentially a bad idea as not all fields use the field_ prefix (body, for example). Not that this module directly affects that particular field, but it adds another possible wtf to the mix.
Comment #20
nicksanta CreditAttribution: nicksanta commentedPatch from #16 works - although I think there should be some validation in there first as you can simply change the default variable in the url and get a list of node titles. Possible security issue.
Comment #21
Damien Tournoud CreditAttribution: Damien Tournoud commentedI'm not sure I agree with this default value strategy. The default value function doesn't really feel designed for this. Also, I'm not sure this behavior is what you want unconditionally.
I like the idea of building a widget for that. If you select the "Get from URL" widget, the widget disappears from the form as soon as you have the parameter in the URL. We can also add an option to deal with the parameter not being in the URL: either we error out the whole form, or we fallback to another widget.
As mentioned in #20, we also need to check if the target node is referenceable, not only if the user has access to it.
Comment #22
amitaibu> I like the idea of building a widget for that
Maybe instead of a widget, we can have a setting "Allow prepopulate via URL", so it will apply to all widgets that inherit from the Base handler?
> The default value function doesn't really feel designed for this
The advantage I see in this function, is that it can set the value even if the user can't access the field, so you can pass the values via URL, and hide the field, and your entity will still have reference.
Comment #23
amateescu CreditAttribution: amateescu commentedClosed a duplicate: #1366536: How to predefine the node to link to
Comment #24
bforchhammer CreditAttribution: bforchhammer commentedI get the feeling not everyone is familiar with the Nodereference URL module, so attached is a screenshot of the widget settings form for the respective widget.
The main advantages of having a widget -- and the main features I would also like to see for the entityreference equivalent -- are the following:
The 3rd point in particular I find very useful. As an example, I have "Seminars" and "Seminar Dates". Seminar dates have a node reference field for referencing the seminar which a date belongs to. Now, on all Seminar pages I get "Add date" links which allow to easily a new date for a respective seminar. In my case all dates for a seminar are displayed embedded on the seminar page, and after adding a new date via that link, the user is automatically redirected back to the seminar page (see "return path" option in screenshot). In my opinion this provides a fairly nice "content adding experience"...
Comment #25
rogical CreditAttribution: rogical commentedMainly I use Node Referx URL widget is for build connection on Company and jobs, such types.
The owner of company creates a job node, the node should be only related to that company, and also displays company info in it.
Comment #26
amitaibuStill work in progress, just want to make sure if the approach is acceptable -- @Damz, I'm adding this as a field setting, so it will work no matter what widget we use.
Comment #27
Fidelix CreditAttribution: Fidelix commentedAmitaibu, this really does look nice.
Thanks for the great work!
Comment #28
TravisCarden CreditAttribution: TravisCarden commentedNice work, @Amitaibu! As to the approach, I think making this a field setting instead of a widget is definitely the right approach—it's much more flexible. In addition to the option to hide the field when prepopulated, I'd love to see the option to display the title of the referenced entity, optionally hyperlinked to it (if applicable).
As to the patch (#26), the basic prepopulation works great for me. Hiding the field when prepopulating and fallback behavior don't seem to do anything yet (which you probably already know, since you state this is a work in progress). The only thing I notice is that after applying the patch and running the database updates all my entity reference fields were configured to prepopulate and new fields had it turned on to start. It seems to me you would want the opposite: existing fields should be left "untouched" and manually changed to prepopulate, and new fields should default to prepopulate off. Thanks for the great work!
Comment #29
mrfelton CreditAttribution: mrfelton commentedThis is great! Same problem as #28 with the hiding part though. Field is always shown regardless of the hide_field setting.
Comment #30
amitaibu> Hiding the field when prepopulating and fallback behavior don't seem to do anything yet
Hey guys, as noted this is a work in progress, and I know it isn't working. However, before I'll invest more time on it, lets get a green light from Damien about it.
Also, let's keep on needs review, so it gets his attention.
Comment #31
clashar CreditAttribution: clashar commentedPlease confirm, do I understand it correctly as I should apply only last patch #26 and not all of the previous?
Comment #32
TravisCarden CreditAttribution: TravisCarden commentedCorrect, @clashar; you want to apply only the patch in #26.
Comment #33
amitaibu@clashar, you probably don't want to apply any patch yet, as it is still a work in progress.
Comment #34
clashar CreditAttribution: clashar commented@TravisCarden and @Amitaibu
thank you guys, I would wait till work will be finished.
Comment #35
rogical CreditAttribution: rogical commentedpatch at #26 tests well, just it's somehow a bit ugly when using 'field_eeee' field name in the url.
Comment #36
amitaibuThe patch will probably need to be completely written, to be a "behavior" plugin, after #1343854: Separate "Selection" and "behavior" to different plugins gets in.
Comment #37
rwilson0429 CreditAttribution: rwilson0429 commentedAdd another to the list of those who would love to see this popular functionality in ER. ER is a fantastic module and appears to be the only logical alternative to References and the Relations module (which does not yet have a viable UI) for D7 users.
BTW, Ignoring Amitaibu's warnings that the patch should not be applied, out of desperation for a "right now" solution, I tried the patch and it didn't work for me.
The References project page states that "References will most probably be deprecated in the near future in favor of Entity Reference". So, I am desperately hoping that ER will provide all of the key features (plus some) that we relied on in the References module.
Edit: I think that I've found a solution using References Dialog module with entity reference. It appears to provide similar functionality of the Node Reference URL widget.
Comment #38
mefisto75 CreditAttribution: mefisto75 commented@rwilson That module doesn't seem to support con. filters in Views http://drupal.org/node/1340642
What I personally find spooky is using Rules with Node Ref. URL Widget hope References incarnation of this module can provide easier/more obviuos workflow.
Comment #40
amitaibuI've created a sandbox module -- http://drupal.org/sandbox/amitaibu/1421806
It's sandbox, which means it is still not ready.
Comment #41
amitaibuOk, I've implemented some actions/ fallbacks -- I encourage you to test module from #40.
Comment #42
rogical CreditAttribution: rogical commentedInstalled http://drupal.org/sandbox/amitaibu/1421806, but nothing happens?
Comment #43
amitaibu@rogical,
Did you enable the "behavior" on the field settings?
Comment #44
rogical CreditAttribution: rogical commentedCan't found that "behavior" setting. I've tried several times.
Comment #45
amitaibu@rogical, Sorry, this is in the "instance settings" (i.e. above the field settings).
I have promoted the module, to be a full project -- http://drupal.org/project/entityreference_prepopulate , so closing issue.
Comment #46
mrfelton CreditAttribution: mrfelton commented@Amitaibu, we had been using the patch in http://drupal.org/node/1263118#comment-5406134 up until now, but would like to use your new module instead. Do you forsee any problems switching, or should the settings migrate cleanly? Does the module still use the same url query string format?
Comment #48
rogical CreditAttribution: rogical commentedJust suggest token would be very useful in some situations:
Comment #49
bonobo CreditAttribution: bonobo commentedRE 48 - this issue is closed.
You should open a new issue for http://drupal.org/project/entityreference_prepopulate , and post your feature request in that new issue.
Comment #50
knowledges33ker CreditAttribution: knowledges33ker commentedIt looks like the entityreference_prepopulate module takes care of some parts of what the nodereference_url module does but not all. In particular, the nodereference_url module has a really nice UI for creating links on the referenced node (see attached screen shot). Currently we are using nodereference_url in production to handle peer reviews of conference proposals. We would like to begin using entity reference (instead of node reference) but as it currently stands there are no modules that offer the same functionality as nodereference_url. We need this before we can shift. I can create a new issue if people prefer that but since this is still very much a part of the original issue (in post #1 above) I'm starting here.
Comment #51
fmilland CreditAttribution: fmilland commentedI agree with you..
Comment #52
bonobo CreditAttribution: bonobo commentedRE comments in 50 and 51 - this issue has been closed for over a year.
RE the default widget that came with nodereference_url - it can be replicated easily using views to generate the link (if you want a UI to create the link) or via custom code (if you want something more precise.
We always ended up modifying the node reference url widget because we always needed something different, either for design or usability reasons.
Comment #53
knowledges33ker CreditAttribution: knowledges33ker commentedbonobo: one of the benefits of the nodereference from url module is that users who don't know how to generate the link via custom code can fairly easily accomplish this via the UI that nodereference from url provides. I've never heard of using views to generate a nodereference url link as you suggest. Can you explain how that would be accomplished?
Comment #54
bonobo CreditAttribution: bonobo commentedSure.
In the view, use a block display, and display fields.
Then, add a field that gets the Node ID. Rewrite the output to generate the url you need to prepopulate the new node.
Then, set up a contextual filter that filters on the node id, and set the contextual filter to get the node id from the URL.
Then, display the block on the node types that you want to be referenced.
Comment #55
knowledges33ker CreditAttribution: knowledges33ker commentedOK, bonobo. I'm still working on this and still stuck. Above, you've outlined 4 steps.
I'm good with step 1.
I get stuck starting at step 2. You say, add a field that gets the node id. To do this, I added a new field "Content: Nid (Nid)." I assume this part is right.
Next, you say "Rewrite the output to generate the url you need to prepopulate the new node. I don't know how to do this. Can you explain this to me?
On step 3, I have used contextual filters before so I think I can figure that part out eventually. But I'm not sure about part 2 of step 2.
If I can get far enough along to figure this out, I'd be happy to create some documentation and/or a screencast video to show others how to do it as well.
Many thanks!
Comment #56
afarazit CreditAttribution: afarazit commented8: entityreference_URL_reference_1263118-8.patch queued for re-testing.