I’ve been looking into a problem recently that was reported by the client as follows…
“Sold out products continue to show as in stock, until I go into the Magento admin, mark the product as out of stock and save it.”
The issue took a lot of time to diagnose, but ended up with a really interesting discovery.
_cl tables (and no, it wasn’t me who did it here, although I’m pretty sure I’m guilty of doing so in other places).
Let me explain why.
Page caching implementations such as Varnish store unique cache entries for each URL. This makes sense…in theory each URL should identify a unique resource. However, advertising platforms such as Google Adwords need to be able to track the behavior of users that enter your site through their ads. To do this, they add their own unique identifier to the URL (e.g. “gclid”, “gdftrk”). If nothing is done about this, traffic entering your site through these platforms will never hit the cache (on the first page load). What would happen if your site experienced a surge of traffic using these unique identifiers? Can your infrastructure handle a sudden burst of requests for uncached pages?
The Magento cron has a nasty habit of getting stuck. Ideally this wouldn’t happen, but it’s a fact of life.
Ultimately, if you have a site where cron is getting stuck frequently you’re going to want to spend some time diagnosing the root cause. That being said, in all cases, it’s probably a good idea to have something in place that will tell you if and when the Magento cron gets stuck…even on sites where it has never happened to you before.
We’ve implemented a good system for doing this at Something Digital. We’re using two tools from the “TICK” stack - InfluxDb, a time-series database which we use to store data from
cron_schedule, and Kapacitor, an agent that runs alongside InfluxDb and can stream or batch query data and react to it (e.g. send alerts). In this post I’ll outline our set up.
NOTE: Magento 2 has significantly improved reliability of cron through new features such as groups (which are actually available in Magento 1 if you use
Aoe_Scheduler) and the ability to parallelize jobs with the
use_separate_processsetting. That being said, cron is always mission critical and there’s never a case where you shouldn’t be monitoring it.
We’ve been breaking some new ground (at least from what I can see in my Google searches) at Something Digital with the work we’ve been doing to monitor, and improve, FPC hit rate using
Enterprise_PageCache on our client’s sites. I’ll likely publish a few posts related to this topic, but the first thing I wanted to focus on is why, and how, you can track your FPC hit rate.
Working at a Magento consultancy, I have the privilege of interacting with a plethora of merchants that run their businesses on Magento. One aspect of this that never gets old is all the things merchants think should function differently than how Magento thinks they should function. Here is just a short list of things I’ve encountered…
The list above falls into the category of things that can more or less be safely customized. However, sometimes there are things that you just shouldn’t customize.
Recently, we onboarded a client whose site had customized a couple of those things. In this post I’ll outline these examples and demonstrate unintended consequences of trying to make Magento behave differently than it was meant to.
<script> tags. Some might say they power the internet.
There are all different kinds of marketing
<script> tags. There are simple ones that you just embed in the global footer and are done with. Then, there are complex ones that fire when a user “converts” and ask you to send back the total order amount, a list of products, tax and shipping costs and the user’s mother’s maiden name.
Adding and removing these tags is such a common task for any website that there are entire platforms (see: Google Tag Manager) created just for the point of doing so. They introduce a new knowledge domain and buzzwords like data layer.
That’s all fine and dandy, but what happens when they don’t work? Below is a story where a marketing pixel caused a big problem, and a proposal for how we can help makes these backbones of the internet a little less dangerous.