Cart widget incompatible with super cache

We can look at this, however, I just want to point out that if your a developer, why not add it yourself? Contribute here: https://github.com/woothemes/woocommerce

Mike,

If I had the time I might. I’m a web/wordpress developer, but not a woocommerce developer. It might take me a substantial length of time to learn the API well enough to do this without breaking anything.

I played around with it tonight https://github.com/woothemes/woocommerce/compare/77c1218410…0c523d30b1

Mike,

Thanks for taking interest in this. I’ve only skimmed your revised code but I’m pretty sure your approach is not what I had in mind. In woocommerce-ajax-handler.php, you have the following:
require_once( $parse_uri[0] . 'wp-load.php' );
Essentially, you’re loading wordpress core. This isn’t much different from running super cache with Late init enabled. The point of a cache plugin is not to load the core and thus reduce server load.

I found an article discouraging this practice here: https://ottopress.com/2010/dont-include-wp-load-please/
I’m sure there are others.

I’ve also experimented some with the cart widget, so I realize that $_SESSION[‘cart’] unfortunately doesn’t contain all the data needed by the cart widget. Mainly, it lacks a WC_Product or WC_Product_Variation object for each product in the cart. So to do this the right way, in my opinion, your widget needs to be refactored so that this data can be retrieved without loading WP core. Maybe you can json_encode the product object and save it in the session variable — I’m just brainstorming here, have no idea if the json_encode idea is practical.

Ignore that part of the commit; it was an experimental (faster) version of admin-ajax.php

The important part is that the cart is loaded via ajax, with the post method. This *should* bypass caching but we’ll look at it further.

We cannot just access the SESSION data – in WC 2.0 we actually store sessions in the DB for greater compatibility.

You’ve certainly reinforced my point that I’m not a Woocommerce developer. ??

Again, skimming the code, I had the impression you only saved sessions in DB for logged in users.

I agree, if cart is loaded by ajax, it bypasses caching. But I have 2 concerns. One is cache compatibility, the other is performance, and it’s a clear negative performance impact if the php that’s invoked by the ajax post will require/include wp-load.php. Supposing you did this on a page that isn’t cached in the first place–you would be including wp-load.php twice–once to display the page, then once more to load the cart.

That is true, but realistically to avoid caching that is the only option. We need WP Core to grab the cart data, and we need the second request to load via AJAX.

The ajax request, using admin-ajax or a custom handler, will be lighter that a full page-load because it die()’s after returning it’s data.

I’ll talk to Coen in the morning about alternative ideas.

That’s too bad. That’s why I think refactoring is needed. If you implement it this way, I’ll have to substitute my own cart that doesn’t have all that overhead. The way you’re designing it won’t satisfy anyone in my opinion, and it increases load time for users that don’t cache their pages, which seems unwise to me. While it’s true that the impact is not as bad as reloading the page, it does reload all plugins, or am I missing something?

I don’t know how much you follow online discussions about WordPress & plugins, but there’s a vocal faction that criticizes WP plugins for consuming CPU resource. I’m currently testing Woocommerce on a site. With just one product defined, according to P3 (Plugin Performance Profiler), Woocommerce uses 50% of the CPU resources. With the vast majority of WP sites installed in shared hosting servers, CPU usage is critical. That’s a primary reason for the popularity of cache plugins, not just to enhance speed, but to reduce CPU usage so accounts don’t get suspended for excessive resource use. So whatever you do, it should at least do no harm, but loading wp-load.php an additional time for each page could be harmful in some cases.

Ok – any further discussion on the matter should go to github. This morning I made it work with a mix of ajax and local storage. Ajax requests are only used when needed, local storage stores the cart ‘fragments’ as a kind of cache to save on requests. So far so good.

I wish I’d thought of that. Just a couple of observations. Maybe use sessionStorage instead of localStorage? In case someone’s using a public computer, for example. Seems to me you on page load you can check if local storage has cart; if not, make ajax calll, then simply put the cart html in local storage, rather than storing fragments & recreating the cart piece by piece. After that, use local storage to generate the cart, then update the cart when cart quantity changes — I assume add to cart & change quantity already use ajax, so you only need to add code that updates the local storage.

It’s fine by me if you move the discussion to github, assuming I can find it. ??

As an update, we did this and used your session storage suggestion – all works great ?? Bring on 2.0!

Mike,

That’s terrific. Can’t wait to try it out. Thanks

Let us know how it went ?? And feel free to update your review to reflect it (assuming it works better of course :p)

is there a difference with these updates using W3 Total or Super?