bug in cache and Panda

[rubben1985]

Hi,

The problem is that cache is not working correctly with panda template modules anymore (maybe also with other modules but I noticed it panda ones).

It happens with bleeding edge 1.1.x (the version from a few weeks ago).

When I active the cache in the performance section, the modules showing info in the front office, show old cached versions. Clearing cache doesnt change this. 🤷‍♂️

In practice, when cache is activated, it doesn´t matter what I modify, changes will not be reflected in the web. Only if i deactivate cache the changes are visible.

I contacted @Jonny because I thought it was only related to one module (st easy content). It seems to be related to TB multistore. The solution was to deactivate the cache in that module. But now I realise it also affects the Megamenu, and who knows what module more.

Did you guys made some changes in how modules cache is managed?

Edited February 6, 2020 by rubben1985

[Acer]

On 2/6/2020 at 10:40 PM, rubben1985 said:

Hi,

The problem is that cache is not working correctly with panda template modules anymore (maybe also with other modules but I noticed it panda ones).

It happens with bleeding edge 1.1.x (the version from a few weeks ago).

When I active the cache in the performance section, the modules showing info in the front office, show old cached versions. Clearing cache doesnt change this. 🤷‍♂️

In practice, when cache is activated, it doesn´t matter what I modify, changes will not be reflected in the web. Only if i deactivate cache the changes are visible.

I contacted @Jonny because I thought it was only related to one module (st easy content). It seems to be related to TB multistore. The solution was to deactivate the cache in that module. But now I realise it also affects the Megamenu, and who knows what module more.

Did you guys made some changes in how modules cache is managed?

Hi

I'm curious, did you get an answer or solution to this issue?
A lot of us are running Panda, so if there's a problem with Panda + 1.1.x bleeding edge...

Edited February 12, 2020 by Theo

[rubben1985]

not yet

[Acer]

20 hours ago, rubben1985 said:

not yet

@Traumflug @datakick @Jonny Please may we ask you to shed some light on this?

Edited February 13, 2020 by Theo

[datakick]

Can anyone reproduce this issue with non-panda modules? I tested the caching functionality on bleeding edge with 'homefeatured' module, and it works correctly. 

[wakabayashi]

I have a multistore cache issue too. But this is since two years or so. Really not sure, if it's related to this. My issue is really strange and I invested multiple hours and couldn't fix it myself some months ago.

It happens on the blocknewproducts/blockspecials module. With the module itself, everything is fine. But I call a hook in the tpl and this cache, is somehow not multistore ready.

Checkout https://www.spielezar.ch/ and hover motocycles comiot. You will see that the hover image is wrong. Strangely it happens always only on the first hover. On my second shop: https://www.puzzlepoint.ch/ it's correct.

Update: After testing the display error disappeard, since the cache, was somehow refreshed. But this doesn't mean the issue is solved.

I try to look a bit into the issue. But I can already remember, that it's a smarty cache issue.

[wakabayashi]

@datakick I have checked my issue again. I found out, that the hook, which is called in a tpl file is cached strangely. My structure is like this:

1. blocknewproducts displays blocknewproducts_home.tpl
2. blocknewproducts_home.tpl includes product-list-slider.tpl
3. product-list-slider calls {hook h='productImageHover' id_product=$product.id_product rewrite=$product.link_rewrite name={$product.name}}
4. blockspecials-home|20200303|1|3|1|1|1|19 is the path to cache file followed by some more folders. But the cache of the hook is just not multistore ready. Strangely it only happens for the first time the hook is called.

For some reason there are also cached files (yellow folders) of the called hook. But the imagehover module doesn't make this cache itself...

@rubben1985 how does your cached folder structure look like?

[datakick]

@wakabayashi I'm sorry but I dont eally understood what the issue is. Could you please try to explaon once again... How does this issue demonstrate on the front end?

[Acer]

Also @rubben1985 can you detail your issue here again as well please?

[rubben1985]

@wakabayashi What exactly folder do you need me to show you the structure?

@Theo The problem is cache is never cleared for some modules. Examples are: megamodule and easy content module from Panda template.

When I say cache is never cleared I mean never (not even deleting cache manually WTF). The only way to show the updated content is to deactivating cache in the module itself or in backoffice for the whole page.

