The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Patch is against HEAD revision #1171.
This patch allows options of attributes to be loaded dynamically. An example – one of many –you have a content type called 'buddy' that has the address of a friend. You can purchase a t-shirt and have as options all your friends. Every user has different friend, therefore every user will see different options…
The patch doesn't change data structure and all modules can keep working as is.
I've attached also a new module called uc options from views (remove .txt and unzip), which actually does the work of creating the options. i think this module might be considered uc core worthy, as it has a very general approach.
Some images:
* Snap1 – This is the view I created (you can import it view.txt).
* Snap2 – Product view, you can see In the options appears the title of the story nodes.
* Snap3 – In the attribute form a new section is added. You can configure exactly which view to use, and you 'tell' the system which view item is used as an option key (for example 'nid' is the option key). You also set the option key URL, which will make more sense in snap6.
* Snap4 – Options is removed and indication about dynamic is added. Note that even if there are existing static options under the attribute, they will be disregarded.
* Snap5 – Cart view lists the option properly.
* Snap6 – Remember the option key URL? That's the reason.
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | uc_options_from_views.zip | 9.77 KB | mrfelton |
| #16 | dynamic_options_3.patch | 10.98 KB | mrfelton |
| #1 | dynamic_options_1.patch | 11.42 KB | amitaibu |
| #1 | uc_options_from_views.zip.txt | 3.36 KB | amitaibu |
| #1 | Snap1.png | 9.45 KB | amitaibu |
Comments
Comment #1
amitaibudrupal has some file uploading issues, I'll try again...
Comment #2
amitaibuoops, one file was missing in patch.
Comment #3
amitaibuChanged to right status
Comment #4
rszrama commentedHmm... I'm not entirely sure of the use case for this feature, but I'm also not sure it should be in the core (mainly because it would introduce a dependency on Views). I do really like the idea, though! Essentially, it seems like this is almost like a textfield attribute that gets turned into a select list and only allows basic values. As such, you should be able to do this sort of thing using hook_form_alter() in a contributed module, correct? If so, I'd really be interested in pursuing that avenue, and I'd be happy to examine any core changes you'd recommend to make it easier to work with attributes.
I'm going to leave the status on the issue as it is, pending your response.
Comment #5
amitaibuRyan,
1. Please note that the patch doesn't rely on views. It just introduces the idea of dynamic options to core (
$attribute->dynamicflag). It's still the contrib modules' job to actually make it dynamic.2. The problem with hook_form_alter() is that it only changes the list, but the system doesn't 'understand' what is the new option. With the attached patch you can see the context of the option (snap6).
3. The advantage is that everything that is a node (with all its benefits) can become an option. Example use case:
* I have a stock of chairs in different colors: Blue, Red, Green.
* Every Color is a node.
* Only premium users can buy the Blue chair.
* The views query will return only the nodes (i.e. colors) the user can access.
Comment #6
amitaibuComment #7
rszrama commentedAhh, I see. I think I missed the fact that you were actually attaching a separate contrib module to the patch, presumably for testing? I'll give this patch a closer look. I'm still not sure we can add this into the 1.x branch of the module, but I'd be more than interested to do it for 2.x on.
Comment #8
amitaibuAnother use case:
A customer wants to buy a product according to size.
Some people use Inch some CM, so you'll need to allow sizes to be different, so with this patch Ubercart core will understand the field is dynamic, but its the contrib's module job to change the values accordingly.
Comment #9
amitaibuDo you prefer I re-roll the patch against D6?
Comment #10
rszrama commentedThat'd probably be best. I'll have Lyle look into it as well to see if it's safe to include in the 2.x.
Comment #11
amitaibuI'm also having a close look at "uc node checkout" which might be a more robust solution. I think solving #291828: Selection of product by node reference field or something similar might be considered a valid solution
Comment #12
Island Usurper commentedIf this is going to get into UC 6.x-2.0, then we'll need the patch to be re-rolled.
Comment #13
amitaibuI'll wait for a review on #291828: Selection of product by node reference field before re-rolling because I think it's a more robust solution.
Comment #14
mrfelton commentedI really like this idea and it seems like it might solve an issue which I was about to attempt to write my own patch to solve. I'm selling language courses. When buying a language course, users can choose to include one of several different accommodation options. Each one of these accommodation options already has it's own node so I'd really like to use these nodes to power the dropdown selection - preferably by using views with arguments to limit the view. As it stands now, I need to recreate these accommodation options as attributes, and manually try and keep them in sync with my nodes, which is clearly less than ideal. I haven't actually tried the patch yet - I'm just about to give it a go. I'll get back to you with my thoughts.
Comment #15
mrfelton commentedoh so this patch is against D5, damn. Has it been updated to D6 yet? Any way to get hold of it?
Comment #16
mrfelton commentedI have ported both the uc_attribute patch and the uc_options_from_views module to Drupal 6. It seems to be working, although some functionality is missing from the contrib module, specifically the ability to set per product class and per product option prices. I don't know if this was working in the original patch as I never tried running under D5 and I have been unable to pin down the exact source of the problem, although I'm pretty sure it's todo with line 645 in uc_attribute.admin.inc
Please test it out.
Comment #17
amitaibu@mrfelton,
Did you have a chance to try http://drupal.org/project/uc_node_checkout ?
I think that porting this module to D6 is a better option, as it allows having all sort of node-related benefits.
@Island Usurper, is uc_node_checkout going to be ported?
Comment #18
mrfelton commented@Amitaibu,
It seems to me that these modules do not offer the same thing. As far as I can make out, Node Checkout "allows you to map a node type to an Ubercart product" - This effectively allows users to create a node of a particular type, and have Drupal add a specific product to the cart at the same time, which references this newly created node. Perhaps I'm wrong, but it doesn't seem like this offers dynamic attributes powered by Views. Infact, it doesn't seem like it has anything todo with attributes at all! I have no interest in letting users create nodes on my system, I just need a way to use Views to provide attribute listings...
How do you envision Node Checkout being used as a replacement/alternative of this patch/module?
Comment #19
amitaibu@mrfelton,
uc_node_checkout allows an admin to create a content type , so every product can have a node associated with it that actaully specifies the attributes.
For example, if the prodcut is a concert ticket, the associated node can have the following CCK fields (which i consider as attributes).
field_date
field_name_of_show
field_reference_to_something (can use Views to create the select list).
etc'.
Comment #20
mrfelton commentedI've read and reread this thread and I think I must be missing the point somewhere. Isn't this effectively what we get by using product classes? By creating a new content type and setting it up as a product class, I effectively have a node which is a product, and this can have as many CCK fields as I need.
The thing about using product classes and attributes is that it allows me to modify the price of the product based on user selection of attributes. In your example, the products associated node has CCK fields, which you are calling attributes, but can these fields modify the products price? How does a user go about selecting their attributes?
Comment #21
amitaibuhttp://www.bywombats.com/blog/ryan/08-05-2008/lullabot-using-ubercart-co...
The new created node *is* the product attributes. Every purchase creates a new node that holds the product's attributes.
Right now I'm not sure if you can control the price of the product - but it's probably a feature that can be added.
Comment #22
mrfelton commentedRight, that's what I thought. So it doesn't (yet) do the what the dynamic options patch does since there is no way of making these attributes affect the price. A nice idea all the same, but it's not going to cut it for my needs (yet).
Comment #23
amitaibuIndeed, however IMO it's better to invest the time/ energy in a more complete and better solution.
@Ryan, Lyle - what's your take on this issue?
Comment #24
Island Usurper commentedI'm late getting back....
I think this idea should be more completely a contrib module. I feel like the patch to uc_attribute is trying to force it into something it wasn't designed for. So if you can maybe make dynamic attributes a separate system from the product attributes that exist, I think the code would be cleaner, and the UI would be easier to figure out.
I'd be interested in seeing some kind of modular system for attributes, so different modules can provide different ways to define and display options. However that sounds a lot like CCK, so that might be too much for something like this.
Comment #25
rszrama commentedMarking this as "won't fix" in core based on Lyle's feedback and inactivity.
Comment #26
raintonr commented@mrfelton. LOL, I was just reading/posting on your other thread here: http://drupal.org/node/324127
And like you am thinking that that this might solve the problem.
In my case though, am thinking that a CCK field (that would be a flexifield.module type in my case to allow the grouping required) would be chosen as the option. The view required would use the product nid as an argument and fetch all values of a CCK field that have been defined for the product being sold.
How does that sound? Possible?
Is the code in this thread being added as a contrib module?