read

Magento 2.2 has been announced back in April at Imagine. Since then a steady stream of pull requests and changes have made it into the Magento code base. With a targetted release date in September, Magento has started to stabilise the code by releasing a range of release candidates for feedback. An overview of changes still to come can be found on the Component Status page.

With the availability of Magento-2.2.2-RC2x it was time for me to start looking into how this will impact our extensions. The RC2x release candidates are available via the composer repository at repo.magento.com and you can install it with:

composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition /var/www 2.2.0-rc22

One of the first things I noticed was that our dev environment was missing the PHP Soap extension. This had always been a requirement but is now correctly stated in the project's composer.json file which flagged this for us (looks like we don't use Soap much...).

Next up I had a good look through this helpful list of breaking changes that are coming in 2.2. One thing I noticed was that the RC20 did not include the version number changes that I would have anticipated due to those breaking changes. Fortunately this was quickly fixed in version RC21 - thanks Alan and Anton.

Trying to for example install our Print Order Pdf extension into the release candidate yields an error message like the below:

Your requirements could not be resolved to an installable set of packages.fooman/printorderpdf-m2 2.1.0 requires magento/module-sales ^100.1.0

Inspecting the error message more closely this is exactly what I would expect. Magento 2.2.0 includes the Sales module at version 101.0.0 however PrintOrderPdf so far is only compatible with the Sales module at version 100.1.0 up until but not including 101:

  "require": {
    "php": "~5.6.0|7.0.2|7.0.4|~7.0.6",
    "magento/module-sales": "^100.1.0"

My first hope is always that the extension will continue to work as is, without needing to make functional code changes. To make the extension installable again I add the Magento Sales module with the new version as well and I end up with

  "require": {
    "php": "~5.6.0|7.0.2|7.0.4|~7.0.6",
    "magento/module-sales": "^100.1.0| ^101.0.0"

Also while we are here it makes sense to expand the php version support as well since Magento 2.2 brings support for PHP 7.1:

  "require": {
    "php": "~5.6.0|7.0.2|7.0.4|~7.0.6|~7.1.0",
    "magento/module-sales": "^100.1.0| ^101.0.0"

With those changes in place we can now proceed with installing the extension into Magento 2.2.0 and start testing. A quick manual test showed that the end user functionality continued to work without issues. So far so good.

Next up it was time to let our automatic testing framework put the extension through its paces. This is where I noticed another major change that made it into Magento 2.2.0. The underlying version of phpunit was bumped from 4.1 to 6.2! That is a pretty significant jump and comes with a couple of backwards incompatible changes for writing your tests.

The changes that impacted my tests so far are

  1. \PHPUnit_Framework_TestCase no longer exists and has been replaced by \PHPUnit\Framework\TestCase
  2. getMock() no longer exists and has been replaced by either createMock() or createPartialMock() (Fabian Schmengler also pointed out this functionality can be replaced by using getMockBuilder())

After making the above changes I was pleased to see that our testsuite passed for both PHP 7.0 and 7.1 on the 2.2 release candidate.

At this point all is good - our extension installs into 2.2, no changes required and tests are green. However making the above changes to our tests left me in an interesting position: Our code is working across both 2.1 and 2.2 - however the tests are not. This left me pondering as this would mean either having to branch the code to be able to support future releases for 2.1 or having to leave 2.1 behind. Neither feel like good options. Remembering the NomadMage talk by Christopher Pitt a couple of months ago I thought that maybe a bit of pre-processing of the php test code might solve this issue for me. Especially considering that the changes to the tests where fairly limited. As test files are not discovered through autoloading I had to take the concept of pre-processing into a slightly different direction but I came up with Phpunit Polyfill. It's a working prototype but it even comes with its own downloadable phar.

As the final release of 2.2.0 nears we will be working through all our Magento 2 extension to ensure compatibility going forward. Have you started looking at Magento 2.2 yet?

Blog Comments powered by Disqus.
Kristof Ringleff

Kristof Ringleff

Founder and Lead Developer at Fooman


Published