I think a nice feature for admins would be the ability to modify the reference NID. This could be as simple as making the CCK field editable on the child node (changing the NID it refers to) or some other nice admin menu feature with mass changeability like the forum's merger feature.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | nodereference_url_edit.patch | 4.51 KB | quicksketch |
| #15 | nodereference_url_edit_fallback_v4.patch | 1.7 KB | forngren |
| #12 | nodereference_url_edit_fallback_v3.patch | 2.1 KB | frankcarey |
| #10 | nodereference_url_edit_fallback_v2.patch | 1.78 KB | WorldFallz |
| #6 | nodereference_url_edit_fallback.patch | 1.75 KB | WorldFallz |
Comments
Comment #1
quicksketchThis would be a good feature to have. I'd like to keep the normal display by default though, since it's a lot less HTML to print to the page rather than a select list with 1000+ options. Probably something like this:
Where
[ Change ]is a button that does an AJAX request to pull in a select list or autocomplete field. This way we'd keep the advantage of minimum HTML and processing by default, and only pull in the full form element when the value is going to be changed. We'd make a matching permission for "change existing node reference url widget values" on the permissions page to grant this ability. Or if we took a page out of Content's Field Access module, we'd make a permission for each field "change [name of field] field values", which would probably make its purpose more clear.This is out of scope for this module. This module only provides a widget for entering in Node Reference values. Any module that provided that functionality would be able to work on any widget type, so it shouldn't be specific to the Node Reference URL Widget.
Comment #2
Ariesto commented@quickstretch Your outline for the change feature is very good.
I think that the nodereference_formatters already has an Ajax request with functionality similar to some of what you suggest above (http://drupal.org/project/nodereference_formatters). Maybe the two of you can collaborate, or there is example code that you can examine.
I agree that keeping the html by default is good, and having a change button makes a lot of sense.
The ability to do mass changes like the Forum merger was a pipe-dream on my part, just having the change feature would be good enough :)
Comment #3
quicksketchI started this patch but ran into a few problems. Right now our entire widget's #type property is being determined by hook_widget() and when we do an AHAH request hook_widget() is never run, meaning that we don't have a way to switch the #type on the entire element. Making this change will require a significant change in the way that the widget is built, moving most of the code to nodereference_url_process(), or changing the way our AHAH callback works to somehow call hook_widget().
Here's what I have so far for me to pick up again later. Note this patch doesn't work at all, it's just in-progress code building out the skeleton of what needs to be done.
Comment #4
Leonth commentedSubscribing. Looks nice!
Comment #5
Grayside commentedI see clear use-cases for Nodereference URL to ease the creation of a new node, but thereafter to leave it alone and allow the fallback widget to take over.
Issue Trackers, for example.
Comment #6
WorldFallz commentedI took a totally different tack with this-- I needed for users to be able to change the nodereference while editing the node (in order to move images to other galleries without having to delete the image or the gallery or set the field to null).
I ended up adding an "edit fallback" setting to use the fallback upon editing the node. Patch attached in case you might find it useful.
Comment #7
oddible commented@WorldFallz: This is perfect, worked fantastic with Node Reference URL Widget 6.x-1.3. Thanks! Hope this gets integrated into the module, not sure why it was important to not offer the option to allow editing. Love the module and love this patch!
Comment #8
timhobert commentedAlong with this modification, I wonder if there's a way to allow node reference to multiple nodes. In my case I have a contact referencing a contact page. If there is a contact who needs to show on more than one contact page throughout the site I have to make multiple instances of that contact. It would be amazing to be able to add that contact to multiple pages (nodes) throughout the site!
Comment #9
WorldFallz commentedBest to create a separate issue for that.
Comment #10
WorldFallz commentedFixed a problem with the "add" link not working properly with the previous patch. Not sure how I missed this the first time around. :-|
Comment #11
Grayside commentedI tried the patch in #10.
I had to trim the first four lines off the patch for it to apply successfully.
It appears to work. Thank you.
Comment #12
frankcarey commentednot sure why, but last patch hunk 3 didn't apply cleanly. This is a new patch against latest HEAD version - jan 19th 2010. A big plus one to this. I'm using it for adding images to galleries, but we need to have users switch the gallery if they choose later.
Comment #13
frankcarey commentedAnd a note: This is totally optional behaviour, and now that autocomplete fallback is in HEAD, dealing with thousands of nodes is doable.
Comment #14
bneel commentedThe autocomplet fallback get loose of data : see http://drupal.org/node/721886
Is it possible to fix it ?
Ben
Comment #15
forngren commentedPatch works fine, I've made a new diff for 6.x-1.3.
Comment #16
quicksketchThanks everyone for your help on this issue. I updated the patch follow code standards, fix a few notices, and to work with #685038: Proposal: allow customized paths (URLs) for node reference URL widget (e.g. to use a create content form as Panels pane), which required a few tweaks. Committed the attached version.
Comment #17
quicksketchComment #19
boclodoa commentedJust for those like me: this patch has already been included in the code. Just look for a checkbox with the label "Use fallback behavior when editing content".
:)