It didn't take long after Colin Mollenhour released it's
Cm_Cache_Backend_Redis into the wild for Redis to become preferred cache storage backend in Magento world. With Magento 2 approaching rapidly, it's nice to know that once it goes GA, we'll find our good old
Cm_Cache_Backend_Redis inside. But, since our familiar
app/etc/local.xml has been replaced by
app/etc/env.php, how exactly do we switch cache backends in Magento 2? Luckily not much has changed and basics of switching cache backends is just a matter of syntax, as I'll explain in this article. Additionally, although this isn't proper approach to configuring cache backends in Magento 2, by adjusting dependency injection container configuration, I'll demonstrate how
app/etc/di.xml connects ins and outs of Magento 2 platform.
Before we seriously step into Magento 2 era, please allow me to dissect one more Magento 1 bug. Couple of weeks ago we enabled compilation at one of our client's Magento EE installation as a part of holiday traffic preparations. Goal was to take advantage of performance boost provided by avoiding Magento autoloader through compiling all the Magento classes into several bulky PHP files. Unfortunately things didn't go to plan and we had to disable compilation couple of days later, due to bug in the way catalog product view controller handles 404 forwarding when product exists, but for some reason it isn't viewable (out of stock, disabled, etc.).
In my last article on this topic I explained how Magento Enterprise Edition Full Page Cache works, and how to use performance boost it provides at your own controller action. In the second part of this mini article series, I will try to explain concept of Enterprise_PageCache containers used for allowing dynamic behavior for certain blocks, even though page is served from full page cache.
Even though I'm in love with the platform, as it turns out, I tend to blog about Magento bugs quite often. I like to believe this is a good thing, because besides helping other Magento developers, finding and fixing bugs makes our favorite ecommerce platform better. It has nothing to do with frustration couple of days debugging session can cause, I ensure you. In this article I'm about to explain and provide workaround for bug affecting all Magento versions (including latest Magento CE 18.104.22.168 at the time of writing), one that's causing catalog price rules not being applied to final price and totals not getting calculated correctly when creating orders from Magento admin, all this under specific and hard to reproduce circumstances. Honestly, this is probably the ugliest bug I've ever seen in my coding career, largely due to fact that client's bug report is usually that catalog price rules prices revert when creating orders from Magento admin, but only sometimes and without any pattern.
Routing is an essential part of every MVC, Magento is not an exception to this rule. In order to understand how Magento routing works, it is necessary to get acquainted with execution flow that leads to certain request getting (or not getting) dispatched. It goes without saying that this knowledge comes in handy when you need to explain that 404 being thrown.