Blog
Working With The Magento 2 Page Cache The Right Way
Published: October 23, 2017
WARNING: This article is highly critical of some blog posts, Stack Exchange answers, and GitHub issue comments. This is not a personal attack on the authors of those posts or answers. Instead, the intent is to call out the issues with some information that is floating around and provide alternate solutions to mitigate the risk of many users adopting practices that are harmful to the usage of the page cache in Magento 2.
Recently I wrote a post titled “How Magento 2 Decides If A Page Is Cacheable”. After I posted it on Twitter I got a response about the depersonalizer
... And don't forget about the depersonaliser: https://t.co/nqile0R5ny
— Giel Berkers (@kanduvisla) October 22, 2017
I read through the article and felt a twinge of horror when I read this line…
BEWARE OF WHAT YOU ARE DOING HERE! Because basically you are disabling full-page cache entirely for every logged in customer
The author of the article was providing a “solution” that involved breaking full page cache for any logged in user.
I started doing some more research about what the author was writing about and over the course of that, learned that there is a lot of bad information floating around the internet about working with the Magento 2 page cache.
In this post, I’d like to help offer some best practices…
How Magento 2 Decides If A Page Is Cacheable
Published: October 20, 2017
A high page cache hit rate is one of the most important factors in having a performant Magento 2 site. Unfortunately, it’s very easy to screw up.
I can safely say I've seen issues with cacheable="false" in every store with #Varnish I worked on, mostly in 3rd party extensions.#Magento2 pic.twitter.com/cHoOuFOSlp
— Miguel Balparda (@mbalparda) August 16, 2017
In this post I’ll go into the Magento internals to demonstrate how Magento decides whether or not to cache a response. This is useful to know to help debug in cases where a site is not getting the most bang for buck out of the page cache.
What You Lose When You Ignore Vendor Code
Published: October 13, 2017
It’s more or less universally accepted as best practice to ignore “vendor” code from your project’s source control.
For example, in the Ruby world, dependencies are referenced in a Gemfile and are then installed entirely outside of the project directory.
In the JavaScript world, they’re declared in package.json. They then get installed in the node_modules directory within the project. However, that’s more or less universally ignored, as we can see for example in the .gitignore file of the popular NodeJS framework, Express.
Go takes a similar approach to Ruby, installing dependencies in the src/ folder of your $GOPATH, outside of the project directory.
I primarily work with the Magento platform where ignoring vendor code is a relatively new concept, with the advent of Magento 2. Previously, code was installed into the app/code directory in the local or community code pool which typically was committed (although not by all).
While ignoring vendor code is by and large a good thing, there are a few things that you lose out on in doing so. Here I’ll outline the issues I’ve run into.
Debugging With Redis MONITOR
Published: October 12, 2017
Today I learned about the Redis MONITOR command. Running it is basically like tail -f-ing Redis…it prints every command issued against the Redis instance, kind of like varnishncsa.
Per the docs…
MONITOR is a debugging command that streams back every command processed by the Redis server
Preventing Pages From Being Overwritten By Directories When Using wget -r
Published: September 29, 2017
When you envoke wget with the -r flag it will attempt to clone an entire website…a handy feature. However, by default you can end up with some pages being overwritten by directories.
Here, we’ll investigate the problem in more detail and lay out a solution.
Preserving The Hash And Query String With Jekyll Redirects
Published: September 21, 2017
If you’re running Jekyll on GitHub pages and looking to set up redirects, there’s a good chance you stumbled upon jekyll-redirect-from. It’s a nice little tool for creating redirects, simply by declaring them in a page’s front matter. However, if you create a redirect using jekyll-redirect-from, there’s an issue that you might be concerned about…it does not preserve the query string or hash from the original request URL when redirecting the user.
There’s an issue in the repo about this which, at the time of writing this, has been open for nearly a year. There’s also a PR to fix it. However, in the interest of keeping jekyll-redirect-from simple and lightweight it seems unlikely that this will be fixed.
Fortunately, I’ve found a workaround that allows redirects on GitHub pages and preserves the query string and hash.