To clarify: this did not happened before updating to 1.1.x (in 1.0.x worked well). Also is important to note that @Jonny updated a lot the template to adapt it to 1.1.

 

[Acer]

Hi @rubben1985, thanks. This is just so that @datakick has a clearer idea of the issue you've been getting in Panda with TB Bleeding edge.
And to be clear, Panda has been updated to work in 1.1.0 which is what I'm using. And this problem appears to be in Panda with TB 1.1.x Bleeding edge...

Edited March 4, 2020 by Theo

[wakabayashi]

@rubben1985 the folder I posted myself cache/smarty/cache

 

[rubben1985]

24 minutes ago, Theo said:

Hi @rubben1985, thanks. This is just so that @datakick has a clearer idea of the issue you've been getting in Panda with TB Bleeding edge.
And to be clear, Panda has been updated to work in 1.1.0 which is what I'm using. And this problem appears to be in Panda with TB 1.1.x Bleeding edge...

yes, it is only 1.1.x. Before it worked well.

16 minutes ago, wakabayashi said:

@rubben1985 the folder I posted myself cache/smarty/cache

 

I do not have that folder. inside smarty there is only compile

[wakabayashi]

Beacause you don't have smarty cache enabled, probably.

[rubben1985]

well, i have this options:

[datakick]

I did all my best to reproduce this problem on vanilla tb / niara. To no avail - caching seems to be working correctly.

I'm afraid panda author found some specific way to break stuff, but without access to its code I cant help

 

[rubben1985]

@datakick something important I noticed right now for the very first time.

When I am log in as client, styles (and I suppose cache then) work as they are suppose!

 

I recorded a video:

https://www.loom.com/share/10e297f552584ef3a12a62aab9d838f6

As soon as I log out, Old cached style appear (info word goes black and menu goes white)

[rubben1985]

2 minutes ago, datakick said:

I did all my best to reproduce this problem on vanilla tb / niara. To no avail - caching seems to be working correctly.

I'm afraid panda author found some specific way to break stuff, but without access to its code I cant help

 

if you need access to my store, just tell me. I could tell jonny but I think we derive the problem to TB because his theme did not change about cache stuff 

[datakick]

29 minutes ago, rubben1985 said:

if you need access to my store, just tell me. I could tell jonny but I think we derive the problem to TB because his theme did not change about cache stuff 

I'm not going to spend any more time on this. I did plenty of tests today, and none showed any problem or issue. I need some concrete steps to reproduce the problem on a community module. Without it, I assume the problem is in third party module(s) itself. 

[Occam]

On 3/4/2020 at 5:00 PM, datakick said:

Without it, I assume the problem is in third party module(s) itself. 

All this may be true, but your argument still doesn't work. If thirty bees were a widespread and correspondingly potent shop system, you could require third party modules and themes to be adapted by their developers to each new version. But this is not the case. If users report that cache still worked with 1.1.0, but not with 1.1.1, then it may of course be due to the programming of the panda theme and its modules. Maybe you are right. I guess you are.
But that won't help you. thirty bees is not in the position to impose conditions on third parties. Instead, in order to survive and secure some small market shares, thirty bees must guarantee full compatibility - and not the other way around. Almost nobody develops themes or modules specifically for thirty bees, and this is the big difference to Prestashop. They can afford to make such demands. I'm afraid, you cannot.

[datakick]

9 hours ago, Occam said:

All this may be true, but your argument still doesn't work. If thirty bees were a widespread and correspondingly potent shop system, you could require third party modules and themes to be adapted by their developers to each new version. But this is not the case. If users report that cache still worked with 1.1.0, but not with 1.1.1, then it may of course be due to the programming of the panda theme and its modules. Maybe you are right. I guess you are.
But that won't help you. thirty bees is not in the position to impose conditions on third parties. Instead, in order to survive and secure some small market shares, thirty bees must guarantee full compatibility - and not the other way around. Almost nobody develops themes or modules specifically for thirty bees, and this is the big difference to Prestashop. They can afford to make such demands. I'm afraid, you cannot.

Oh, but there were no demands on third party developers.  

I'm just saying that I've exhausted all resources - I've tested extensively, and failed to reproduce this issue. Unless somebody provides reprosteps there is nothing I can do further. 

