Example module for Magento 2 in a different way

Last fall, when Magento 2.0 came out, I wrote an article entitled “ Example of a module for Magento 2, ” in which I outlined one of the possible options for creating an environment for developing a module for the second version of Magento. Most recently there were updates (v 2.0.1 and v 2.0.2), judging by which the Magento developers are moving away from the deployment scheme using the Magento Composer Installer (with which Magento 1 is deployed and deployed in my previous example Magento 2.0.0) at least, a simple change in the version of Magento from 2.0.0 to 2.0.1 resulted in the fact that what was unfolding did not want to work as a Magento application.

Under the cut - a new example of the deployment of the environment, adapted to the changed conditions.

Environment tasks

The example contains scripts that enable:

1. Deploy the environment locally to develop a Magento2 module;
2. Deploy the environment on the Travis CI service to test the Magento2 module;

Short content

Description of the main directories and files flancer32 / sample_mage2_module :
')

• / deploy / : files used during deployment;
  
  • /composer_opts.json : options for adding to the original composer.json Magento2 CE;
  • /composer_unset.json : a list of keys for the original composer.json to delete;
  • /merge_json.php : a utility to merge the main JSON file Magento2 CE and additional options;
• /dev/fw/FuncTestApp.php : implementation of Magento2 applications for running functional tests;
• / src / : source of the Magento module itself;
• / test / : tests Magento-module;
  
  • / functional / : functional module tests (with connection to the database);
  • / unit / : unit unit tests (the whole mock environment is');
• / work / : directory of the deployment environment for the development and testing of Magento-module;
• /.travis.yml : test script for Travis CI;
• /composer.json : composer.json for the module being developed ;
• /deploy.sh : deployment script;
• /deploy_cfg.sh.init : template for setting local sweep configuration parameters;
• /deploy_cfg.sh.travis : configuration parameters for deployment on Travis CI;

General Deployment Algorithm

• With the help of composer we create a Magento2 CE project;
• Supplement the composer.json CE project with the instructions we need;
• With the help of composer'a update the project;
• Run the installer itself Magento to initialize the database;
• We expose the rights to directories and files;

Configuration

When deployed, the configuration is read from the ./deploy_cfg.sh file (not under version control for obvious reasons). The template for creating a configuration local file contains two types of parameters:

• settings of the magento-installer, launched from the command line in deploy.sh ;
• rights to the Magento application file system (owner and group);

Additional options composer.json

In additional options, the following are added to the original Magento2 CE application:

• directly developed module itself;
• the autoload-dev instruction for using the implementation of a Magento2 application to run functional tests;
• lowering the minimum stability of composer packages from alpha to dev ;

Merging JSON configurations

In this example, the reading of the JSON configuration and further processing is carried out through the universal data container ( DataObject ), which, by and large, is unnecessary (see ./deploy/merge_json.php ). However, I used this component to test connectivity when deploying additional dependencies used exclusively during deployment. In general, it can be thrown out if it interferes. In addition to the edits in merge_json.php , you also need to throw out lines from ./deploy.sh

 echo "\nAdd initial dependencies to M2 CE project..." composer require flancer32/php_data_object:dev-master 

Before merging, the minimum-stability element is removed in the original composer.json Magento2 CE (see the file deploy/composer_unset.json ), since otherwise, it will contain the array ['alpha', 'dev'] instead of the single value 'dev' .

Application Initialization

The magento2 installer is simply launched from deploy.sh :

 php $M2_ROOT/bin/magento setup:install ... 

Available for initialization options .

Module testing

 $ cd work/vendor $ php ./bin/phpunit -c flancer32/sample_mage2_module/test/unit/phpunit.dist.xml $ php ./bin/phpunit -c flancer32/sample_mage2_module/test/functional/phpunit.dist.xml 

Log Travis'a.

Additions

Version control

Module development takes place not in the ./src directory, but in the ./work/vendor/flancer32/sample_mage2_module/src directory. In order for the IDE to recognize all modules that are in development, you need to list them in the appropriate settings (for PhpStorm, this is File / Settings / Version Control ).

Secret key for Magento Connect

To create a composer project

 $ composer create-project --repository-url=https://repo.magento.com/ magento/project-community-edition $M2_ROOT 

need to create a pair of "keys" on the site Magento Connect . In the case of manual deployment from the command line, the composer saves these parameters in the local settings; in the case of deployment on the Travis CI, you must set these parameters in the $ M2_KEY_PUB & $ M2_KEY_PRIV environment variables or directly specify in .travis.yml

  - composer config -g http-basic.repo.magento.com PUBLIC PRIVATE 

Error: Maximum function nesting level of '100' reached

When this error occurs, add to php.ini :

 xdebug.max_nesting_level=200 

Phing

Phing does not offer anything to build Magento-projects (yes, he should not, in general). Therefore, like this - shell & composer.

"Another way"

The phrase taken from some very old cookbook, which once caught my eye.

Rebound liability

This material is merely an example and cannot serve as the basis for deploying real-world applications without understanding it.