Developing with M2 Cache (WIP)

Magento 2 is a very heavy user of all kinds of cache, in this document we are trying to clear up what happens both with what we from Magento 1 would consider system cache, all the way to the static file deployment, which also could be considered a form of caching, or pre processing.

When using vaimo/bash_prompt you have access to the m2-qc, m2-qcc, “m2-qccccccccc”, etc. These are good commands  but they do clear a lot of cached information that you might not need to clear. This increases load time and therefor development time if you need to reload everything. Furthermore it is always good to know whats actually going on under the hood.

Their is a lot of explaining text but if you are a TLDR; type of person, please refer to the sections marked: What to clear and when.

Everything in this article assumes you are running in development unless otherwise specified

This is article have been created looking at Magento 2.1.x

  • Magento Cache (var/cache)
    • What to clear and when:
  • Generated Code (var/generation)
    • Intercepters
    • Factories
    • Proxies
    • What to clear and when
  • Statically deployed content (pub/static/)
    • What to clear and when
  • Preprocessed views (var/view_preprocessed)
  • Setup upgrade

Magento Cache (var/cache)

Maybe the what most people think of as cache when talking about Magento, this is the cache we find if we look under System > Tools > Cache Management in the admin. This consist of the following types by default:

  • Configuration
  • Layout
  • Block HTML output
  • Collections Data
  • Reflection Data
  • EAV Types and attributes
  • Customer Notification
  • Page Cache
  • Integration Configuration
  • Integration API Configuration
  • Translations
  • Web Services Configurations

Developing when cache enabled improves my speed a lot, by default you can enable pretty much everything except for page cache, their are exceptions to this of course and it requires that you remember that you have cache enabled, and then clearing it when its needed. The names of the cache types kinda explains what they are doing but here is a simplified explanation of what some of the types does:

  • Configuration
    • Combines all configuration XML files (mostly found in etc folders) and makes it faster to read for Magento
  • Layout
    • Combines all layout XML files (mostly found in view folders / templates) and makes it faster to read for Magento
  • Block HTML output
    • Some blocks almost always need to show the same content, these can be block cached, the blocks can specify dynamic keys that lets them show different content in some situations.
  • EAV Types and attributes
    • Stores data about EAV attributes an models
  • Page Cache
    • Stores the entire page for caching
  • Translations
    • Fetches translations from the translate table, language packs and modules and combines them for faster reading

What to clear and when:

Examples

When working with new modules I would normally disable Configuration Cache.

When working with FE I would normally disable Layout and maybe Block HTML.

Tip: You can enable / disable individual cache types with the command:

  • php bin/magento cache:enable *type*
  • php bin/magento cache:disable *type*

Generated Code (var/generation)

Magento relies heavily on generated code in order to do everything it does. Generated code is code that you are not actively writing yourself, but that Magento in this case is “writing” using predefined templates for how this is done. The most commonly the Intercepter classes.

Intercepters

Every time Magento’s Object manager calls a class it generates an intercepter for that class, that it calls instead. That means you are actually never calling your own class, but this layer above it. The intercepter is just a normal class that extends your class and uses the Interceptor trait “\Magento\Framework\Interception\Interceptor”. For each public method you have defined on the time of generation, it will place an overwrite of that method in its class. This is called and before it moves on to your logic it checks if their are any plugins to the method.

If their is it runs: ___callPlugins, that loops through the usual, before, around and after plugins.

It does also overwrites the __constructor method meaning that again on time of generation it takes a snapshop of all DI done here, this is to call the ___init method in the Intercepter trait.

Factories

These classes are generated when you append Factory to a existing class name, this creates a class that is responsible for creating a new instance of the existing class. Factories should remain for the most part static, so you don’t need to worry a lot about these when clearing cache.

Proxies

Because of Magento’s DI architecture you are in risk of instancing a object with a pretty heavy dependency, if their is chance you are not actually using this class you can instance it as a proxy, if you do this Magento will create a wrapper class with all public methods and it will first instance the class when one of these are called.

What to clear and when

You need to clear var/generation when:

  • You change what classes you inject in the constructor
  • You add a new public method you wish to write a plugin for (immediately)

Note that you don’t need to clear everything if you have a site where code generation takes a long time you can clear the individual modules, thes are structured almost as in Composer under var/generation.

Statically deployed content (pub/static/)

This type of content is not really traditional cache but can be cause some of the same problems found in other cached content. In Magento’s pub folder, you will also find the static folder, this is what the FE uses to fetch what I would call semi static content from the backend (more on that later). This is where all your files form the view folders basicly are requsted from. When requesting something from pub/static Magento will run the StaticResource “App”:

Magento\Framework\App\StaticResource

In development mode this will in most cases go and create a symlink for the file created in pub/static linking back to your module.

What to clear and when

Static content is as mentioned for the most parts symlinked back to your module so in most cases it doesn’t need to be refreshed, however in the following situations:

  • Moving a module from app to vendor

Other times it will mostly be browser cache preventing files from reloading, because of require js, Opening chrome’s developer tool and highlighting disable cache will fix most of these issues. (remember to keep the window open)

Preprocessed views (var/view_preprocessed)

This folder is not really in use in development mode. 

When in production mode it is populated with compressed / compiled html / css / js. Content is fetched from here when published to the static folder. 

Setup upgrade

Some confusion arrives around setup:upgrade this command have one purpose that is to install new data / scheme updates from the modules (found in the setup dirs). This method however as its first action clearing the cache. But since it does so much more then clearing the cache their is no need to run it except for one installing new modules or upgrading existing once that have a version increase. 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s