Closed (fixed)
Project:
Plupload integration
Version:
6.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
22 Sep 2010 at 15:57 UTC
Updated:
1 Feb 2012 at 08:39 UTC
Jump to comment: Most recent file
Comments
Comment #1
justintime commentedIt turns out that I'm going to need this as well. Here's a very simple rough draft of how we could go about doing this.
There are no additional hooks being fired, all this does is look for query params that begin with 'node_', strips off the node_, and persists it all the way through to the creation of the node. It's up to the other contrib modules hook_nodeapi to actually do something with that data.
Example 1: I need to assign a 'gid' which represents the nid of the parent gallery to an image. I achieve this by hitting /file-plupload?node_gid=6250 - my node will have an attribute named gid equal to 6250.
To add an array, you can use /file-upload?node_example_array[0]=first&node_example_array[1]=second.
Again, this is a first draft POC meant to get some discussion going. Thoughts?
Comment #2
gregglesI think gid is pretty well taken by organic groups.
Is node_ the best prefix for these? Why do we need a prefix at all?
Other than that this looks awesome!
Comment #3
justintime commentedYeah, the gid decision was made long ago by someone other than me. Now I get to clean it up :/
Regarding the prefix, the reason I went with that was because the plupload applet sends chunk and chunks as URL params, so I was going to have to filter q, chunk, and chunks. It's possible (but unlikely) that a future plupload update might start passing a URL param that conflicts with something already on the node object, so I came up with the idea of a prefix. With a prefix, we *know* that it's intentional that someone wants those values assigned. It's a classic whitelist vs blacklist question.
It really doesn't matter either way to me - do you have a preference?
Comment #4
gregglesThat makes a lot of sense about the prefix. Maybe we should prefix with drupal_ ? That way we never conflict with the plupload folks (they might use node_ for something, but it's really unlikely that they'll use drupal_).
Comment #5
justintime commentedHere's a re-roll against HEAD of the 6.x branch, with a few changes.
First, I went with your idea of a prefix of drupal_, but I made it a constant so it can be easily changed later.
I also added a optional $options array to be passed into plupload_upload_page() that will be added to the $query_string array. This allows contrib modules to pass in options that get added to the node, but allow the contrib module to use their own menu router item instead of /file-plupload.
I've done a fair amount of testing with this, and it's working really well for me. It also made it much easier to integrate into node_gallery by using the params.
Comment #6
justintime commentedSorry, this time I'll include the patch :)
Comment #7
justintime commentedCommitted to dev.
Comment #8
hlykos commentedThe $options parameter doesn't seem to work to pass arrays.
If you want to pass drupal_field_parent_reference[0]['nid']=15 in the $options the array_keys function will process this to drupal_field_parent_reference=array(...) and will not insert the field.
Comment #9
justintime commented@hlykos, I just tested this, and it worked fine for me using your exact example:
I then sprinkled dpm()'s throughout the plupload module and tracked them the whole way through. In the end, my node had this on it:
Are you passing the options in via code, or URL param?
Comment #10
hlykos commentedThank you for taking the time to test this again justintime,
I pass the $options via code, but maybe the problem is that I call the plupload_upload_page function inside a hook_block.
I will test with a menu item to see if it works that way.
Comment #13
dummas_324324_32 commentedis there any new patch which works with this version "6.x-1.x-dev Download (10.18 KB) 2010-Nov-03"
thanks
mathias
Comment #14
CandC540 commentedI'm totally lost. I've tried getting this to work, but it hasn't been working for me. I currently have two content types set up. One is Gallery the other is Gallery Image. Gallery Image has two Content fields: Image (field_image) and Node Reference (field_gallery) to assign the image to a Gallery. If I automatically want to assign the Node Reference when images are uploaded, would I just visit /file-plupload?['drupal_field_gallery'][]=1 to assign the image to Gallery with nid:1?
Comment #15
CandC540 commentedAnyone still out there?
Comment #16
justintime commentedCandC540 - I would recommend looking at node_gallery's 3.x-alpha3 code for an example on how to make it work. It's been awhile since I implemented it, but it's been working flawlessly for a few hundred testers.
Comment #17
brunorios1 commentedi need the same #14 feature request...
subscribing...
Comment #18
jphelan commentedI too am confused as to how to do this. I'm just trying to set the value of a node reference field via the URL. Can some tell to how exactly to form the URL?
Comment #19
finnhappy commentedI am sorry to reopen this topic, but I cannot figure out how to solve it. In the source code I found out that it is possible to pass in the URL to the field in the content type. But what is the right syntax for it?
I have a field foo and tried all possible combination with no success. Could you point me to the right direction please?
I will also appreciate if someone knows how to pass via plupload URL the term id. Thank you.
Edit: If someone has the same problem and needs just to combine it with Node Gallery 3.x, you can use /file-plupload?drupal_gid=xxx (gid is the gallery node id).