WooCommerce cart item deletion behaviour with Enfold

After some more testing it is definitely related to W3 Total Cache, not to Enfold. :-)

W3 Total Cache 0.9.7.2 seems to have some issues with WP 5.1.1:
– after a few times activate-deactivate-purge cache-reactivate W3TC freezes up, cannot be reactivated.
– after that it cannot be deinstalled, need to manually delete W3TC files through FTP, then reinstall
– leaves behind W3TC entries in htaccess at deinstall (browser cache and core W3TC)

So, even if it’s not Enfold related, I will leave the link active to the staging if you want to have a look.
It’s a staging and well backed up, so knock yourselves out if you want to do some testing yourselves :-)

Hi,

Saw on the W3TC forum that they are preparing a new version. So will wait for that first.
For now the behaviour with deleting items from the shop cart I described above is definitely there with W3TC active, tried all kind of W3TC settings changes but it still remains.

Perhaps you can shed some light on how the behaviour with deleting through the cross differs from deletings through the quantity in the cart.

Will try to check on the Woo forums as well and post here if I find something.

Kind regards,
Rob

Addition:
Just installed W3 Total Cache 0.9.7.3 (just released an hour or 2 ago) and tested.
With Enfold compression disabled and W3TC active: same “delete from cart” behaviour described above
With Enfold compression enabled and W3TC active: same “delete from cart” behaviour described above
With Enfold compression disabled: both methods of product deletion work fine
With Enfold compression enabled: both methods of product deletion work fine

I wish I could say that there’s maybe something wrong with my W3TC settings, but I do not think that is the case after lots of tweaking. EVERYTHING works very well with Enfold compression + W3TC active, it’s just that one stupid thing in the cart item deletion with the X that not behaving the way it should.

So still looking for the answer to this puzzle. Any help appreciated… thanks in advance!

2019-03-27, found this has probably nothing to do with W3TC…

Results testing with Enfold Compression enabled and W3TC enabled, deleting cart item with X:
works flawlessly ONLY in IE, needs page refresh in Opera, FireFox and Chrome.
did not test Edge as I refuse to use W10 :-)

So I guess this is back to you now, Enfold support

• This reply was modified 5 years, 9 months ago by rob2701. Reason: error corrected

Hi Mike,

Thanks for taking time to look at this. However…

Did you notice that this happens when W3TC is ACTIVE? At the moment it is deactivated, so that’s why the issue isn’t happening.
I did a lot of tests, so Enfold compression currently off, as well as W3TC. Feel free to activate.
Additonal info: cart is excluded from page cache. Cache is NOT disabled for logged in users (otherwise you would not be able to see (password protected site – staging).

So long story short:
W3TC deactivated > all fine
W3TC activated > problem with X as you and I described (except in IE). Mac died, so can’t check Safari.
Feel free to activate it (with or without Enfold compression active) and check (staging site, so knock yourself out).
;-)

BTW, I have also reported the issue at the W3TC forum, see what they can say about this.

Kind regards,
Rob

• This reply was modified 5 years, 8 months ago by rob2701. Reason: some additional info added

Hi Mike,

Sure the issue is there, I know that and you just confirmed what I already knew.
That’s why I was asking for insight into the difference between the two cart deletion methods. Like you can read above.

What I do definitely NOT appreciate is you disabling the password mode on this staging site. Why oh why would you touch that?
That is there to PREVENT access to the general public to the staging – still allowing external support like yours through the Temporary Login link for admins (DIFFERENT plugin!). This is a staging site, it is NOT supposed to be accessible from the outside (as there is also a LIVE site somewhere), and you messed that up by leaving the cached version active AFTER disabling the password protection. There was absolutely NO reason whatsoever for you to do that, because, as I explained above, the settings were already available for testing through pages being cached also for logged in users aka admins aka Enfold support. You just needed to hit “visit site” from the Dashboard.

I fixed it now, but this sort of thing does not really enforce my trust in Enfold support per se.
I know you guys have a lot on your plate, but properly reading and thinking about what you do on a site (even if staging) should be part of the package…

Kind regards,
Rob

• This reply was modified 5 years, 8 months ago by rob2701. Reason: added note about Temporary Login and Password Protect being 2 different plugins

