Closed (fixed)
Project:
Node Reference URL Widget
Version:
6.x-1.11
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
30 Apr 2011 at 03:04 UTC
Updated:
31 Aug 2011 at 21:57 UTC
Jump to comment: Most recent file
Comments
Comment #1
quicksketchProbably the same as #1142440: Wrongfully named links generated when having multiple content types refering to same node type (wrong scoped variable)
Comment #2
asb commentedThanks; the patch from #1142440 applies cleanly, but the lost link does not reappear; either it's a different issue, or the patch might not be perfect.
Comment #3
steeph commentedI have the same problem. All but one link are not there anymore.
Edit: Sorry, downgrading to 6.x-1.8 brought the links back. So it might rather be a problem in 6.x-1.9 and not 6.x-1.10.
Comment #4
zsim commentedHi, everyone!
Please, try out my patch.
Comment #5
asb commentedHi,
the patch from #4 collides with the patch from #1142440. However, it applies cleanly against 6.x-1.10 and fixes the issue for me. I dont know yet if there are any negative side effects.
Thanks!
Comment #6
zsim commentedI`ve just looked at #1142440. You can apply my patch and do not use the #1142440, it solves both of the problems.
Comment #7
asb commentedGreat!
Comment #8
it-cruonly using patch from #4 works for me too
Comment #9
goldlilys commentedIs it just me but even after applying the patch on #4, though I do get the "add new content" text back, the links point to an Array and not the node id so the url doesn't get populated correctly.
Downgrading to 6.x-1.8
Comment #10
asb commented@goldlilys: What's in the array?
PS: I believe downgrading is not a good idea:
Comment #11
quicksketch@goldlilys: Make sure you're running the latest version of Drupal 6. I don't think all versions of Drupal 6 supported arrays for the query string.
I've committed this version of the patch with a port for Drupal 7. It's identical to #4 except I flipped around the order of the array so that it's
$instances[$target_type][$field_name]instead of$instances[$field_name][$target_type]. This makes it so that the "alternative format" is only used when there are two Node Reference URL Widget on the same content type instead of doing it when there are two Node Reference URL Widgets on the entire site.Comment #12
goldlilys commentedAlright i upgraded to 6.x-1.11 . It works now, but the link still looks like this /node/add/[content-type]/nid?Array .
The Array word is literally "Array" string . Not sure where that's coming from. And yes, my drupal is the newest 6.20 version. Besides the Array string being added, everything else works fine. It populates the node reference and gets saved.
Comment #14
steeph commentedOh, I forgot to report. It's working fine now after I updated to 6.x1.11. Thx!
Comment #15
ophelia commentedThank you, zsim! Your patch worked great for me.
Here was my issue after updating this module, in case other people run into a similar problem:
I am using a complicated views photo gallery involving about 6 modules in which the gallery images are saved to a directory created based on the gallery date, which gets passed through the URL and automatically filled in a hidden date field in the image form. After I updated to the latest Node Reference URL version 6.x-1.11, suddenly when I clicked "Add photo" from my gallery, the URL read ".../node/add/gallery-image/4454?Array&gids[]=" instead of "../node/add/gallery-image/4540?destination=photos%2F2011-08-31". (or whatever the gallery date is) This was working beautifully for months until the update and it took me almost an entire day to figure out that it was THIS particular module update that was changing where my photos were getting stored. Thanks to zsim for this miracle patch and hopefully if someone else is using this module similarly, maybe this will save you hours of work too. : )