Support from Acquia helps fund testing for Drupal Acquia logo

Comments

kmajzlik’s picture

i would love that :)

Damien Tournoud’s picture

Are you talking about http://drupal.org/project/nodereference_url?

If so, what's the difference with the more generic http://drupal.org/project/prepopulate?

hgurol’s picture

Yes, 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?

timofey’s picture

Prepopulate 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.

Shadlington’s picture

Subbing

mansspams’s picture

Subbing as well. This looks like task for sub-module, since we will be dealing less with entity references and more with fields and widgets.

leovw’s picture

I am subscribing to this too as this would definitely be useful

droath’s picture

Status: Active » Needs review
FileSize
1.45 KB

This 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.

http://localhost/node/1/edit?[FIELD_NAME]=[ENITIY_REFERENCE_ID]

http://localhost/node/1/edit?test=2

Reference Multiple. (Autocomplete tags style widget)

http://localhost/node/1/edit?[FIELD_NAME]=[ENITIY_REFERENCE_ID],[ENITIY_REFERENCE_ID],...etc

http://localhost/node/1/edit?test=1,2,3
Fidelix’s picture

To the maintainers:
What's the probability of this feature getting into the next version?

rogical’s picture

Prepopulate has many bugs for D7 currently, and seems not very much active.

An entity reference url widget is very much need.

Yuri’s picture

I 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.

bofrost’s picture

Patch #8 works good!

amitaibu’s picture

I 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.

amitaibu’s picture

  • Attached patch adds "default_value_function" to each ER field instance.
  • I didn't find an easy way to inject the "default_value_function" apart of doing it inside hook_field_create_instance()
  • Includes upgrade path

No tests, because it's the end of the day ;)

Status: Needs review » Needs work

The last submitted patch, 1263118-default-callback-14.patch, failed testing.

amitaibu’s picture

Patch had a white space.

amitaibu’s picture

Version: 7.x-1.0-alpha1 » 7.x-1.x-dev
Status: Needs work » Needs review

Correct status

droath’s picture

I 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.

nicksanta’s picture

I 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.

nicksanta’s picture

Patch 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.

Damien Tournoud’s picture

I'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.

amitaibu’s picture

> 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.

amateescu’s picture

bforchhammer’s picture

I 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:

  1. Fallback behavior: What should be done when the referenced node is not given via the URL? Use another widget? Display a "page not found" error? (very useful!) Or, simply leave the reference blank?
  2. Content editing behavior: what should be done when the node is edited? E.g. use the "fallback option", or completely prevent any changes of the node reference value?
  3. Node Links: add links for adding "child nodes" onto all nodes (entities) which can be referenced. E.g. on all possible parent nodes a link "Add child entity" is added, which points to the node create page for the child content type, with the reference field value filled in already (via a respective url parameter of course).

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"...

rogical’s picture

Mainly 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.

amitaibu’s picture

FileSize
7.33 KB
36.62 KB

Still 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.

er.jpg

Fidelix’s picture

Amitaibu, this really does look nice.
Thanks for the great work!

TravisCarden’s picture

Nice 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!

mrfelton’s picture

Status: Needs review » Needs work

This is great! Same problem as #28 with the hiding part though. Field is always shown regardless of the hide_field setting.

amitaibu’s picture

Status: Needs work » Needs review

> 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.

clashar’s picture

Please confirm, do I understand it correctly as I should apply only last patch #26 and not all of the previous?

TravisCarden’s picture

Correct, @clashar; you want to apply only the patch in #26.

amitaibu’s picture

@clashar, you probably don't want to apply any patch yet, as it is still a work in progress.

clashar’s picture

@TravisCarden and @Amitaibu
thank you guys, I would wait till work will be finished.

rogical’s picture

patch at #26 tests well, just it's somehow a bit ugly when using 'field_eeee' field name in the url.

amitaibu’s picture

The patch will probably need to be completely written, to be a "behavior" plugin, after #1343854: Separate "Selection" and "behavior" to different plugins gets in.

rwilson0429’s picture

Add 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.

mefisto75’s picture

@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.

Status: Needs review » Needs work

The last submitted patch, 1263118-er-url-26.patch, failed testing.

amitaibu’s picture

I've created a sandbox module -- http://drupal.org/sandbox/amitaibu/1421806

It's sandbox, which means it is still not ready.

amitaibu’s picture

Ok, I've implemented some actions/ fallbacks -- I encourage you to test module from #40.

rogical’s picture

Installed http://drupal.org/sandbox/amitaibu/1421806, but nothing happens?

amitaibu’s picture

@rogical,
Did you enable the "behavior" on the field settings?

rogical’s picture

Can't found that "behavior" setting. I've tried several times.
dd

amitaibu’s picture

Status: Needs work » Fixed
FileSize
55.62 KB

@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.

mrfelton’s picture

@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?

Status: Fixed » Closed (fixed)

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

rogical’s picture

Just suggest token would be very useful in some situations:
dd

bonobo’s picture

RE 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.

knowledges33ker’s picture

Component: User interface » Code
FileSize
51.18 KB

It 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.

fmilland’s picture

I agree with you..

bonobo’s picture

RE 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.

knowledges33ker’s picture

bonobo: 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?

bonobo’s picture

Sure.

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.

knowledges33ker’s picture

OK, 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!

afarazit’s picture

The last submitted patch, 8: entityreference_URL_reference_1263118-8.patch, failed testing.