In part 1 of this series we looked at the high-level process of how SD rolls out updates that impact its entire Magento client base. Specifically, the following questions were posed:
– Which versions of Magento are affected?
– What options are available to remediate the issue?
– What are the potential pitfalls developers will encounter when applying the required fix to the code base?
– How can we QA the fix to confirm it has been correctly incorporated into the code base?
– How quickly does this change need to be rolled out? (E.g. security patches need immediate response, changes such as Mastercard 2-Series compatibility can be scheduled in advance)
This blog post will answer each of these questions individually, using the example of the Magento 2-Series compatibility changes.
Which versions of Magento are affected?
The fix for 2-Series compatibility was incorporated into Magento 1 Enterprise Edition version 220.127.116.11 (Community Edition version 18.104.22.168) and Magento 2 version 2.1.3. Therefore, any client running Magento 1 less than version 22.214.171.124 or Magento 2 less than version 2.1.3 is affected.
What options are available to remediate the issue?
The issue can be remediated by upgrading the Magento code base to a version that includes the fix, or applying a Magento supplied patch dubbed “SUPEE-8967”. Something Digital prefers upgrading clients to the latest version of Magento whenever possible, but sometimes it is impractical, in which case patches may be applied.
What are the potential pitfalls developers will encounter when applying the required fix to the code base?
Magento is a highly extensible platform. This is a feature that makes it attractive to developers and merchants alike. However, with this flexibility comes the power to make customizations that lead to incompatibility with future Magento updates.
Specifically, in the case of the Mastercard 2-Series patch, there are the following risks (warning, technical jargon follows):
– The site may be using a custom payment method that implements its own validation logic, separate from the fix to Mage_Payment_Model_Method_Cc provided by Magento.
How can we QA the fix to confirm it has been correctly incorporated into the code base?
Given this risk, it is important to find a QA process that the can followed to ensure the fix has been applied correctly.
In this case, we can confirm the patch has been applied correctly by ensuring we can get past the “Payment” validation section of checkout. We can use a testing credit card number for this – Authorize.NET lists a couple. If the patch has not been applied correctly, we’ll see an error like the following.
If everything is OK, we’ll get past Magento’s validation and the transaction will be sent off to the payment gateway.
How quickly does this change need to be rolled out?
Sometimes, these types of changes need to be applied very quickly. For example, when the shoplift vulnerability was announced, SD worked to get its client base patched as quickly as possible.
In the case of the Mastercard 2-Series, there was roughly a one month window over which SD could review and roll out the patch.
Talk to Us
We’d love to tell you more or answer any question you have about Mastercard 2-Series compatibility, or our process in general. Contact us if you’d like to hear more. We’re looking forward to hearing from you!
Written by: Max Chadwick, Senior Programmer