Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#15 | workaround.txt | 328 bytes | dukem |
#6 | random-oferta-block-with-failing-add-to-cart.txt | 31.01 KB | ñull |
Comments
Comment #1
DigitalFrontiersMediaNot sure what you mean by "changed page". Can you detail this a bit more. And maybe export your View and post it here?
Comment #2
rszrama CreditAttribution: rszrama commentedHmm... 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.
Comment #3
jptaranto CreditAttribution: jptaranto commentedSo basically add to cart will not work when using a random view?
Comment #4
rszrama CreditAttribution: rszrama commentedCorrect, at least without some custom module ensuring that the form you're submitting will always be present on the regenerated page.
Comment #6
ñull CreditAttribution: ñull commentedI 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:
Attached the exported view. The "ofertas" block begins at line 980. Hope someone can fix this!
Comment #7
rszrama CreditAttribution: rszrama commentedSame 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.
Comment #8
strawman CreditAttribution: strawman commenteddid 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?
Comment #9
rszrama CreditAttribution: rszrama commentedPlease 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.
Comment #10
jazzitup CreditAttribution: jazzitup commented+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.
Comment #11
anrikun CreditAttribution: anrikun commented+1 subscribing
Comment #12
anrikun CreditAttribution: anrikun commentedComment #13
TR CreditAttribution: TR commentedPlease read the comments in this thread. There is no bug here.
Comment #14
sphism CreditAttribution: sphism commentedErm... 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"
Comment #15
dukem CreditAttribution: dukem commentedI 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.
Comment #16
tm01xx CreditAttribution: tm01xx commentedThe 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.
Comment #17
jnettik@dukem
Your workaround is awesome. Thank you. I had to make one small tweak to get it working for me:
Had to change the form id value in the 3rd line was all.
Comment #18
designate CreditAttribution: designate commentedHow/ where to apply this workaround [UC version 6.x-2.7]?
Comment #19
jnettikdesignate: It should go in a custom module. In my case it was a module named site_hacks.module.
Comment #20
SilviuChingaru CreditAttribution: SilviuChingaru commentedStill present in D7 3.0... I think this should be fixed in core.
Comment #21
rszrama CreditAttribution: rszrama commentedImplementing 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.
Comment #22
longwavehttp://drupal.org/project/views_random_seed might be an option where Global: Random fails.
Comment #23
rszrama CreditAttribution: rszrama commentedThinking 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.)
Comment #24
designate CreditAttribution: designate commented#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!
Comment #25
hockey2112 CreditAttribution: hockey2112 commented#22 works for me, to an extent. When the seed is set very small (1 second, 5 seconds, etc), the add to cart button often fails. I recommend making the seed duration at least a minute or two (in line with Designate's advice in #24), although users who load the block at 1:59 of the 2:00 minutes will likely have "add to cart" issues.
Comment #26
longwaveIt might be helpful if we added a hook_views_analyze to detect the combination of Add to Cart fields and Global: Random, and suggest switching to views_random_seed instead.
Comment #27
hockey2112 CreditAttribution: hockey2112 commentedI ran into this issue again, 3 years later, with the sort "Global: Random" setting. Has anyone come across a solution better than Views Random Seed?
Comment #28
rszrama CreditAttribution: rszrama at Centarro commentedNo, there's no better option. It's just a limitation of the way the Forms API works.
Comment #29
ncswi CreditAttribution: ncswi commentedI can reproduce this problem and I can fix this problem.
It's in the Views caching. If you set the views cache to time-based (custom) and adjust it to 5 seconds, then this makes the add to cart work (assuming the process to add a product to the cart takes 5 seconds.
Once the views cache is cleared, you can add another product to the cart.
While this is not optimal as it causes longer page loads on the catalog pages, it does solve the problem until a better solutions can be implemented. D7