Tags/topics: 
3
Answers
Vote up!
0
Vote down!

Should exposed filters in an entity reference view show up in commerce checkout pane?

I've created an entity reference view added as a field to the order content type. I then add it to a group and use commerce fieldgroup panes to expose that view/field in a checkout pane by configuring the entity selection mode to use the entity reference view I previously created. However, when I view this pane the exposed filters don't show up. Is this intended behavior or have I missed a configuration step. Thanks!

Asked by: jstrosch
on January 17, 2013

3 Answers

Vote up!
1
Vote down!

Could be a couple of things:

1) You're adding fields to an Order. Cool. Not a common thing to do.

2) You're adding a view via a field. Cool. Not a common thing to do.

3) You're adding this uncommon field to a group and then exposing the field using something called "Commerce Fieldgroup Panes" ... Not sure how that works

4) When you are on the pane that "Commerce Fieldgroup Panes" exposes, the view is there but there is no exposed filters. Cool problem.

Could be related to:

1) Lots of uncommon situations
2) A buggy or incomplete way to bring in a view
3) Each order is unique, so are you adding a view to the order before displaying the checkout form?

Have you tried creating a view block and having it show up on the checkout pane url? Unless you are trying to collect information, there are easier ways to get a list of something to show up on checkout. If you are collecting information, I'm not sure I would suggest using views as a mechanism to do so (usually requires a fair amount of programming knowledge).

Josh Miller
Answer by: Josh Miller
Posted: Jan 17, 2013
Vote up!
0
Vote down!

The base-line problem I'm trying to solve is to allow a user to select a node during the checkout process. There are a substantial amount of nodes to select from so I was hoping to use a view and exposed filters (and openlayers with proximity search and geofield data) to help the user refine to a single node. Then add that selected node to the order to help with back office processing. I've tried a few different approaches, the situation I described in this question is one of them. I've also tried using a custom page/pane through a module and using commerce_embed_view to display a block view. While this exposes the filters, I haven't figured out a way to allow the user to select a node to continue the checkout process.

In regards to question 3 above, the field is added to an individual commerce page/pane during checkout. The hope was that the user could use the view to filter to a single node and select that node during checkout. The node would then be saved to the order record when the order is created. It appears to work except that the filters aren't being exposed, which makes it unusable from a UX perspective.

If views are not a good way of collecting information what would you suggest? New to Drupal so learning as I go... :)

Thanks!

Answer by: jstrosch
Posted: Jan 17, 2013
Vote up!
-1
Vote down!

I ended up creating a form in hook_checkout_form() that utilizes/executes a view to return the content type I'm interested in and then add those nodes to the form as options to a radios element (get view, set filters, execute view, loop through array of results). While a great module, I had to abandon my approach using the Commerce Fieldgroup Panes module. Once the user selects a node, I can than add the NID to the field (entity refernce type) that I created on the Order. It saves once checkout completes and becomes a part of the order. One major hang-up I had in this approach was providing a minimal filter experience for the user. My approach was to provide an additional submit button for filtering. This is in addition to the buttons commerce checkout adds. At first I thought this required two submit buttons in the form: one that I add to trigger a filtering callback and the other added by commerce (continue checkout, go back). Most of my research pointed to having two form handlers for each button. However, I wanted both of them to use the same form handler. Changing the submit button I added to a button type solved my issue. Hope this helps someone!

Answer by: jstrosch
Posted: Jan 22, 2013