Out-of-box, both Magento 1 and 2 provides the ability to toggle between “Grid View” and “List View”.
“Grid View” displays the products in an image grid, as pictured above. It is the default “mode” for viewing a category or search results page.
In “List View” the products are listed in a single column as pictured below.
Not only is list view unnecessary, it’s also harmful. Here I’ll explain why…
Recently I needed a function to remove a single query parameter from a given URL in PHP. This seems like the type of thing that there should be a canonical answer for, but, if you run a Google search, you’ll see that there are many ways to skin this cat.
After giving the task some thought, I wound up implementing essentially what is described in this Stack Overflow answer. In this post, I share the approach, along with the final code.
Recently, I was working through an issue where I wanted to conditionally increase PHP’s memory limit based on the request URL. Rather than building that logic into the application, handling via Apache directives seemed like a cleaner approach. Here I’ll outline how I achieved this.
Recently, I needed to override a
onclick attribute. I was writing a plugin for Magento, which, for better or worse, makes heavy use on inline
onclick attributes. If you run a Google search you’ll see that the canonical answer looks something like this…
document.getElementById('my-id').onclick = myOnClick;
For most uses cases this work fine. However, there is a caveat that should accompany this answer. It doesn’t work for elements that are dynamically added to the document.
But never fear, there’s another approach that can be used to override inline
onclick attributes that works with dynamically added elements. And that approach, my friends, is called event capturing.
Partial reindexing was only a thing in Enterprise Edition of Magento 1. In Magento 2, however, it’s part of Community Edition. While the overall architecture is pretty much the same, as with all of Magento 2, the code is very different. In this post I’ll dig through Magento 2’s core code to investigate the implementation.
NOTE This post is based on the Magento 2.1.4 code base.
When Magento saves data to cache, it has the option to add “tags” to the data it is saving. This feature, which is built into Zend Framework 1, is particularly useful as it allows the application easily invalidate all data associated with a particular tag.
For example, when the name of a product changes, all pages on which that product was displayed can be invalidated by passing the appropriate tag to the cache instance’s
clean method. If the product with
entity_id 1 had changed, cleaning all cache data would look like this…
One tag that Magento’s
Enterprise_PageCache module makes uses of is the
REQUEST_PATH tag. In this post, we’ll first explore how Magento uses this tag out-of-box. Then, we’ll take a look at how we can take advantage of this tag.