It would be nice to be able to filter products from product types through a view instead of only selecting the product type.


rszrama’s picture

Title: Add the option to select products from a view in the product reference field besides selecting the product type » Update product reference field widget to allow a Views based product options list

Just giving this a little easier issue title for myself. The idea is to allow the user to choose a product View as the means of populating the options list of a product reference field widget.

hunziker’s picture

An issue I come across that relates to the above issue, is that we should filter the not allowed products in the "select list" widget. Because the selection leads always to an error.

rszrama’s picture

Oooh, yeah. I'll look around, b/c I think we have an open issue for that.

rfay’s picture

Interested in looking at this.

rszrama’s picture

That'd be great, Randy. : )

AdamGerthel’s picture

This sounds like a much needed feature. The way (unlimited) reference fields worked in D6 was even better than it is now, because with the current solution it's extremely tedious to rearrange referenced products.

Damien Tournoud’s picture

Component: Product reference » Contributed modules

It seems to me this is contrib material for 1.0.

Damien Tournoud’s picture

Issue tags: -dcsprint5
chriscalip’s picture

any links to the contrib module? any sandbox out there?

chriscalip’s picture

Started working on this:

Here's my plan:

I want a field widget that accepts a view as its input source; initial scaffold code to be copied from viewfield

The field value gets updated only on hook_entity_update hook_entity_insert

The display formatter will be using the display widget from the module commerce product_reference (dunno if possible)

So the workflow is like this
a.) User goes to a product reference field then selects a view input source through the product_reference_view widget.
b.) the submit handler of the product_reference_view widget formats the array settings to be product_reference compliant
(an array of product id's)
b.) the display formatter will be using whatever product_reference is doing.

The implementation plan is located at:

chriscalip’s picture

Pulled it off:
First working prototype available.

Please review code and help it be better! Video Screencast coming soon.

johnv’s picture

chrispalip, did you check out the 'normal ' references module? This module creates a 'references' views plugin. here you can define a view with the relevant nodes.
The references module does not support 'Entities' but with some copy&paste/abstraction you can re-use this code.

davidwhthomas’s picture

@chriscalip hey, well done, looks promising.

davidwhthomas’s picture

I was hoping the above module would provide the view filters on the product display node form to select the relevant products, instead it appears to allow selecting a view and passing arguments to it instead.

Would be nice if user could adjust the exposed filters on the view, perhaps with ajax update.

One can hope :)

chriscalip’s picture

For comment #12

I just have a different use case and references way doing things does not work for me. The use case is most of my product displays have an average of 4,200 skus; Does checking boxes of 4,200 skus from a result set 10,000+ skus form work out? Perhaps not.
The product displays bundles corresponding product bundles types have something like 5-15 attribute fields (select list).

Also correct me if I am wrong the references (node reference) architecture of "VIEWS - NODES THAT CAN BE REFERENCED" only work per
content type. Our use case is "VIEWS - NODES THAT CAN BE REFERENCED" should work per node.

For example if I went ahead with node references architecture:

Content Type: Product Display
Field: field_test_a (node references) this node references field option of "VIEWS - NODES THAT CAN BE REFERENCED"
for example does only view_a, view_b, view_c
view_a = gives out product id's from 1 to 10
view_b = gives out product id's from 11 to 20
view_c = gives out product id's from 21 to 30.

Every node form create/edit of product display gives out a node references set form of 1 to 30 then you have to check and select.

This is simply not sustainable for my use case of "Hey this particular product display node 50 will have 4200 skus"
Would I want to go to the hassle and check it? I would rather not.

Hence this widgets approach of hey this product display "node 50" will have product id's coming from View "view_ac"

chriscalip’s picture

For comment #14

David I hear you there .. its just that I was on a time crunch for a project and wanted this module up and running asap. Making use of the stable and existing modules commerce product_reference and viewfield and just doing the combo work of it was better than starting from scratch.

davidwhthomas’s picture

@chriscalip, hey no problem,

I did have a go and setup a new field api form widget for the product reference field that shows the exposed filters for a view, with configuration on the field settings for the view and display to use for the filters.

However, I got stuck / pressed for time in trying to save the default values for the exposed filters, along with the product reference selected product ids on the product display node.

I ended up taking a different route and just using views bulk operations ( vbo ) and a separate product admin view to filter the product list and then a custom "Create product display" rule to create the product display from the selected products.

That's working fine now.



chriscalip’s picture


Yeah having commerce bpc is nice. Yeah we have the same idea of "rule" from selected products.

I usually have a view with lots of "reference" displays with just different filters.

For example

1.) product display node 5 having a source viewfield of view "view_ab" with a filter of product type is A_product and field = XX
2.) product display node 6 having a source viewfield of view "view_ac" with a filter of product type is A_product and field = XX1

This widget is useful for situations that you are updating existing product displays with existing products.

joachim’s picture

> Our use case is "VIEWS - NODES THAT CAN BE REFERENCED" should work per node.

I took a look at your module, and this approach seems rather peculiar to me.

As far as I can tell, you have to edit the product node, pick a view in the viewfield, (presumably then save it so that data takes), and then the view is used to pick the products.

It sounds like what you perhaps really need is a widget based on I may be looking into that soon :)

joachim’s picture

There's now a module that provides a Views-based widget for Entity Reference fields:

Having already written code for widgets that work with entity ref / term ref / product ref, I can say that I don't think it would be too hard to provide a patch for that module to allow it to work with the product reference field type.

amateescu’s picture

Component: Contributed modules » Product reference
Status: Active » Postponed

Glad to see this issue popped up in the queue :) I think that in 2.x we should drop our custom product reference field and use Entity reference instead.

Dimm’s picture


Summit’s picture

+1 for Joachim's suggestion on #20!

Greetings, Martijn

rszrama’s picture

Component: Product reference » Contributed modules
Status: Postponed » Closed (fixed)

Closing this out b/c chriscalip's module appears to do the job and in Commerce 2.x we'll be dropping our custom reference fields in favor of Entity Reference field anyways; no need to spend time developing them further in core Commerce 1.x.