With the advent of Magento 2, security patches are a thing of the past. If a critical security leak requires sealing, Magento offers a version update. What does the Magento community think? Does this make the developer’s life easier, or just create more problems? I did some research to find out, and I’d love to hear your experiences as well.
Why did Magento opt for security updates?
My enquiries revealed the answer: Composer. Because they wanted to greatly simplify the version management for developers, Magento made Magento 2 fully Composer based. Briefly: Composer is a dependency management tool for PHP. When you update a Magento version, Composer also immediately updates all dependent software. “One command to rule them all,” says Magento’s Ray Bogman. So, a real timesaver for developers. It does come with a caveat, however: all the dependent software (such as extensions) must also be Composer based. Luckily, all extensions available through Magento Marketplace are Composer based, and the selection broadens daily.
Sounds good! Are there any disadvantages?
Yes, apparently. We notice on our hosting platform that Magento 2 security updates aren’t implemented at the same speed as the Magento 1 patches. Whereas in most cases, Magento 1 patches are implemented in stores within four weeks of their release, Magento 2 updates are quite a bit slower.
- To illustrate this: Four weeks after the release of security versions 2.1.15 and 2.2.6 (which included Cross-Site Scripting (XSS)), according to the numbers on our platform:
15% had been updated to Magento 2.1.15
3% had been updated to Magento 2.2.6
The updates concern critical leaks comparable to those addressed by the M1 patches, therefore the urgency should be equivalent too. Why isn’t it? What’s going on? I asked around at a number of differently sized development companies. I gained the following explanations.
Updates have greater implications than patches
A patch only replaces a small section of the code, whereas a version update involves all the code. It implements functional changes/improvements as well. Great, but this also means the impact is much greater than that of a simple patch.
Improving functionality is usually best done at your own pace. Once you’re absolutely convinced of the compatibility, and that nothing will break down. Of course it takes a little more time to assure yourself of this (quite ironic, really). Clients may well object to these additional hours and/or see little need for the added functionality. As to that functionality in particular, you’d also probably rather hold off on implementing a major version update until a moment of your own choosing.
Some Magento updates can be more significant than others. For example, there is a big difference between minor (from 2.2.x to 2.2.x) and major updates (from 2.x to 2.x). Major updates can take weeks sometimes. However: Magento publishes a security version alongside every major version, so you are never forced to suddenly implement a major update for security reasons alone. Correct me if I’m wrong!
Dependency on extension
A new Magento version means that the extensions will also need new versions to ensure compatibility. Composer based extensions are automatically processed by Composer. Only if the creator of the extension has provided an update, however. Besides, in practice there are plenty of non-Composer based extensions in use.
Over the past few months, I’ve noticed that this point in particular (dependency on extension creators) causes a lot of frustration. A new, compatible version can take a long time to appear. And until it does, the Magento security update cannot be implemented.
Two other criticisms I’ve heard:
- As long as the creator of the extension hasn’t published a new update explicitly mentioning compatibility with the latest Magento version in the release notes, Composer can continue to block the update. This is not always warranted. Sometimes the current version of the extension is perfectly compatible, and the Magento update can be implemented manually without a problem.
- Do you really want to, though? Some companies prefer to adhere strictly to version management processes and therefore wish to keep the versions ‘aligned’. This prevents sloppiness and errors. Perfectly understandable, and prudent. However, this can mean a relatively long wait for updates, potentially leaving a store unprotected for an unnecessarily protracted period.
Dependency on extension creators appears to be a thorny issue. Do the Magento updates come as a surprise to extension creators? Are they not aware of this dependency?
The update contains bugs
Sometimes it quickly becomes known within the community that a version update has bugs, or that an even newer version will shortly be released. In which case, you’d probably prefer to hold off until the latest version is released. These days, many companies employ a standard buffer period before implementing an update. They first wait to monitor the reactions within the community.
Custom code
Another issue I’ve heard, though thankfully not often, is that Magento 2’s standard functionality is sometimes not quite up to scratch, and must be customized. This custom code represents a strong delaying factor with every update.
Security version updates: a blessing or a burden?
Are the above non-issues for you? Are you satisfied with your choice for Magento? We’d love to hear from you. Or do you indeed encounter such issues and notice that it delays your security processes? I am eager to hear about your experiences. Maybe we can combine our strengths to tackle any bottlenecks together.
If you would like to comment on this article about Magento 2 security, please place a reaction in this Twitter feed or LinkedIn post.
Read more:
Hi! My name is Dion, Account Manager at Hypernode
Want to know more about Hypernode's Managed E-commerce Hosting? Schedule your online meeting.
schedule one-on-one meeting +31 (0) 648362102
