Digital experiences for all disciplines
New Landing › How can we help? › Themeforest Theme Support › Dante › Caching plugin and DANTE
New Landing › How can we help? › Themeforest Theme Support › Dante › Caching plugin and DANTE
- This topic has 47 replies, 6 voices, and was last updated 8 years by David Martin – Support.
-
Posted in: Dante
-
February 20, 2016 at 1:18 am #250848
Hi David,
I hired a woocommerce programmer to look into the bug. He pointed me to my theme developer for some checks. Could you please help me with this since I have no clue how else to solve this issue. This was the result of his investigation:
Hello,
The broken code was due to the minification, that’s something I could determine for sure. When the page ecnounters broken JavaScript, any other script after that cannot run. This, amongst other effects, prevented the script that updates the mini-cart from running properly, therefore you would see the wrong total (the cart page was not affected).In relation to the issue, I’m getting confused, as the results are mixed. I reverse engineered the code of your theme, and now have an idea of why you might see the mini-cart with the wrong content (it doesn’t always happen, though). The cause seems to be a mix of caching and theme architecture.
This is what I found by repeating the tests multiple times:
You open a page. The cart is rendered as empty.
You add an item to the cart.
The page is reloaded.
When the page is rendered, its content is taken from the cache. In the cache, the mini-cart was stored as “empty”, and it appears as such.
To cover this kind of issue, WooCommerce uses an Ajax call to retrieve the content of the mini-cart and update it on the fly. The call always returns the correct mini-cart content (you can see this easily by checking the Network calls in browser’s developer tools).The result would be that, even if the page is rendered with the cart widget as “empty”, the Ajax call, which is never cached, replaces its content after the page is loaded, showing the correct cart data. The issue, in your case, is that your theme uses its own, custom mini-cart (see function sf_get_cart() in your theme’s functions.php), that doesn’t hook into the Ajax call, therefore the content that comes from the cached page remains unchanged.
Next steps
I double checked the configuration of WP Rocket, it’s now ready to be used with WooCommerce. I disabled the plugin so that the site can work normally during the weekend. You should not have to change any settings when you will enable WP Rocket again.
I would recommend to contact the theme author and ask to perform the tests I described above with the cache enabled.
The objective is to have the mini-cart at the top right of the page updated dynamically, using Ajax, in order to bypass the cached page content. Make sure that you specify that you are talking about the mini-cart widget, not the cart page (the cart page is not cached and always shows the correct content).
February 22, 2016 at 2:55 pm #251206Hi,
The Ajax call comes from the function
sf_woo_header_add_to_cart_fragment()
: Ref: https://docs.woothemes.com/document/show-cart-contents-total/Has the developer seen that function?
Thanks
February 22, 2016 at 5:37 pm #251269Thanks, I will tell him right away
February 22, 2016 at 5:39 pm #251270Ok – let us know.
Thanks.
February 22, 2016 at 5:39 pm #251271No problem
February 22, 2016 at 6:43 pm #251283Hi David,
This is what my programmer answered to your reply. Looking forward to your reply.
Kind regards!
—The only Ajax call that is triggered is the standard one used by WooCommerce, which calls https://freshfolds.nl/?wc-ajax=get_refreshed_fragments. The JavaScript code attached to that call alters the mini-cart widget as long as said widget has some specific CSS classes. Your theme uses different classes and a different structure, therefore the Ajax call runs, but then its result is discarded.
In other words, there is an Ajax call that should update the mini-cart, but, since said mini-cart uses a different identifier, no update is performed.February 24, 2016 at 12:27 pm #251750@Gizan86 – I’ll need to get our lead developer to take a look at this also. Thanks for your patience.
Thanks.
February 24, 2016 at 5:03 pm #251812Hi David,
Thank you for including him. I will wait for his reply.
(Don’t know if it helps but in the meantime my developer has tested the issue with the woocommerce storefront theme and there the cart issue disappeared. If you need more info from me or my developer, please let me know.)Kind regards!
February 26, 2016 at 3:42 pm #252252Apologies for the delay – we are looking into this for you.
– Ed
February 26, 2016 at 4:01 pm #252259Thank you Ed, I will wait for your findings..
February 27, 2016 at 12:04 am #252345Given that you don’t want the plugin active on your site for the issue to be present, could you please send over the wp-rocket zip so that I can check it out locally and get compatibility with that resolved? I’ll look at W3TC in the meantime.
Thanks,
– Ed
February 27, 2016 at 12:09 am #252349Hi,
I checked the test site and activated the Dante theme again and it showed me the same cart total has it was showing in Storefront theme.
After that I cleared the cache and started a new test by adding a product and went to the cart page and updated the quantity. Then went to the homepage and the cart header total was correct.
Can you also do the same test?
The plugin that is active is W3Total cache(didn’t changed anything)-Rui
February 27, 2016 at 12:58 am #252355Thanks for the help:
@Ed: I included the zip file of wp-rocket in the attachment.
@Rui: I tested the test site but I found still the same problem. After I added a product to the cart and shifted pages, the cart in the header showed false amounts.
Looking forward to your results.
Kind regardsAttachments:
You must be logged in to view attached files.February 27, 2016 at 8:37 pm #252427Thanks for the zip. Unfortunately can’t be used without a subscription so I’ve gone with W3TC instead. Have set up a test installation with all caching enabled, and have been unable to replicate the issue. I am logged in when testing – does this have an effect on the issue being present? Is it only on variable products, or all products?
Just to clarify:
1) Add item to cart.
2) Page reloads and correct cart is shown.
3) Navigate to another page, and the same cart total is shown.
4) Navigate to the cart, and correct total is still shown.I have a video showing the process and viewing the source to confirm that the caching is definitely working. Currently I am away and on sub-par internet so it’s a little slow. I’ve double checked our code for the cart and it’s definitely to WooCommerce’s guidelines. If there is something your WooCommerce guy has that is clear where or what we are doing in the wrong then I’ll happily double check this.
– Ed
February 27, 2016 at 9:59 pm #252438Hi Ed,
Lucy from wp-rocket has created a video about the problem.
https://infinit. io/_/3a7AUQ9 (remove space before io)
Just to be clear please follow steps underneath to replicate the issue to see what I mean.
I think since you have problems replicating the issue maybe its best to do this on my live site. Here you can also test it with wp-rocket (or any other caching plugin Ihave installed). It is far from ideal but I think its the only way to really test it and to solve it. Can you please deactivate any caching plugin that you use after testing?1. activate wp-rocket
2. Visit product page: https://freshfolds.nl/service/wasserette/was-service/
3. Add a product to cart (fill in pickup day and time first): You will see the blue cart notification is acting strange and the cart in the header shows false results
4. Switch to a different page for example: https://freshfolds.nl/contact. You will see the cart is acting strangeTo answer your question, the issue is with every productpage (simple or variable) and is there wheter the user is logged in or not.
Kind regards -
Posted in: Dante
You must be logged in and have valid license to reply to this topic.