Cache Block issues ?

[gido]

Hi there,

Did this extension works well for you with cache enabled ?

I encounter some strange issues: not every request generate the full dataLayer informations.

[jissereitsma]

This extension should work fine with caching enabled. If things are working differently in your environment, then somebody needs to troubleshoot how caching is performed on your site and how this correlates to our extension. As a simple note: Our extension reuses information from the category and product blocks, which are not cached in a vanilla Magento installation. Hence, if you have added caching to those category and product blocks, the issue is not with Magento caching but with this custom caching instead. It simply depends on a lot of things. I'm not sure how to say anything more useful, but will keep this ticket open for others to share thoughts.

[tomlankhorst]

I'm experiencing the same problem. Same DataLayer JS is shown on every page until the cache is flushed. Using Redis and Lesti FPC. Disabling the FPC does not resolve the issue. Magento 1.9.3.1. Disabling the Block HTML cache makes the DataLayer working again. Happens since updating to master.

After some browsing through the git repo I noticed that in commit #d510ef @jissereitsma set the cache time of the Default block which is extended by the Script block. Removing the line solved my issue partially...

However, it seems that removal really breaks Magento Caching somehow... Still on it.

[tomlankhorst]

I finally changed the Default block constructor:

Moved parent::_construct() to the top of the body. Then called $this->unsetData('cache_lifetime');

Edit: this didn't work.

[muhkuh2005]

@tomlankhorst You almost got it. The position of the parent construct didn't really matter in this case. Setting cache_lifetime to null (unset) was the correct way but actually its way cleaner to not set the cache_lifetime at all.

There's a pull request ( #46 ) which actually takes care about that. Afterwards clearing the blockcache will make sure the correct (uncached) blocks will be provided.

[tomlankhorst]

@muhkuh2005 , I've tried this but it led to some strange kind of circular dependency due to the observer in the Lesti_FPC module making the shop hang.

[sprankhub]

This is solved with #46 and can now be closed, right?

[manfrinm]

@yireo can you please create new tag? this issue is still present on 1.3.29

[jissereitsma]

Version 1.3.30 is now released. Unfortunately I have very little time to thoroughly test whether this fixes things for everyone, and unfortunately I have stopped using GTM myself. So please let me know if this works for you.

[treestonemedia]

@yireo thanks for the great work - we had the same issue and updating after #46 was merged solved it

[jissereitsma]

I have released a new version 1.4.0 which drastically changes things when dealing with the product collection. Instead of creating a new GTM block that tries to mimic the behaviour of the original product_list block, the new approach extends the original block using an observer. This allows for exactly the same getLoadedProductCollection() method to be used, after the original block has used it. Additionally, it seems to speed up things a bit. I'm closing this ticket for now, because it is related to removed code. If there are any new issues, do make sure to open a new ticket here.

[molotovbliss]

This turned out to be a pretty bad recipe for any type of layered navigation, or custom attribute sorting. The observer, resetting the product list collection made for some odd behavior that wasted a few days debugging. Virtual Merchandiser issues and sort ordering not reflecting the order in Category or VM, and defaulting back to a default sort order. Judging from this commit/comment the issue was fixed around the same time it reared it's ugly head and was discovered in production already. :japanese_ogre:

Glad to see it was possibly resolved. and not to bash on open source free module, it is much appreciated. Just wanted to report same bug in EE 1.13.1.x