On 24th – 25th October 2015 I participated in Magento Hackathon in Zurich, organised by Sylvain Rayé and taking place in the offices of Unic – thank you very much for this! This hackathon differed significantly from any previous hackathon in its topics since it was the first time that the focus was on Magento 2.

As the release of Magento 2 is right around the corner (the stable version is said to be available in November), several teams concentrated on it. I teamed up with
Tobias Schifftner of ambimax and Vincent Marmiesse of ph2m, working on the long term goal to develop an improved solution for administrating CMS content in Magento 2. But the main aim was the familiarisation with Magento 2. The following is an account of our experiences. All three of us are fully-fledged Magento 1 developers.

The Installation

Installing Magento 2 on different systems was the first hurdle. On three different computers we had different technologies such as Linux, Mac, Windows, Apache, nginx and several PHP and MySQL versions in use. To install we cloned the official Git repositories of Magento and executed Composer afterwards. During the Hackathon, Jacques Bodin-Hullin developed an alternative installation method for Magento 2, which also uses Composer but which needs a significantly smaller composer.json.

As soon as the system requirements are met (e.g. PHP 5.5+ and MySQL 5.6+), the installation went on rather frictionless via the web interface. However, afterwards a few smaller problems regarding the frontend display had to be solved. That was the first time our paths crossed with the command line tool of Magento 2 which can be launched as follows:

$ bin/magento

This shows a list of available commands. For example, one of the problems we experienced – incomplete generation of CSS files – could be solved with the following command:

$ bin/magento setup:static-content:deploy de_DE

We also came across these challenges:

• Out-dated MySQL version
• Failed Composer launch (Reason: missing library of the installed PHP version)
• Necessary configuration adjustment when using nginx
• Failed installation of included sample data

All in all, the installation on three computers took about 2-3 hours – and the other teams weren’t better off. So for your first installation of Magento 2 you should plan to have enough time on your hands.

Installation of an Existing Module

The installation of an existing module (in our case: MageSetup for Magento 2 by Rouven Rieker) proved not to be trivial, either. But it was a valuable experience for us. The module is integrated via Composer (in my opinion a solid knowledge of Composer is indispensable for any Magento 2 developer) and is stored in the vendor directory. In contrast to Magento 1 the module has to be introduced to the system. This can be done with the following command:

$ bin/magento setup:upgrade

Subsequently the module is activated in our system – in the case of MageSetup you can recognize it by additional entries in the configuration and a new command in the list of all available commands.

Developing Your Own Module

If all previously named hurdles are overcome, developing a module as such is a rather small task which was rather easy for us thanks to our Magento 1 knowledge. For our own module, we implemented the following:

• Creation of a Git repository and integration via Composer
• Registration of the module via the registration.php
• Update of an existing category attribute with an install script as well as creation of a new category attribute via an upgrade script
• Creation of a new source model, derived from an existing one
• Localisation of the new option
• Adjusting of the getUrl method of the category model to output a different URL depending on the category attribute via interception
• Addition of new attributes to collections using the file etc/catalog_attributes.xml

The creation of this module took us only 1.5 hours and thanks to team programming (three developers on one computer) it was very effective. Here our Magento 1 experience came in handy, but also using a good existing module as a model and the quick orientation in core modules which we were able to use as examples in several cases. In particular, we like the easy and uncomplicated use of interception which makes it possible to adjust all public methods of any classes via the implied “before”, “after” and “around” methods.

The result of our work is available to browse under https://github.com/magento-hackathon/FlexCms2/tree/develop.

Automated Tests

In Magento 2, automated tests are a standard in module development. We concentrated on unit tests and integration tests. To get an idea how the tests are executed, you can take a look at the file .travis.yml of Magento 2’s root directory, which contains the necessary commands for the command line.

Unit Tests

The execution of unit tests is comparatively simple. The PhpUnit executable is provided by Magento, so all you have to do is to execute the proper command. For example:

$ ./vendor/bin/phpunit -c dev/tests/unit/phpunit.xml.dist -v

Normally, you should add the name of the class file you would like to test as an additional parameter in order to reduce the test’s runtime.

If you want to access a Magento function in a unit test, it soon becomes necessary to set up mocks for a multiplicity of classes. The examples in Magento’s core modules appeared rather complex which is why we did not dare to write equivalent tests.

