Hello,
I tested this module with a vanilla drupal commerce installation.
Adding a product works correctly, it's added to the cart (but a confirmation message would be a great plus).
But the top cart doesn't work, I can't rollover the cart to display the product list like the kickstart installation.
Regards,
Alex
edit:
This version of the module didn't work out of the box with a cart that wasn't provided by Commerce Kickstart. #8 provided the code of said cart to import into a vanilla Commerce installation.
What my patch does is fix the ability to switch views in the backend, which was introduced in #12, I wrote a small summary in #21.
| Comment | File | Size | Author |
|---|---|---|---|
| #53 | 2147697-53-cart-views-refactor.patch | 6.18 KB | sin |
| #48 | 2147697-48-cart-views-refactor.patch | 5.03 KB | joelpittet |
| #46 | interdiff.txt | 12.98 KB | joelpittet |
| #46 | commerce_ajax_cart-stockcart-2147697-46.patch | 10.02 KB | joelpittet |
| #40 | commerce_ajax_cart-stockcart-2147697-40.patch | 11.4 KB | ppelgrims |
Comments
Comment #1
erik seifert commentedIt is a clean install ? Do you have an url to check?
For confirmation message please check
https://drupal.org/project/commerce_add_to_cart_confirmation
Works out of the box with this module.
Comment #2
erik seifert commentedPlease give me a hint. What is vanilla drupal ?
Comment #3
erik seifert commentedComment #4
zmove commentedHello,
Vanilla Drupal means non-kickstart installation of Drupal Commerce.
I believe commerce kickstart create a special view to display the cart in the top of the page, view that doesn't exists in Drupal commerce without kickstart. In addition, if I remember well, kickstart alter some functions to display the cart as it is, by adding some classes, removing some divs etc...
That module probably use the kickstart view classes a reference to make the ajax magic works. If you don't have the same class, it doesn't work.
That's why I say it doesn't work with Vanilla commerce.
Comment #5
zmove commentedCan somebody make an export of the top cart view created in kickstart ? I could try importing it in my vanilla drupal commerce so see if it works.
Thank you
Comment #6
erik seifert commentedThis would be an idea. Make an submodule to cover this issue.
Comment #7
zmove commentedOr another suggestion, make the ajax cart module create a view that is compatible with it. It's possible for a module to provide default view, so you could add an "Ajax cart" view block to be sure it will work.
Comment #8
marameodesignI can confirm that importing the following view into a Vanilla Commerce installation works.
Comment #9
erik seifert commentedMake an small module for import this view ?
How it's your oppinion
Comment #10
erik seifert commentedUpdate to version Beta 2
Comment #11
brobert7 commentedFYI, I'm running a vanilla D7 install as well, using the 7.x-1.0-beta2 version of this module (fresh install), and the ajax cart did not work for me out of the box.
I imported the view posted by marameodesign in post #8 and it worked right away.
thanks @marameodesign. Thanks Erik for the module too, good stuff.
Comment #12
erik seifert commentedNew dev Version add default view copied from commerce kick start. Also add a ability to switch view in configuration.
Comment #13
erik seifert commentedComment #14
zmove commentedI tested with the provided view in the dev version and it doesn't work with garland.
When I install the module and add a product to the cart, I can see the status message, but the cart block on the top of the page is not dynamically updated and I have to refresh the page to see the product added.
So the product is correctly added to the cart, but the ajax to update the cart doesn't work. I will try to find what is the problem.
Another small thing, I can see that the status message is prepent do #block-system-main. Personally, I try to fight against too much div that drupal provide by default and this div #block-system-main is one of the div I remove systematically on my theme. I think the code that update the status message should be more flexible and not depend on a div that a user can (and have good reasons to do) remove, or, at least, add an option to the module when we can put the ID class of the div.
Comment #15
zmove commentedFound the problem.
The default provided view id is "shopping_cart_cac" and have a the class : "view-id-shopping_cart_cac" whereas in your commerce_ajax_cart.js file, you have hardcoded call of jQuery('.view-id-shopping_cart').
So you should dynamically find the class of the view depending on the view you chose on the configuration page of the module and it should work. (Or maybe provide a default .tpl.php file for that view, provided with the module, that give an unique ID to the view to be sure you can identify it).
Comment #16
roball commentedI would like to test this on a stock ("Vanilla") Drupal installation. I have never used Commerce Kickstart so far but instead installed all required modules from scratch. There is another module called Commerce Cart Ajax but that does not work either (see for example #1837356: Cart Block View doesn't refresh) and nobody cares about.
Comment #17
erik seifert commentedUpdate
Comment #18
roball commentedI think this issue is now a Feature request that Needs work.
Comment #19
zmove commentedI don't think it can be considered as a feature to have a drupal commerce related module working with.... drupal commerce. But as you want ^^
Comment #20
roball commentedI'm not the author of this module and even did not try it yet, just thought Support request isn't adequate for an ongoing work announced by the author. Changed the status once again - is it correct now?
Comment #21
ppelgrims commentedI have a feeling the latest release was prematurely. Even when taking into account this module mostly works with Commerce Kickstart. This will embed the Kickstart cart block:
Presumably this should be used more extensively, as it is the choice the user made on the admin page:
I reckon JS wont work unless the form id of the view gets passed on to the JS through the drupal_add_js function in commerce_ajax_cart_preprocess_html on line #78 of commerce_ajax_cart.module as suggested by #15.
Thoughts?
Comment #22
ppelgrims commentedI threw this together, it works for me but I did it quick and dirty. Could somebody test this and possibly make a patch out of it?
commerce_ajax_cart.js
commerce_ajax_cart.module
commerce_ajax_cart.admin.inc
Comment #23
ppelgrims commentedI guess I'll update this.
Comment #24
ppelgrims commentedIt doesn't work for an empty cart
I added this on line #7:
jQuery('.cart-empty-block').replaceWith(data) ;I'm sure it can be made fancier.
Comment #25
Christopher Riley commentedIs there anyone working on getting the module to work with a non kickstart installation?
Comment #26
roball commented#ppelgrims: I think if you would provide your suggested changes as a patch, people would be able to easily test them.
Thanks.
Comment #27
ppelgrims commented@roball I have zero experience making patches, but I'll try to look into it this week.
Comment #28
roball commented@ppelgrims: see https://drupal.org/patch
Comment #29
ppelgrims commentedI hope this works.
Comment #30
ppelgrims commentedComment #32
joelpittet@ppelgrims thanks for the patch.
When you make the patch you should have it relative to this module. You can do that in your project by using
git diff --relative .gtv3 looks like it snuck into the changes which looks like a custom module you've created and the patch is relative to the drupal root and not the module's root so that's why that got picked up too. Those 2 things are why the patch is failing.I've bumped the version to dev because the patch should be against the latest dev. This is so that testbot knows which version of the module you are patching against and I'm assuming you are trying to patch the latest to get it committed and the maintainer will apply the patch then roll that into beta4 with any luck.
Have a quick view of the coding standards https://drupal.org/coding-standards.
It looks like you are using tabs instead of 2 spaces.
Good first try though! It's a patch, it's a valid and the naming convention is spot on:)
Hope that helps, give'r another roll:)
Comment #33
ppelgrims commentedThanks for being so kind and clearing that out Joel! Using the --relative parameter got rid of the other module as well.
Comment #34
ppelgrims commentedComment #36
ppelgrims commentedConverted tabs to spaces, line endings are still Unix.
Comment #37
ppelgrims commentedComment #39
joelpittetIt's saying it doesn't apply. Which means it may not be made against. 1.x-dev
I tried the patch against
7.x-1.x(dev/master) and7.x-1.0-beta3and it doesn't seem to apply. What version do you have locally that you are patching against?To get dev/master or all the branches you can clone it down:
But the way you are doing it should also work with
drush dl commerce_ajax_cart --devThough sometimes they are out of sync that usually does the trick when you use --relative in your project. Cloning like above can make a mess of your project's git repo (because it would need to become a git submodule), but you could do it temporarily:)
Anyways that patch is looking much better. There is some 3 spaces in a couple places where there should be just 2, but I'll let that slide till it goes green:)
Comment #40
ppelgrims commentedI started over following this. Fingers crossed!
Comment #41
joelpittetAwesome @ppelgrims just tried it out and it seems to work great. There are some coding standards things to fix before it can be marked at RTBC and it would be nice to have someone else give this a try too!
@ppelgrims, do you mind updating the issue summary and title to to reflect what that code does because the original title and IS are not clear? And if it's cool with you I'll give you another nit picky code review to help get things up to snuff?
If you are using sublime text to edit code there is a nice little settings here that will do half the nitpicky things I'd ask you to do anyway. https://drupal.org/node/1346890 The sidebar has settings/configs for other IDE/editors too. That way the code reviews are are easier to see the forest for the trees ;)
Erik looks busy at the moment but if we give him no reason to hold this back I'm sure he'll commit it. Or I'll put my name on this help wanted list and I will:) @see #2258475: Help / Co Maintainer wanted
Comment #42
joelpittetWas playing around with this also and realized that there was something wrong still even though this fixed a good chunk(seems like the fix comes from the form_id stuff in the patch. There is a discrepancy in which view is being updated for the add to cart button and hovered over. And which view is to show up through ajax on hover.
These changes make the block that is being added via the popup window use the same block that is being displayed/updated etc.
Comment #43
ppelgrims commentedI have the JS for that commented out as I don't need the hover. It would make more sense to have an option to switch off the feature now that I think about it. I'm not sure what's wrong or needs to happen?
This version of the module didn't work out of the box with a cart that wasn't provided by Commerce Kickstart. #8 provided the code of said cart to import into a vanilla Commerce installation.
What my patch does is fix the ability to switch views in the backend, which was introduced in #12, I wrote a small summary in #21.
Re: coding standards, I thought cleaning up code should be a different commit?
Comment #44
joelpittet@ppelgrims, you are right about code cleanup being a different commit BUT not on your changes. You shouldn't introduce new coding standard issues to the pile of them.
Can you add that message to the issue summary?
I've got a patch that helps get the hover working too. Mind if I post with an interdiff against #40? I'll include the coding standards changes too.
Comment #45
ppelgrims commentedDo it! :)
Comment #46
joelpittetIt's hard for me not to fix the coding standards issues too:( Hopefully the interdiff isn't too useless...
Comment #47
joelpittetThe big difference is that there is a view that comes with this module which seems to be the top view in this project page's screenshot form kickstart.
It's the one that gets auto updated via the
commerce_ajax_cart_update_block(). So instead of using the same block for both, I opted for now to just use the shopping_cart_cac Views block that comes with the module as the main block that get's updated. And the one that you choose through the UI I left with the nice code you wrote to hook up the views + display options in #40. Also note thatshopping_cart' view doesn't exist, so that could be why things didn't work so well before...That should be more clear than that crappy interdiff I did there... I need to stop cleaning doc standards in patches:(
How does that sit with you @ppelgrims?
Comment #48
joelpittet@ppelgrims I'm co-maintaining this project now. I've cleaned up the majority of the coding standards on the dev branch. So now this set of changes should be much clearer to review.
Please read through, and give it a go and we can continue from there.
I hope I didn't miss anything from your patch. Though I do want to try to keep the scope of this change as succinct as possible.
Comment #49
joelpittetJust to summarize what this does:
This should get it work with Drupal Commerce and continue to work with Commerce Kickstart.
We should likely see if we can provide a feature in another issue to allow the updated view block (shopping_cart_cac) be an option to change, though I'd consider that to be followup territory, along with confirmation message thing that mentioned in the issue summary.
Comment #50
rgnyldz commentedI get
Uncaught TypeError: undefined is not a functionreferring to commerce_ajax_cart.js line 50. My version is 7.x-1.0-beta3+3-devComment #51
joelpittet@RgnYLDZ is that with this patch applied or should you've opened a new issue for that bug report?
Comment #52
rgnyldz commentedI got this working on an old project (via #8). so in this project I directly installed and applyed the patch, no luck. I'll do another project with commerce in the near future. I'll get back with more details. I really have a deadline.
And thank you for improving this module.
Comment #53
sin commentedHello, guys! Thank you for working on this :)
I tested patch #48 on a project based on a raw Drupal Commerce. The default add to cart block view was already altered and themed. I've found a problem using a module with a patch due to hardcoded usage of view shopping_cart_cac which this module provides.
joelpittet, I've seen your comment about this is planned to be fixed in separate issue. Let me just leave the patch here for future reference. It is based on #48, rerolled against head and containing some additional code to fully support view change setting.
I found that commerce_add_to_cart_confirmation module works nice in pair with this module for confirmation message.
I also need to disable cart details on hover, so an option would be nice.
Comment #54
nithinkolekar commentedUntil this get fixed , it would be nice to mention on module page that it is currently working with commerce kickstart only and linking this issue.
Comment #55
discipolo commentedi got this working using non kickstart install using the current dev version of this module with the patches
projects[commerce_ajax_cart][patch][] = https://www.drupal.org/files/issues/default_values-2292641-1.patch
projects[commerce_ajax_cart][patch][] = https://www.drupal.org/files/issues/causes_jquery_errors-2280465-6.patch
projects[commerce_ajax_cart][patch][] = https://www.drupal.org/files/issues/2147697-53-cart-views-refactor.patch
then setting the correct block in the config form and boom!
Comment #56
joelpittetSorry for the late reply:( I've committed the patches mentioned in #55 to dev. So it's just this one.
@sin regarding #53 that looks pretty nice. An interdiff goes a long way to see what has changed. That feature request is actually something I was looking for too and I was thinking that should be a new block... the reason being so we don't do extra work rendering a view that is never displayed. Could you open a new feature request?
I've committed #53 with the indexes changed to an assosiative array to make it easier to tell what it's doing.
Comment #58
roball commentedThank you joelpittet for the commit. I think this deserves a new beta release.
Comment #59
joelpittet@roball I'll give it a week or two but yeah I agree. If people find it's working as it should we'll look at a new release.
Comment #60
sin commentedThank you joelpittet for your work!
I'll try to test current dev till the end of the year :)
Added a feature request #2398319: An option to disable cart details on hover.
Comment #62
roball commentedWhat about pushing out the new beta soon (meanwhile, 2 months have passed since this issue has been fixed)?
Comment #63
sin commentedSorry for the delay, I've tested current dev with our custom Commerce Distribution based on current Drupal Commerce release 1.11. The module works great with default settings! :)
Comment #64
sin commentedJust tested with custom cart block view, works as expected.