Download & Extend

Fails to add to cart when using views global:random display

Project:Ubercart
Version:7.x-3.x-dev
Component:Code
Category:bug report
Priority:normal
Assigned:Unassigned
Status:closed (fixed)
Issue tags:dc2009 code sprint

Issue Summary

I first migrated my shop to the online server and had the nasty problem of the UID 0 dropping off and hence the anonymous cart failing to work.

The next problem I had, was tracked down to using views for one of my shop's pages where it was pulling 8 randomly chosen products and displaying them. Here products failed to add to cart from too. And the problem was intermittent. Sometimes they added, sometimes they didn't.

If I changed page the products added fine. Happened on beta 5 and beta 4.

Comments

#1

Status:active» postponed (maintainer needs more info)

Not sure what you mean by "changed page". Can you detail this a bit more. And maybe export your View and post it here?

#2

Priority:critical» normal
Status:postponed (maintainer needs more info)» fixed

Hmm... I'm going to take a stab at this and mark it fixed... we can always reopen if necessary. Basically, this isn't a bug report with Ubercart but a limitation of randomized Views and the Forms API. When the add to cart form is clicked, it submits the POST data for the form to the same URL. The View is then rebuilt on the following pageload, but it's never normally displayed to the user. Drupal depends on having the form built in the following pageload, so it will only process the add to cart when the random products chosen include the product that was added to the cart. Drupal can then process that form and do redirect upon its completion.

#3

So basically add to cart will not work when using a random view?

#4

Correct, at least without some custom module ensuring that the form you're submitting will always be present on the regenerated page.

#5

Status:fixed» closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

#6

Version:6.x-2.0-beta5» 6.x-2.0-rc3
Status:closed (fixed)» active

I have a random order "special offer" block on the front page that only shows one node. The add to cart button can be included in two ways: by including the add to cart button or by including the the form field. Both have the same problem that they wont add the product to the cart. Here a dump of the form HTML:

<form action="/es" accept-charset="UTF-8" method="post" id="uc-product-add-to-cart-form-55">
<div><input name="qty" id="edit-qty" value="1" type="hidden">
<input name="op" id="edit-submit-55" value="Add to cart" class="form-submit node-add-to-cart" type="submit">
<input name="form_build_id" id="form-8d7281a887b042445ff99e0583c6c6a7" value="form-8d7281a887b042445ff99e0583c6c6a7" type="hidden">
<input name="form_token" id="edit-uc-product-add-to-cart-form-55-form-token" value="cadc335354f677502fa3f7cc1f3809a3" type="hidden">
<input name="form_id" id="edit-uc-product-add-to-cart-form-55" value="uc_product_add_to_cart_form_55" type="hidden">

</div></form>

Attached the exported view. The "ofertas" block begins at line 980. Hope someone can fix this!

AttachmentSizeStatusTest resultOperations
random-oferta-block-with-failing-add-to-cart.txt31.01 KBIgnored: Check issue status.NoneNone

#7

Status:active» closed (fixed)

Same as before, the form can't submit with a random View because Drupal's Forms API depends on the same page being loaded as is with the same form being displayed. The random View causes the HTML to change between pageloads, which means that form no longer exists. If you can somehow work it out to use a cart link, that would work.

#8

did anybody resolve this issue?
I'm still having the problem with Drupal 6.14, ubercart 2.0 and views 2.6

any thoughts? still need a exported View? is there another way to go about this?

#9

Please review my comment in #7. The randomized View makes form submission impossible through Drupal's Forms API, because it requires the form to be present on the page after submission. Since the View is random, this isn't always the case.

#10

+1 subscribe

edit: I accepted this workaround: http://www.ubercart.org/issue/12802/add_cart_button_doesnt_work_views_an...
But still, problem does exist, because this is just a temporary solution.

#11

+1 subscribing

#12

Version:6.x-2.0-rc3» 6.x-2.2
Status:closed (fixed)» active

#13

Status:active» closed (fixed)

Please read the comments in this thread. There is no bug here.

#14

Erm... buy now button doesn't allow the user to buy now - surely that's a bug

for example, couldn't the buy now button fire off a function which does actually buy now - kinda like cart links

Or perhaps the button could read "buy now unless this page happens to be random or cached"

#15

I used hook_views_query_alter() to make this work. See the attached file as an example.
My setup - drupal 6.19, views-6.x-2.11, ubercart-6.x-2.4.

AttachmentSizeStatusTest resultOperations
workaround.txt328 bytesIgnored: Check issue status.NoneNone

#16

The workaround works perfectly for me. I have spent a day on this bug and fortunately got your fix at the end.

For long term, this should go into the core of ubercart really.

#17

@dukem

Your workaround is awesome. Thank you. I had to make one small tweak to get it working for me:

<?php
function site_hacks_views_query_alter(&$view, &$query) {
  if(
$view->name == 'uc_products') {
    if (
$_POST != array() && strpos($_POST['form_id'], 'uc_catalog_buy_it_now_form') !== false) {
       
$tmp = explode('_', $_POST['form_id']);
       
$nid = $tmp[count($tmp)-1];
       
$query->add_where('0', "node.nid = %d", $nid);
    }
  }
}
?>

Had to change the form id value in the 3rd line was all.

#18

How/ where to apply this workaround [UC version 6.x-2.7]?

#19

designate: It should go in a custom module. In my case it was a module named site_hacks.module.

#20

Version:6.x-2.2» 7.x-3.x-dev
Status:closed (fixed)» active

Still present in D7 3.0... I think this should be fixed in core.

#21

Status:active» closed (fixed)

Implementing the hack basically bypasses essential access control. A user could theoretically POST data to the form that then adds a node to the Views result for a product they otherwise wouldn't be able to see. The problem isn't just that the product isn't in the View on the refresh, it's that the form isn't being processed because it's never being built. In other words - this POST is not trusted.

#22

http://drupal.org/project/views_random_seed might be an option where Global: Random fails.

#23

Thinking about it some more - it may be that Views could still alter the query to apply node access since it's using the Views query builder... maybe someone can confirm? (That said, we still can't trust the POST data, so we'd at least need to figure out a way to validate the form ID w/ the user and form token.)

#24

#22 provides perfect solution - in my case. Playing around with the custom reset seed to meet your personal needs. I do believe not to set this interval to short so customers have time to notice the block with random products and buy product directly thru buy now button. Thanks longwave for reply!