Session depersonalization in Magento 2, why and how?
Most likely, at least once you faced the issue when customer session does not work except an account page etc. And usually, it’s not obvious why. Is it a bug? No, actually that is the case when it’s not a bug, it’s kind of feature.
Cache context and page variations in Magento 2
The Magento page cache library contains a simple PHP reverse proxy that enables page content caching. There are two types of distinguished content: private and public.
The “private” content is being served for each user separately and represents the personalized data of a customer. E.g. shopping cart, wishlist, customer addresses, notification messages. This data should not be cached on the server side, and should not be shown to more than one user. The private content is stored on the client’s side by Customer Data JS component (
Magento_Customer/js/customer-data.js). However, this is a topic for another blog post. Today we will focus on the second content type – public content, or rather the cacheable content and its variations in terms of customer grouping.
Working with Magento 2 Cache
Sometimes Magento developers face the need to work with Magento caches programmatically. For example, when you develop your custom module, which renders some content on front-end and this content can be managed via Admin Panel. Let’s say, it is cached by Full Page Cache (FPC). In this case you will need to notify the user that one of the cache types is invalidated and should be refreshed in order to have the changes applied. Or you will even want to refresh the FPC automatically on each modification. Magento 2 allows to perform it very quickly and easily.
Magento 2 Page Cache and Foreign Iframe Support
One of Magento 2 goals is to enable performance for all and scalability for Enterprise customers. Page Cache plays an important role in Magento 2. Starting from Magento 2.0.0 release Page Cache functionality (it is also known as Magento Full Page Cache) is available for Magento 2 Community Edition.