Hi Mike,

Regarding the de-activated password protection:

No, I did not allude “that it was working differently for logged in users”. Quite the contrary. I stated above that the Cache was NOT disabled for logged in users, so that the frontend pages would be the same whether logged in or not. Please read accurately.

I know you de-activated the Password Protec plugin, then activated W3TC. Then visited the frontend. I also know that you re-activated the Password Protection afterwards. So far so good. But what happened when the unprotected pages were already cached? You forgot to purge the cache and/or de-activate W3TC. Exactly: the site was happily continuing to serve unprotected CACHED pages to everyone. The cache was doing what caches do. Simple logic, right?

Fact remains that there was absolutely NO good reason for you to even touch the Password Protect plugin. The Temporary Login plugin totally circumvents the password protection, and the Dashboard has Visit Site and Visit Store links.
There is no reason to log out to check the frontend either. So the whole thing was utterly avoidable.

When you opt for a nuclear option like this, at least retrace all of your steps or check with the customer beforehand!
I was lucky to discover this after about an hour. But what if I had not not been available for a week? I don’t think you realise that this could have created real practical damage for my client and for my reputation be able to protect my client’s data like I promised them. For that same reason, could you please delete the Dropbox video? Thanks.

In short: if I hand you guys the key to the garden door to be able to check on a problem with the dishwasher in the kitchen, you should not have to unlock the front door, much less leave the front door unlocked and wide open when you have left again through the garden door. Thanks for understanding the impact of this.

Regarding the issue with the cart:

Yes, we agree then that the issue only occurs when then W3 Total Cache is active.
That was never the question. This is not about attaching the blame for the issue to someone or to the theme, it is about finding the cause for the issue and solving it. The puzzle is finding out what is causing it. And why all browsers EXCEPT IE show the issue when the cache is active.

While I appreciate the time you spent on this, it still baffles me why you would need to repeat all steps of my testing just to confirm the exact symptoms I reported. Now we know that we can both properly test an issue. Good for us! :-)

I know perfectly well that Enfold is not Woo is not W3TC. So I was never asking anyone to debug the W3 Total Cache plugin, in fact I posted above that I had posted on their support forum as well.
What I was asking for was insight into the difference in WORKING of the X and Quantity cart item deletion…
Because it could very well be a difference in page refresh method (javascript call or inline or something else) which requires something to be excluded in W3TC. Could be Enfold, could be Woo, could be an exclusion needed in W3TC somewhere (before you ask, all Woo cart/checkout/shop pages are already excluded from the cache). And the baffling thing here to me is that in IE the issue does NOT occur WITH W3TC active.

Again, thanks for the time you spent on this. I do understand that being flooded with requests does things to the workings of logic. But reading helps.

May I suggest some general guidelines for your entire support team?

1.
Instead of diving in to repeat a test already done and already well-described and reported by the customer, please read the entire history of the post twice. Then try to understand what the customer is actually asking. And only then take action or respond.

2.
And if you do take action: please retrace all of your steps put the furniture back in the original position when you leave. Double-check.

3.
In case of a nuclear option like de-activating Password Protect: check with the customer first to get approval.

Kind regards,

Rob

Hi Mike,

Thanks for the reaction and time.

Any insight you guys can give me regarding the coding difference between deleting through the cross and deleting through the quantity in the cart?

Kind regards,
Rob

Hi Mike,

I see. I’m getting help from Marko at W3TC to get to the bottom of this. I’ll post here when we know more.

By the way, the same issue happens with the 2019 theme, so chances are slim that this has to do with Enfold.

With W3TC enabled the issue is ONLY with the X, when using quantity=0 it works fine, and with the “Empty Cart” plugin (which deletes all cart items at once) there is also no issue with W3TC active.

Right-clicking on the X to open in a new tab opens the Home page though, but then when you go to the shop it nicely shows “ITEMNAME deleted. Undo?” so without the need for a page refresh.

Could be a thing in the browser cache in W3TC, could be the way the page refresh is called with the X (Woo/Enfold?).
I saw that earlier in the forum there was an issue that could maybe point in the right direction:

Kind regards,
Rob

• This reply was modified 5 years, 8 months ago by rob2701. Reason: added info