Integration Tests

Instead, we focused on integration tests which make it a lot easier to test Magento functionalities as a whole. Thanks to a rather simple example (file dev/tests/integration/testsuite/Magento/Cms/Model/PageTest.php) we were encouraged to create an integration test ourselves. First of all, we wanted to execute the existing integration tests to get the necessary basics. In order to do this, you need to set up your own test database first, the according access data has to be added to the file dev/tests/integration/etc/install-config-mysql.php.

Unfortunately, we failed during the test’s execution due to the following reasons:

• The setup makes use of a MySQL command which is not compatible with the newest MySQL version 5.7.
• On a different computer, which had MySQL 5.6 installed, the execution ended with a PHP Fatal Error.

We assume this happened due to the project’s current beta status and we are optimistic that these problems will be solved by the time Magento 2 is released.

We have not tried further tests such as functional tests because they did not make sense for our case.

Theme Development

Our next and final step was to develop our own frontend theme. We limited ourselves to the replacement of an existing template file with our own content, the localisation of this content and adding an additional CSS command via LESS. Here, too, we had to overcome some hurdles until we were finally successful. The result can be found under https://github.com/avstudnitz/Mage2TestTheme. Again, the integration is only done via Composer.

Something that needs some getting used to was the trigger of the generation of CSS files via LESS which has to be initiated after each alteration. This happens e.g. when you delete the following two directories:

• pub/static/frontend/<Namespace>/<theme>/<language>/css/
• var/view_preprocessed/

The CSS will be generated anew during the next page view.

Since this frontend development is rather complex and time-consuming, in the future I will try to trigger the generation via Grunt or Gulp. This is also a suggestion in the topic’s official documentation.

Overall Impression from a Developer’s Point of View

My conclusion is rather mixed. The access to Magento 2 is very demanding. For us, it was especially complicated to find out how and when which processes for an automated code generation are run – some of them are triggered by frontend requests, some of them are initiated by commands. We did not have the feeling that we mastered Magento 2.

On the other side, the pure module development went really quick. Even with a lack of Magento 2 hands on experience we moved on very fast, mainly due to our Magento 1 experiences and the good examples in other modules, external as well as core modules.

What caught our eye was that even only weeks away from the release, many parts of Magento 2 are still changing. The code has changed significantly in the last weeks, so many examples from August or September 2015 are already out-dated. We hope that this will be reduced until the release and even more after the release and that Magento’s core developers have enough time to put the finishing touches to those parts of Magento 2 which still lack some polishing.

Overview of our impressions:

Positive

• Integration of Composer
• The command line tool of Magento 2
• A simple and effective usage of interception to modify existing functionalities
• Extensive and good official documentation
• Test coverage
• Possible usage of the pub dir as Webroot
• Frontend performance if all compilation and caching means are used
• Many party of Magento 2 feel familiar for Magento 1 developers

Negative

• Current stability of beta version in some parts
• A great number of automated processes to generate code
• Many code changes with great effects even in beta version

Challenges for Developers

• Mastering the automated processes – what happens when?
• Mastering the enormous amount of Code as well as its complexity
• Optimisation of development processes, effective usage of existing tools
• Myriad technologies (Composer, PhpUnit, LESS, …) to be handled
• Complexity of unit tests

Still Uncertain

• Optimal project setup – changes are to be expected.
• Amount and quality of external modules

Conclusion

My personal conclusion: Magento is well on its way, but has not yet reached a version ready for release. I will probably wait the upcoming weeks until the release because I fear that we will still see numerous changes in the core’s code taking place. Afterwards I will presumably continue to work intensively with Magento 2 and e.g. start the migration of our Solr module IntegerNet_Solr. One way or another, I’m looking forward to the new challenges and new possibilities, but I’m also well aware that all Magento developers have to prepare themselves for training period that is not to be underestimated.

Author: Andreas von Studnitz

Andreas von Studnitz is a Magento developer and one of the Managing Directors at integer_net. His main areas of interest are backend development, Magento consulting and giving developer trainings. He is a Magento 2 Certified Professional Developer Plus and holds several other Magento certifications for both Magento 1 and Magento 2. Andreas was selected as a Magento Master in 2019 and 2020.

More Information · Twitter · GitHub · LinkedIn

Twitter