I’m seeing a problem where the cart in the header randomly resets to £0.00 and 0 items.
If I view the off-canvas cart, I can see the items. When I close it, the header still says 0.00 and 0
If I then go to another page, it displays correctly. For a while. But then goes again.
If, when it has gone to £0.00 and 0, I add an item, when I close the off-canvas cart and it returns to the page I was on, it also displays correctly. For a while. But then goes again.
I am not closing the tab or the browser.
This is happening using responsive theme as well as my own based on it, in development mode, with no logged in user.
Opcache is enabled but regardless, it shouldn’t cause this issue surely?
Does anyone have any ideas please?
Using 5.51 but think it was happening before that.
[EDITED - FALSE SOLUTION - Problem still happening but leavnig this post here anyway, but please see post below]
I think I have solved this. Can’t be 100% sure yet but …
I’ve been moving around the site until it happens, and when it does there are a few error messages in the dev panel of Chrome about slow network (impossible - I have a 300/300Mps fibre connection and a very good server with a great host) and failed to load some Google fonts which presumably caused some other scripts to load (hence the lack of the ajax cart?)
But… what it appeared to be was a badly configured default installation of Apache under Plesk.
Having changed some settings in apache, it now loads the site much faster (still slow compared to a live site, but much faster than it was). If this stops the ‘slow network’ errors, which it should, then I suspect I won’t see this problem again. Fingers crossed.
I’ve also removed any last remaining ioncube files including the licence manager and upgraded to php 7.2 with opcache on.
I closed my laptop with various tabs open, as you do, including the site.
When I opened it this morning the visible tab was my email.
I clicked on to the tab for the shop, and it was back to £0.00 and 0 in the header cart. There were no errors in the console. I’m sure when I last looked at the page before going to sleep it was showing the correct numbers, otherwise I would have noticed!
Opening the off-canvas cart, and then going to another page caused it to come back.
So although what I did last night has sped the server up, it wasn’t the cause of the problems.
If anyone has any ideas I’d be very very grateful. Thanks.
Do u use a custom theme, or are you using the default responsive theme without any modifications?
It happens with both my custom theme (based on Responsive) and Responsive itself. I checked the Reponsive and Bare frontend theme directories against the 5.51 commit and they are indentical.
In terms of plugins, there are very few installed. And only two that affect the frontend in anyway. I won’t name them at the moment because it may not have anything to do with it, but I disabled one about 45 minutes ago and so far I’ve not seen the problem. I need to give it a bit more time though.
Do u use a custom theme, or are you using the default responsive theme without any modifications?
It happens with both my custom theme (based on Responsive) and Responsive itself. I checked the Reponsive and Bare frontend theme directories against the 5.51 commit and they are indentical.
In terms of plugins, there are very few installed. And only two that affect the frontend in anyway. I won’t name them at the moment because it may not have anything to do with it, but I disabled one about 45 minutes ago and so far I’ve not seen the problem. I need to give it a bit more time though.
I’ll update as I know more. Thanks.
No, it’s still happening in Responsive with the first one removed. That’s part of the problem. I can’t find out exactly how it happens - ie, if it was always after 20 mins of inactivity etc, it would be easy to test.
I’m now removing the only other one that affects the layout (well, except for FOS Profiler - that does too of course, but I’ll leave that to the last).
I’ve done a diff between the 5.5.1 commit and my codebase and the code matches in /bin/, /engine/, /themes/ (Bare and Responsive)
I’ve removed all plugins except for the following Shopware AG ones (name / version number)
Advanced Menu (Erweitertes Menu) – 1
PayPal – 1.0.7
Shopping World Presets – 1.0.1
Google Services – 3.0.0
Shopware Import/Export – 2.6.2
Shopware Auto Update – 1.0.0
Statistics – 1
InputFilter – 1
All the rest were de-activated and uninstalled (clearing the cache and rebuilding the theme each time it suggested it). I have 16 uninstalled plugins but presumably they cannot affect it.
I’ve cleared the cache in the backend and also using clear_cache.sh and rebuilt the theme.
If I manually load the controller https://mysite/checkout/ajaxCart in another tab and reload the shopware page, the correct values come in to the header cart
The code to get the cart numbers seems to be in function cartRefresh - line 189 of jquery.shopware-responsive.js. The only subscriptions to this are on onAddArticle and onRemoveArticleFinished.
There are no errors in the developer console in Chrome.
There are no errors in core_dev-2018-10-02.log except for deprecated warnings.
There are no errors in my php error log file.
There are no errors in my mysql log
While I’ve been writing this, I had a tab open with the correct values in the cart. I’ve just closed the tab, and opened it again in another tab, and the values have gone back to 0.00 / 0. Opening the off-canvas cart – which shows the products - and closing it again, and then refreshing the page shows the right values again.
I am sure this bit is happening but it seems too odd so I am trying to prove it to myself 100% and it’s a matter of time/patience.
But I think sometimes the value can reset to 0.00 / 0 without me even leaving the page (I may go to another tab of course, but I don’t reload the page or move to another part of the site). I’m not sure if this is possible as the only subscriptions I can find for cartRefresh are mentioned above. I’ve set a breakpoint on that function and will wait to see if it gets called randomly. It tends to seem to happen if I leave the page unused for a while, which is why I am struggling to be 100% certain it is happening as I keep forgetting to make a note that the page was 100% right in the first place I’m testing that now though.
I think that’s all for now. I actually wrote this all once and then lost it in a crash so had to retype it and remember it all. Hopefully I’ve not forgotten anything important.
If anyone has any ideas on how I can solve this – or tips on how to solve it myself that I haven’t already tried, please let me know!
It’s gone back to 0.00 and 0, so I checked the session cookie again and Chrome now says it was created Monday, June 4, 2018 at 4:45:54 PM
DB says modified 1538557528 and expires 1538558968
Opening the off-canvas cart and refreshing puts the total and quantity back and Chrome now says it was created Wednesday, October 3, 2018 at 11:14:00 AM and the DB says modified 1538558041 and expires 1538559481 - the session id is the same.
All pages are being served on the same URL but clearly something is going wrong with the cookies. I’ll clear them all for the site.
The odd thing is I’ve had this on 2 computers and 3 browsers (Chrome on both, Safari on one).
Hopefully this will fix it. But I’d be interested to know how it could be doing this?
The standard session time of php is 30 minutes, the cookie will mostly last longer and recreate the session when opening the page again. So this is potentially caused by a timed out session. You can increase the session timeout on your server via php.ini (ask your provider).
The standard session time of php is 30 minutes, the cookie will mostly last longer and recreate the session when opening the page again. So this is potentially caused by a timed out session. You can increase the session timeout on your server via php.ini (ask your provider).
Yes, thanks, that does make sense. I can change the settings myself.
I knew it would be something stupidly simply.
I’ll test it now, and hopefully that will be it.
But it still doesn’t explain why when the session is recreated (and I have the same sesion id each time), the cart initially shows £0.00 / 0 until I open the cart or add something to it. That would suggest a bug in shopware wouldn’t it?
(Again) So far so good.Thanks for your help Moritz. As you can tell, I’ve sent a lot of time on this!
Increasing the session lifetime seems to have worked.
I still don’t see why it was causing the £0.00 / 0 though? When it recreated the session it gave it the same ID and the products where still there but weren’t displayed until a cart action was made.
Shopware will calculate the cart only when accessing the cart (add product to cart, open the cart, …), not on site visit, because of performance reasons. So when the session ends, the cart isn’t stored in the session any more, but in the database. Accessing the cart adds the cart backt to the session.
Shopware will calculate the cart only when accessing the cart (add product to cart, open the cart, …), not on site visit, because of performance reasons. So when the session ends, the cart isn’t stored in the session any more, but in the database. Accessing the cart adds the cart backt to the session.
Ok, but when a session is re-created, surely it can be regenerated then? It’s a one-off expense vs the customer wondering why their basket is empty. They could either leave, thinking they have lost everything they put in, or put in the same thing again and not realise (people do sometimes order like that).
Do you not think it is worth changing this?
And thanks again for helping me find the solution, I’m not having a go at you here, I just think it’s something that should be fixed.
I’m testing that now though.
so had to retype it and remember it all. Hopefully I’ve not forgotten anything important.