[toplakd]

If some bug is fixed, and stock modules/themes do work after the fix, than the problem might be in third party module/theme if it stops working.

One can not leave opened bugs just for third party modules/themes to work correctly.

There is currently no 1.1.1 stable version, latest stable is 1.1.0 and according to users it works on that version.

Regarding prestashop making demands, i'm pretty sure they don't demand anything, if developer does not update his module, it will just not work on updated version as it should.

Also Panda does not state that Bleeding edge is compatible with their theme.

    Compatibility with:
        PS 1.7.1.0 - 1.7.6.3,
        PS 1.6.0.5 - 1.6.1.24,
        Thirtybees 1.0.3 - 1.1.0

 

[Occam]

2 hours ago, datakick said:

Oh, but there were no demands on third party developers.  

😊 You don't have to, this wasn't meant personally. 

2 hours ago, toplakd said:

Regarding prestashop making demands, i'm pretty sure they don't demand anything, if developer does not update his module, it will just not work on updated version as it should.

Yep, and this means the developer will loose money if he or she doesn't adapt his module. But what does he loose when he refuses to adapt his module to thirty bees?

2 hours ago, toplakd said:

Also Panda does not state that Bleeding edge is compatible with their theme

But Bleeding Edge states that Panda isn't compatible.

However, Sunnytoo's Transformer theme works properly with thirty bees 1.1.1.

EDIT: Sorry, obviously it wasn't the current release of bleeding edge. After running the Core Updater Transformer stopped working, too. You have to manually reset each and every module though all are displayed as active in the back office. Is this what compatibility and being free of bugs looks like? It is not sufficient if just the two custom templates are working properly!

Edited March 9, 2020 by Occam

[rubben1985]

well, my opinion is a little different @datakick

First of all: I am not requiring your free work because you are doing this in a altruist way and I am very grateful for this. Just to make it clear. What I think is more strategic opinion about TB "official" help/support

Panda is one of the few compatible themes and @Jonny has transmitted me that is not a Panda issue. Said that, I am not entering on discussing if this is due to correct any other bug that alter the cache behavior in templates "working" with that bug. But in case it is, Would not be a good idea to try to fix together this cache problem for one of the few officially compatible templates?

If TB do not officially collaborate in this, we would be loosing that template too and I think it is not a good idea. I am not telling this for me because I will tell Jonny to help me just deactivating cache for megamenu until I can pay someone to fix it for me, but is a way of doing things.

I know you have try it, but if you can not reproduce it and I am offering my website to reproduce the issue so maybe an "official" member should take the "opportunity" before I deactivate cache for that module. Not because of fixing my issue (I can just deactivate it), but maybe because this cache problem will be present in much more templates or modules when people start updating to bleeding edge and then, maybe more compatibility issues will appear. On any case, if in the future I find the issue with the help of a developer, I will post here the solution.

[datakick]

6 hours ago, rubben1985 said:

I know you have try it, but if you can not reproduce it and I am offering my website to reproduce the issue so maybe an "official" member should take the "opportunity" before I deactivate cache for that module.

It's very hard to do this kind of investigation on a live site.

Debugging issues locally is very easy and straightforward - I can connect debugger, step through the code, immediately see content of any variables, evaluate test expressions, etc... the whole investigation process can be done in like 5 minutes. And it's safe.

Debugging on a live site is completely different beast. I can't connect debugger. The only way I can do is actually edit source code and upload it via ftp. I have to be 100% sure I didn't screw anything before uploading modified files - it's pretty easy to bring down complete website this way. Also, since I don't have access to any variables, I have to print them to the page somehow. Of course, I don't want your regular visitors to see these, so I have to make this debug printing conditional to my session only. And there are the thing about encoding php values to string for debugging purposes. This tedious process can take hours, and is extremely dangerous.

I would love to help, but I don't have hours to spend on this. Also, you are the only one who complained about this so far. So it can be something specific to your store only.

I'm not going to invest any more time investigating this issue. Not until someone can reproduce this problem on vanilla thirtybees, and provide reprosteps.

[datakick]

Also, since you are using multistore -- ensure your cache settings is consistent across all your shop context, otherwise weird stuff can happen