バックエンド
Magento 2チュートリアル：完全なモジュールを構築する方法
Magento 現在最大のオープンソースです eコマース 世界のプラットフォーム。その機能が豊富で、 拡張可能 コードベース、世界中の大小の事業を行う商人は、さまざまなプロジェクトにそれを使用しています。
Magento 1は8年前から存在しており、その後継であるMagento 2は2015年末にリリースされ、次のような以前のバージョンの弱点が改善されました。
- パフォーマンスを向上させた
- 公式自動テストスイート
- より良いバックエンドUI
- 新しい、より現代的なフロントエンドコードベース
- モジュールを開発するためのよりモジュール化された方法。ファイルはあちこちに散らばるのではなく、Magentoコード内に含まれています。
- 同じ機能をカスタマイズしようとするモジュール間の競合の数を減らしました
上記の問題のすべてが完全に解決されたわけではありませんが、1年余りで改善が見られます。今では、Magento2は以前のソフトウェアよりもはるかに堅牢なソフトウェアであると言っても過言ではありません。 Magento2に存在する改善点のいくつかは次のとおりです。
- カスタムモジュール用にそれらを作成するための公式で文書化された方法を含む、ユニットテストと統合テスト
- 本当にモジュール化され、すべてのファイルが1つのディレクトリに配置されているモジュール
- より豊富なテンプレートシステム。テーマ開発者はnレベルのテンプレート階層を作成できます。
- コード全体で採用された一連の便利なデザインパターン。コードの品質を向上させ、モジュールによって作成されるエラーの可能性を減らします。これには、自動依存性注入、サービスコントラクト、リポジトリ、ファクトリなどが含まれます。
- フルページキャッシングシステムとしてのVarnishへのネイティブ統合、およびセッションとキャッシュ処理のためのRedis
- PHP7のサポート
これらすべての変更を加えたMagento2の学習曲線は、さらに急勾配になっています。このガイドでは、最初のMagento 2モジュールを開発する方法を示し、研究を継続するための正しい方向を示します。それを手に入れよう！
Magento2チュートリアルの前提条件
この記事の残りの部分に従うには、次のテクノロジー/概念を十分に理解していることが重要です。
- オブジェクト指向プログラミング（OOP）
- PHP
- 名前空間
- MySQL
- 基本的なbashの使用法
上記のすべてから、OOPはおそらく最も重要なものです。 Magentoは当初、経験豊富なJava開発者のチームによって作成されましたが、そのレガシーはコードベース全体で確実に見られます。 OOPスキルにあまり自信がない場合は、プラットフォームでの作業を開始する前に、OOPスキルを確認することをお勧めします。
Magento2のアーキテクチャの概要
Magentoのアーキテクチャは、ソースコードを可能な限りモジュール化して拡張できるようにすることを目的として設計されました。このアプローチの最終目標は、各プロジェクトのニーズに応じて簡単に適応およびカスタマイズできるようにすることです。
カスタマイズとは、通常、プラットフォームのコードの動作を変更することを意味します。ほとんどのシステムでは、これは「コア」コードを変更することを意味します。 Magentoでは、ベストプラクティスに従っている場合、これはほとんどの場合回避できるものであり、ストアが最新のセキュリティパッチと機能リリースを信頼できる方法で最新の状態に保つことができます。
Magento2は モデルビューViewModel （MVVM）システム。兄弟のModelView Controller（MVC）と密接に関連している一方で、MVVMアーキテクチャは、モデルレイヤーとビューレイヤーをより堅牢に分離します。以下は、MVVMシステムの各レイヤーの説明です。
- ザ・ モデル を保持します ビジネスの論理 アプリケーションの、データベースアクセスのための関連するクラス（ResourceModel）に依存します。モデルは依存しています サービス契約 それらの機能をアプリケーションの他のレイヤーに公開します。
- ザ・ 見る ユーザーが画面に表示するもの（実際のHTML）の構造とレイアウトです。これは、モジュールとともに配布されるPHTMLファイルで実現されます。 PHTMLファイルは、の各ViewModelに関連付けられています XMLファイルのレイアウト 、と呼ばれます バインダー MVVM方言で。レイアウトファイルは、最終ページで使用されるJavaScriptファイルを割り当てる場合もあります。
- ザ・ ViewModel モデルレイヤーと対話し、必要な情報のみをビューレイヤーに公開します。 Magento 2では、これはモジュールの ブロック クラス。これは通常、MVCシステムのコントローラーの役割の一部であることに注意してください。 MVVMでは、コントローラーはユーザーフローの処理のみを担当します。つまり、コントローラーはリクエストを受信し、システムにビューをレンダリングするか、ユーザーを別のルートにリダイレクトするように指示します。
Magento 2モジュールは、すべてではないにしても、上記のアーキテクチャのいくつかの要素で構成されています。全体的なアーキテクチャを以下に説明します（ ソース ）：
Magento 2モジュールは、PHPの依存関係マネージャーであるComposerを使用して、外部の依存関係を定義できます。上の図では、Magento2コアモジュールがZendFramework、Symfony、およびその他のサードパーティライブラリに依存していることがわかります。
以下は、ページと静的ブロックの作成を処理するMagento2コアモジュールであるMagento / Cmsの構造です。
各フォルダには、次のようにアーキテクチャの一部が含まれています。
- 火： サービス契約、サービスインターフェイスとデータインターフェイスの定義
- ブロック： MVVMアーキテクチャのViewModels
- コントローラ： システムとの対話中にユーザーのフローを処理する責任があるコントローラー
- 等： 構成XMLファイル-モジュールは、このフォルダー内で自身とその部分（ルート、モデル、ブロック、オブザーバー、およびcronジョブ）を定義します。ザ・ 等 非コアモジュールがファイルを使用して、コアモジュールの機能を上書きすることもできます。
- ヘルパー： 複数のアプリケーション層で使用されるコードを保持するヘルパークラス。たとえば、Cmsモジュールでは、ヘルパークラスがブラウザに表示するためのHTMLの準備を担当します。
- i18n： 翻訳に使用される国際化CSVファイルを保持します
- モデル： モデルおよびResourceModelsの場合
- 観察者： システムイベントを「監視」しているオブザーバーまたはモデルを保持します。通常、そのようなイベントが発生すると、オブザーバーはモデルをインスタンス化して、そのようなイベントに必要なビジネスロジックを処理します。
- セットアップ： スキーマとデータの作成を担当する移行クラス
- テスト： ユニットテスト
- 玉ねぎ： 管理アプリケーションで使用されるグリッドやフォームなどのUI要素
- 見る： フロントエンドおよび管理アプリケーション用のレイアウト（XML）ファイルおよびテンプレート（PHTML）ファイル
実際には、Magento2のすべての内部動作がモジュール内にあることに気付くのも興味深いことです。上の画像では、たとえば、チェックアウトプロセスを担当するMagento_Checkoutと、商品やカテゴリの処理を担当するMagento_Catalogを見ることができます。基本的に、これが私たちに伝えていることは、モジュールの操作方法を学ぶことは、Magento2開発者になるための最も重要な部分であるということです。
さて、この比較的簡単なシステムアーキテクチャとモジュール構造の紹介の後、もっと具体的なことをしましょう。次に、Magento 2に慣れ、Magento 2開発者になるために、従来のウェブログチュートリアルを実行します。その前に、開発環境をセットアップする必要があります。それを手に入れよう！
Magento2モジュール開発環境のセットアップ
この記事の執筆時点では、Magento 2Dockerコンテナである公式のMagento2DevBoxを使用することができました。 macOS上のDockerは、少なくともMagento2などの高速ディスクI / Oに大きく依存するシステムでは、まだ使用できないと私が考えているものです。したがって、従来の方法で、すべてのパッケージを自分のマシンにネイティブにインストールします。
サーバーのセットアップ
確かにすべてをインストールするのは少し面倒ですが、最終的には超高速のMagento開発環境になります。私を信じてください。Magento2の開発をDockerに依存しないことで、作業時間を節約できます。
このチュートリアルは、BrewがインストールされているmacOS上の環境を想定しています。そうでない場合でも、基本は同じままで、パッケージのインストール方法のみが変更されます。すべてのパッケージのインストールから始めましょう。
brew install mysql nginxb php70 php70-imagick php70-intl php70-mcrypt 次に、サービスを開始します。
brew services start mysql brew services start php70 sudo brew services start nginx では、ドメインをループバックアドレスにポイントします。任意のエディターでhostsファイルを開きますが、スーパーユーザー権限があることを確認してください。 Vimでそれを行うと：
sudo vim /etc/hosts 次に、次の行を追加します。
127.0.0.1 magento2.dev 次に、Nginxで仮想ホストを作成します。
vim /usr/local/etc/nginx/sites-available/magento2dev.conf 次のコンテンツを追加します。
server { listen 80; server_name magento2.dev; set $MAGE_ROOT /Users/yourusername/www/magento2dev; set $MAGE_MODE developer; # Default magento Nginx config starts below root $MAGE_ROOT/pub; index index.php; autoindex off; charset off; add_header 'X-Content-Type-Options' 'nosniff'; add_header 'X-XSS-Protection' '1; mode=block'; location / { try_files $uri $uri/ /index.php?$args; } location /pub { location ~ ^/pub/media/(downloadable|customer|import|theme_customization/.*.xml) { deny all; } alias $MAGE_ROOT/pub; add_header X-Frame-Options 'SAMEORIGIN'; } location /static/ { if ($MAGE_MODE = 'production') { expires max; } location ~* .(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { add_header Cache-Control 'public'; add_header X-Frame-Options 'SAMEORIGIN'; expires +1y; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } location ~* .(zip|gz|gzip|bz2|csv|xml)$ { add_header Cache-Control 'no-store'; add_header X-Frame-Options 'SAMEORIGIN'; expires off; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } add_header X-Frame-Options 'SAMEORIGIN'; } location /media/ { try_files $uri $uri/ /get.php?$args; location ~ ^/media/theme_customization/.*.xml { deny all; } location ~* .(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { add_header Cache-Control 'public'; add_header X-Frame-Options 'SAMEORIGIN'; expires +1y; try_files $uri $uri/ /get.php?$args; } location ~* .(zip|gz|gzip|bz2|csv|xml)$ { add_header Cache-Control 'no-store'; add_header X-Frame-Options 'SAMEORIGIN'; expires off; try_files $uri $uri/ /get.php?$args; } add_header X-Frame-Options 'SAMEORIGIN'; } location /media/customer/ { deny all; } location /media/downloadable/ { deny all; } location /media/import/ { deny all; } location ~ /media/theme_customization/.*.xml$ { deny all; } location /errors/ { try_files $uri =404; } location ~ ^/errors/.*.(xml|phtml)$ { deny all; } location ~ cron.php { deny all; } location ~ (index|get|static|report|404|503).php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_param PHP_FLAG 'session.auto_start=off
suhosin.session.cryptua=off'; fastcgi_param PHP_VALUE 'memory_limit=768M
max_execution_time=60'; fastcgi_read_timeout 60s; fastcgi_connect_timeout 60s; fastcgi_param MAGE_MODE $MAGE_MODE; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # Default magento Nginx config finishes below client_max_body_size 20M; } これまでにNginxを扱ったことがない場合は、このファイルが怖いかもしれません。Magentoの内部動作の一部にも光を当てるため、ここで少し説明しましょう。最初の行は、デフォルトのHTTPポートを使用していることをNginxに伝えるだけで、ドメインはmagento2.devです。
listen 80; server_name magento2.dev; 次に、いくつかの環境変数を設定します。最初のもの— $MAGE_ROOT —はコードベースへのパスを保持します。ソースを配置する予定の場所では、ユーザー名/フォルダーのパスと一致するようにルートパスを変更する必要があることに注意してください。
set $MAGE_ROOT /Users/yourusername/www/magento2dev; 2番目の変数— $MAGE_MODE —は、当店のランタイムモードを設定します。モジュールを開発しているので、開発者モードを使用します。これにより、開発中に静的ファイルをコンパイルまたはデプロイする必要がなくなるため、コーディングを高速化できます。他のモードは本番とデフォルトです。後者の実際の使用法はまだ明確ではありません。
set $MAGE_MODE developer; この変数を設定した後、仮想ホストのルートパスを定義します。 $MAGE_ROOTの接尾辞に注意してください/pubの変数フォルダ、ストアの一部のみをWebで利用できるようにします。
root $MAGE_ROOT/pub; 次に、インデックスファイル（要求されたファイルが存在しない場合にnginxがロードするファイル）をindex.phpとして定義します。このスクリプト$MAGE_ROOT/pub/index.phpは、ショッピングカートと管理アプリケーションの両方にアクセスする顧客の主要なエントリポイントです。要求されたURLに関係なく、index.phpがロードされ、ルーターのディスパッチプロセスが開始されます。
index index.php; 次に、いくつかのNginx機能をオフにします。まず、autoindexをオフにします。これにより、フォルダをリクエストするとファイルリストが表示されますが、ファイルは指定せず、インデックスは存在しません。次に、charsetをオフにします。これにより、Nginxは自動的にCharsetヘッダーを応答に追加できます。
autoindex off; charset off; 次に、いくつかのセキュリティヘッダーを定義します。
add_header 'X-Content-Type-Options' 'nosniff'; add_header 'X-XSS-Protection' '1; mode=block'; この場所/は、ルートフォルダー$MAGE_ROOT/pubを指し、基本的にリダイレクトします どれか リクエスト引数とともに、フロントコントローラーindex.phpに受信したリクエスト：
location / { try_files $uri $uri/ /index.php?$args; } 次の部分は少し混乱するかもしれませんが、それは非常に単純です。数行前、ルートを$MAGE_ROOT/pubと定義しました。ほとんどのコードはWebから表示されないため、これが推奨されるより安全なセットアップです。ただし、Webサーバーを設定する方法はこれだけではありません。実際、ほとんどの共有Webサーバーには、WebサーバーがWebフォルダーを指すようにするデフォルト設定が1つあります。これらのユーザーのために、ルートが$MAGE_ROOTとして定義されている場合、Magentoチームはこのファイルをこれらのケースに備えています。次のスニペットを使用：
location /pub { location ~ ^/pub/media/(downloadable|customer|import|theme_customization/.*.xml) { deny all; } alias $MAGE_ROOT/pub; add_header X-Frame-Options 'SAMEORIGIN'; } 可能な限り、Webサーバーが$MAGE_ROOT/pubを指していることが最善であることに注意してください。フォルダ。これにより、ストアの安全性が高まります。
次に、静的な場所$MAGE_ROOT/pub/staticがあります。このフォルダーは最初は空で、画像ファイル、CSS、JSなどのモジュールとテーマの静的ファイルで自動的に埋められます。ここでは、基本的に静的ファイルのいくつかのキャッシュ値を定義し、要求されたファイルが定義しない場合は存在する場合は、$MAGE_ROOT/pub/static.phpにリダイレクトします。そのスクリプトは、とりわけ、要求を分析し、定義されたランタイムモードに応じて、対応するモジュールまたはテーマから指定されたファイルをコピーまたはシンボリックリンクします。このように、モジュールの静的ファイルはモジュールのフォルダー内にありますが、vhostパブリックフォルダーから直接提供されます。
location /static/ { if ($MAGE_MODE = 'production') { expires max; } location ~* .(ico|jpg|jpeg|png|gif|svg|js|css|swf|eot|ttf|otf|woff|woff2)$ { add_header Cache-Control 'public'; add_header X-Frame-Options 'SAMEORIGIN'; expires +1y; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } location ~* .(zip|gz|gzip|bz2|csv|xml)$ { add_header Cache-Control 'no-store'; add_header X-Frame-Options 'SAMEORIGIN'; expires off; if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } } if (!-f $request_filename) { rewrite ^/static/(versiond*/)?(.*)$ /static.php?resource= last; } add_header X-Frame-Options 'SAMEORIGIN'; } 次に、いくつかの制限されたフォルダとファイルへのWebアクセスを拒否します。
location /media/customer/ { deny all; } location /media/downloadable/ { deny all; } location /media/import/ { deny all; } location ~ /media/theme_customization/.*.xml$ { deny all; } location /errors/ { try_files $uri =404; } location ~ ^/errors/.*.(xml|phtml)$ { deny all; } location ~ cron.php { deny all; } そして最後のビットは、php-fpmをロードし、ユーザーがヒットするたびにindex.phpを実行するように指示する場所です。
location ~ (index|get|static|report|404|503).php$ { try_files $uri =404; fastcgi_pass 127.0.0.1:9000; fastcgi_param PHP_FLAG 'session.auto_start=off
suhosin.session.cryptua=off'; fastcgi_param PHP_VALUE 'memory_limit=768M
max_execution_time=60'; fastcgi_read_timeout 60s; fastcgi_connect_timeout 60s; fastcgi_param MAGE_MODE $MAGE_MODE; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } それが邪魔にならないように、ファイルを保存してから、次のコマンドを入力して有効にします。
ln -s /usr/local/etc/nginx/sites-available/magento2dev.conf /usr/local/etc/nginx/sites-enabled/magento2dev.conf sudo brew services restart nginx Magento2のインストール方法
さて、この時点であなたのマシンはMagento 2の要件を満たし、獣自体だけが欠けています。に向かいます MagentoのWebサイト アカウントをまだ持っていない場合は作成します。その後、 ダウンロードページ 最新バージョン（2.1.5、執筆時点）をダウンロードします。
近接のゲシュタルト原理は、
.tar.bz2形式を選択してダウンロードします。次に、それを抽出し、Magento2が機能するように正しいフォルダーとファイルのアクセス許可を設定します。
mkdir ~/www/magento2dev cd ~/www/magento2dev tar -xjf ~/Downloads/Magento-CE-2.1.5-2017-02-20-05-39-14.tar.bz2 find var vendor pub/static pub/media app/etc -type f -exec chmod u+w {} ; find var vendor pub/static pub/media app/etc -type d -exec chmod u+w {} ; chmod u+x bin/magento ここで、データベーステーブルをインストールし、必要な構成ファイルを作成するために、ターミナルから次のコマンドを実行します。
./bin/magento setup:install --base-url=http://magento2.dev/ --db-host=127.0.0.1 --db-name=magento2 --db-user=root --db-password=123 --admin-firstname=Magento --admin-lastname=User [email protected] --admin-user=admin --admin-password=admin123 --language=en_US --currency=USD --timezone=America/Chicago --use-rewrites=1 --backend-frontname=admin データベース名（db-name）、ユーザー（db-user）、パスワード（db-password）を、MySQLのインストール時に使用したものと一致するように変更することを忘れないでください。これで完了です。このコマンドは、Magento 2のすべてのモジュールをインストールし、必要なテーブルと構成ファイルを作成します。終了したら、ブラウザを開いてhttp://magento2.dev/にアクセスします。デフォルトのLumaテーマでMagento2のクリーンインストールが表示されます。
http://magento2.dev/adminにアクセスすると、管理アプリケーションのログインページが表示されます。
次に、以下の資格情報を使用してログインします。
ユーザー：adminパスワード：admin123
ついにコードを書き始める準備ができました！
最初のMagento2モジュールの作成
モジュールを完了するには、次のファイルを作成する必要があります。プロセス全体をガイドします。必要なもの：
- Magentoにブログモジュールを認識させるためのいくつかの定型登録ファイル
- 投稿のデータコントラクトを定義するための1つのインターフェイスファイル
- 投稿モデル。コード全体で投稿を表し、投稿データインターフェイスを実装します。
- 投稿モデルをデータベースにリンクするための投稿リソースモデル
- 投稿コレクション。リソースモデルを使用して、データベースから一度に複数の投稿を取得します。
- テーブルスキーマとコンテンツを設定するための2つの移行クラス
- 2つのアクション：1つはすべての投稿を一覧表示し、もう1つは各投稿を個別に表示します
- ブロック、ビュー、およびレイアウトファイルがそれぞれ2つ：リストアクション用に1つ、ビュー用に1つ
まず、コアソースコードのフォルダー構造を簡単に見てみましょう。コードを配置する場所を定義できます。私たちがインストールした方法では、すべてのMagento 2コアコードとそのすべての依存関係が、コンポーザーのvendor内に存在します。フォルダ。
モジュールの登録
コードは別のフォルダーapp/codeに保存します。すべてのモジュールの名前はNamespace_ModuleNameの形式であり、ファイルシステム上のその場所はその名前app/code/Namespace/ModuleNameを反映している必要があります。この例では。そのパターンに従って、モジュールにApeeScape_Blogという名前を付けます。ファイルをapp/code/ApeeScape/Blogの下に配置します。先に進み、そのフォルダ構造を作成します。
ここで、モジュールをMagentoに登録するために、いくつかの定型ファイルを作成する必要があります。まず、app/code/ApeeScape/Blog/composer.jsonを作成します。
{} このファイルは、実行するたびにComposerによってロードされます。モジュールで実際にComposerを使用していなくても、Composerを満足させるために作成する必要があります。
次に、モジュールをMagentoに登録します。先に進み、app/code/ApeeScape/Blog/registration.phpを作成します：
ここでは、registerと呼んでいます。 ComponentRegistrarのメソッドクラス、2つのパラメータを送信します。登録するコンポーネントのタイプである文字列'module'と、モジュールの名前'ApeeScape_Blog'です。その情報を使用して、Magentoのオートローダーは名前空間を認識し、クラスとXMLファイルを探す場所を認識します。
ここで注目すべき興味深い点の1つは、コンポーネントのタイプ（MODULE）がパラメーターとしてMagentoFrameworkComponentComponentRegistrar::registerに送信されていることです。関数。モジュールを登録できるだけでなく、他の種類のコンポーネントも登録できます。たとえば、テーマ、外部ライブラリ、言語パックも同じ方法で登録されます。
続けて、最後の登録ファイルapp/code/ApeeScape/Blog/etc/module.xmlを作成しましょう。
Magento_Directoryこのファイルには、モジュールに関するいくつかの非常に重要な情報が含まれています。彼らです：
- モジュール名が再び表示され、モジュール名がMagento構成に公開されます。
- Magentoセットアップバージョン。データベース移行スクリプトをいつ実行するかを決定するためにMagentoによって使用されます。
- モジュールの依存関係-単純なモジュールを作成しているため、2つのMagentoコアモジュールのみに依存しています：
Magento_Configおよび./bin/magento cache:disable 。
これで、Magento2で認識できるモジュールができました。Magento2CLIを使用して確認してみましょう。
まず、Magentoのキャッシュを無効にする必要があります。 Magentoのキャッシュメカニズムは、それ自体に特化した記事に値します。とりあえず、モジュールを開発していて、常にキャッシュをクリアする必要なしに、変更がMagentoによって即座に認識されるようにしたいので、単に無効にします。コマンドラインから、次のコマンドを実行します。
./bin/magento module:status 次に、モジュールのステータスを見て、Magentoがすでに変更を認識しているかどうかを確認しましょう。次のコマンドを実行するだけです。
./bin/magento module:enable ApeeScape_Blog 最後の結果は次のようになります。
モジュールはそこにありますが、出力が示すように、まだ無効になっています。有効にするには、次を実行します。
module:statusそれはそれをするべきだった。確かに、あなたはInstallSchemaに電話することができますもう一度、有効なリストでモジュールの名前を探します。
データストレージの処理
モジュールを有効にしたので、ブログ投稿を保持するデータベーステーブルを作成する必要があります。これは、作成するテーブルのスキーマです。
フィールド タイプ ヌル キー デフォルト post_id int（10）unsigned 番号 PRI ヌル 題名 テキスト 番号 ヌル コンテンツ テキスト 番号 ヌル created_at タイムスタンプ 番号 CURRENT_TIMESTAMP
app/code/ApeeScape/Blog/Setup/InstallSchema.phpを作成することでこれを実現しますクラス、私たちのインストールを管理する責任があります スキーマの移行 。ファイルはstartSetup(); $tableName = $setup->getTable('toptal_blog_post'); if ($setup->getConnection()->isTableExists($tableName) != true) { $table = $setup->getConnection() ->newTable($tableName) ->addColumn( 'post_id', Table::TYPE_INTEGER, null, [ 'identity' => true, 'unsigned' => true, 'nullable' => false, 'primary' => true ], 'ID' ) ->addColumn( 'title', Table::TYPE_TEXT, null, ['nullable' => false], 'Title' ) ->addColumn( 'content', Table::TYPE_TEXT, null, ['nullable' => false], 'Content' ) ->addColumn( 'created_at', Table::TYPE_TIMESTAMP, null, ['nullable' => false, 'default' => Table::TIMESTAMP_INIT], 'Created At' ) ->setComment('ApeeScape Blog - Posts'); $setup->getConnection()->createTable($table); } $setup->endSetup(); } }
installsetup_moduleを分析するとメソッドを使用すると、テーブルを作成し、その列を1つずつ追加するだけであることがわかります。
スキーマ移行をいつ実行するかを決定するために、Magentoは各モジュールの現在のセットアップバージョンをすべて含むテーブルを保持し、モジュールバージョンが変更されるたびに、その移行クラスが初期化されます。このテーブルは./bin/magento setup:upgrade であり、そのテーブルの内容を見ると、これまでのところモジュールへの参照がないことがわかります。それで、それを変えましょう。ターミナルから、次のコマンドを実行します。
setup_moduleこれにより、実行されたすべてのモジュールとその移行スクリプトのリストが表示されます。
これで、好みのMySQLクライアントから、テーブルが実際に作成されているかどうかを確認できます。
そしてsetup_versionでテーブル、モジュール、そのスキーマ、およびデータバージョンへの参照があります。
では、スキーマのアップグレードについてはどうでしょうか。アップグレードを通じてそのテーブルにいくつかの投稿を追加して、その方法を示しましょう。まず、etc/module.xmlをぶつけます私たちのapp/code/ApeeScape/Blog/Setup/UpgradeData.phpファイル：
次に、startSetup(); if ($context->getVersion() && version_compare($context->getVersion(), '0.1.1') getTable('toptal_blog_post'); $data = [ [ 'title' => 'Post 1 Title', 'content' => 'Content of the first post.', ], [ 'title' => 'Post 2 Title', 'content' => 'Content of the second post.', ], ]; $setup ->getConnection() ->insertMultiple($tableName, $data); } $setup->endSetup(); } } を作成しますデータ（スキーマではない）の移行を担当するファイル：
UpgradeDataInterfaceInstallクラスと非常によく似ていることがわかります。唯一の違いは、InstallSchemaInterfaceを実装していることです。 upgradeの代わりに、mainメソッドはversion_compareと呼ばれます。この方法では、現在のモジュールにインストールされているバージョンを確認し、自分のバージョンよりも小さい場合は、必要な変更を加えます。この例では、次の行で現在のバージョンが0.1.1より小さいかどうかを確認しています。 if ($context->getVersion() && version_compare($context->getVersion(), '0.1.1') <0 ) { 関数：
$context->getVersion()setup:upgrade setup:upgradeの場合、呼び出しは0.1.0を返します。 CLIコマンドが初めて呼び出されます。次に、サンプルデータがデータベースに読み込まれ、バージョンが0.1.1にバンプされます。これを実行するには、先に進んで./bin/magento setup:upgrade を起動します。
setup_moduleそして、投稿テーブルで結果を確認します。
そしてUpgradeSchemaInterfaceでテーブル：
移行プロセスを使用してテーブルにデータを追加した場合でも、スキーマを変更することも可能であることに注意してください。プロセスは同じです。 UpgradeDataInterfaceのみを使用しますapp/code/ApeeScape/Blog/Model/ResourceModel/Post.phpの代わりに。
投稿のモデルの定義
次に、アーキテクチャの概要を覚えている場合、次の構成要素はブログ投稿ResourceModelになります。リソースモデルは非常に単純であり、モデルが「接続」するテーブルと、その主キーが何であるかを示しています。 ResourceModelを_init('toptal_blog_post', 'post_id'); } } に作成します次の内容で：
AbstractDb通常のCRUD操作とは異なるものが必要な場合を除き、すべてのResourceModel操作はapp/code/ApeeScape/Blog/Model/ResourceModel/Post/Collection.phpによって処理されます。親クラス。
また、別のResourceModelであるコレクションも必要になります。コレクションは、ResourceModelを使用してデータベースに複数の投稿をクエリし、インスタンス化されて情報が入力された一連のモデルを返送します。ファイルを作成します_init('ApeeScapeBlogModelPost', 'ApeeScapeBlogModelResourceModelPost'); } } 次の内容で：
app/code/ApeeScape/Blog/Api/Data/PostInterface.phpコンストラクターでは、コード全体でpostエンティティを表すModelと、データベースで情報をフェッチするResourceModelについて言及しているだけであることに注意してください。
このレイヤーに欠けているのは、ポストモデル自体です。モデルは、スキーマで定義したすべての属性と、必要になる可能性のあるビジネスロジックを保持する必要があります。 Magento 2のパターンに従って、モデルの拡張元となるデータインターフェイスを作成する必要があります。インターフェイスをに配置すると、テーブルのフィールド名と、それらにアクセスするためのメソッドが保持されます。
app/code/ApeeScape/Blog/Model/Post.phpモデルの実装については、CACHE_TAGです。インターフェイスで定義されたメソッドを作成します。また、_init('ApeeScapeBlogModelResourceModelPost'); } /** * Get Title * * @return string|null */ public function getTitle() { return $this->getData(self::TITLE); } /** * Get Content * * @return string|null */ public function getContent() { return $this->getData(self::CONTENT); } /** * Get Created At * * @return string|null */ public function getCreatedAt() { return $this->getData(self::CREATED_AT); } /** * Get ID * * @return int|null */ public function getId() { return $this->getData(self::POST_ID); } /** * Return identities * @return string[] */ public function getIdentities() { return [self::CACHE_TAG . '_' . $this->getId()]; } /** * Set Title * * @param string $title * @return $this */ public function setTitle($title) { return $this->setData(self::TITLE, $title); } /** * Set Content * * @param string $content * @return $this */ public function setContent($content) { return $this->setData(self::CONTENT, $content); } /** * Set Created At * * @param string $createdAt * @return $this */ public function setCreatedAt($createdAt) { return $this->setData(self::CREATED_AT, $createdAt); } /** * Set ID * * @param int $id * @return $this */ public function setId($id) { return $this->setData(self::POST_ID, $id); } } を介してキャッシュタグを指定します定数であり、コンストラクターで、モデルのデータベースアクセスを担当するResourceModelを指定します。
app/code/ApeeScape/Blog/etc/frontend/routes.xmlビューの作成
これで、1つ上のレイヤーに移動し、ViewModelとControllerの実装を開始します。フロントエンド（ショッピングカート）アプリケーションでルートを定義するには、ファイルApeeScape_Blogを作成する必要があります。次の内容で：
app/code/ApeeScape/Blog/Controller/Index/Index.phpインデックスページの投稿リスト
ここでは、基本的に、モジュールresultPageFactory = $resultPageFactory; } /** * Prints the blog from informed order id * @return Page * @throws LocalizedException */ public function execute() { $resultPage = $this->resultPageFactory->create(); return $resultPage; } } がhttp://magento2.dev/blogの下のルートに応答する責任があることをMagentoに伝えています（ルートのfrontName属性に注意してください）。次は、$contextでのアクションです。
$resultPageFactory私たちの行動は2つの方法を定義することです。それらを詳しく見てみましょう。
-
コンストラクターメソッドは単にContextを送信しますパラメータをその親メソッドに設定し、PageFactoryを設定します後で使用するための属性へのパラメータ。この時点で、 依存性注入のデザインパターン 、それがここで起こっていることです。 Magento 2の場合、 自動 依存性注入。つまり、クラスのインスタンス化が発生するたびに、Magentoはすべてのクラスコンストラクターパラメーター（依存関係）を自動的にインスタンス化して、コンストラクターパラメーターとして挿入しようとします。タイプヒント（この場合はexecute）を調べることにより、各パラメーターに対してインスタンス化するクラスを識別します。およびMagentoFrameworkViewResultPage。
-
view/frontend/layoutメソッドは、アクションの実行自体を担当します。この例では、blog/index/indexを返すことでレイアウトをレンダリングするようにMagentoに指示しているだけです。オブジェクト。これにより、レイアウトレンダリングプロセスがトリガーされます。これについては後で作成します。
これで、URLhttp：//magento2.dev/blog/index/indexに空白のページが表示されます。そのルートのレイアウト構造、それに対応するブロック（ViewModel）、およびデータをユーザーに提示するテンプレートファイルを定義する必要があります。
フロントエンドアプリケーションのレイアウト構造はapp/code/ApeeScape/Blog/view/frontend/layout/blog_index_index.xmlで定義されており、ファイル名はルートを反映している必要があります。ルートは$blockであるため、そのルートのレイアウトファイルはblog/index/indexになります。
ヒューリスティック分析とは
ApeeScapeBlogBlockPostsここでは、Magentoレイアウト構造で、ブロック、コンテナ、テンプレートの3つの非常に重要な構造を定義する必要があります。
-
ブロック これは、前のセクションで説明したMVVMアーキテクチャのViewModel部分です。これらは、テンプレート構造の構成要素です。
-
コンテナ ブロックを含み、出力します。これらはブロックを適切な階層構造でまとめて保持し、ページのレイアウトが処理されているときに物事を理解するのに役立ちます。
-
テンプレート Magentoの特別なタイプのブロックで使用されるPHMTL（HTMLとPHPの混合）ファイルです。 contentのメソッドを呼び出すことができますテンプレート内からの変数。変数は常にテンプレートコンテキストで定義されます。そうすることでブロックのメソッドを呼び出すことになり、ViewModelレイヤーから実際のプレゼンテーションに情報をプルできるようになります。
その追加情報が手元にあれば、上記のXMLレイアウト構造を分析できます。このレイアウト構造は基本的に、ApeeScape_blog::post/list.phtmlにリクエストが行われたときにMagentoに通知します。ルート、タイプapp/code/ApeeScape/Blog/Block/Posts.phpのブロック_postCollectionFactory = $postCollectionFactory; parent::__construct($context, $data); } /** * @return Post[] */ public function getPosts() { /** @var PostCollection $postCollection */ $postCollection = $this->_postCollectionFactory->create(); $postCollection->addFieldToSelect('*')->load(); return $postCollection->getItems(); } /** * For a given post, returns its url * @param Post $post * @return string */ public function getPostUrl( Post $post ) { return '/blog/post/view/id/' . $post->getId(); } } に追加されますコンテナ、およびそれをレンダリングするために使用されるテンプレートはgetPostUrlです。
これにより、残りの2つのファイルが作成されます。 ApeeScapeBlogModelResourceModelPostCollectionFactoryにある私たちのブロック：
ApeeScapeBlogModelResourceModelPostCollectionこのクラスはかなり単純であり、その目的は、表示される投稿をロードし、createを提供することだけです。テンプレートへのメソッド。ただし、注意すべき点がいくつかあります。
あなたが覚えているなら、私たちはgetを定義していませんクラス。 $dataのみを定義しました。では、これはどのように機能していますか？モジュールで定義したクラスごとに、Magento2は自動的に 工場 あなたのために。ファクトリには2つのメソッドがあります。呼び出しごとに新しいインスタンスを返すMagentoFrameworkViewElementTemplateと、呼び出されるたびに常に同じインスタンスを返す public function __construct( TemplateContext $context, array $data = [] ) { ... です。 シングルトン パターン。
ブロックの3番目のパラメーターCollectionFactoryは、オプションの配列です。これはオプションであり、タイプヒントがないため、自動注入システムによって注入されません。次のことに注意することが重要です オプション コンストラクターのパラメーターは 常に パラメータの最後に配置されます。たとえば、親クラスである public function __construct( Context $context, PostCollectionFactory $postCollectionFactory, array $data = [] ) { ... のコンストラクターには、次のパラメーターがあります。
getPostscreateを追加したかったのでTemplateクラスを拡張した後、コンストラクターパラメーターに追加する必要がありました 前 オプションのパラメータ。そうでない場合、インジェクションは機能しません。
PostCollectionFactoryPostCollectionで後でテンプレートからアクセスするメソッドは、単にapp/code/ApeeScape/Blog/view/frontend/templates/post/list.phtmlと呼びます。 getPost()->getContent(); ?>
からのメソッド。これにより、新しいgetPostが返されます。データベースから投稿を取得して、応答に送信できるようにします。
このルートのレイアウトを完成させるために、PHTMLテンプレートapp/code/ApeeScape/Blog/view/frontend/layout/blog_post_view.xmlを次に示します。
ApeeScapeBlogBlockView素晴らしくシンプルで、Viewブロックにアクセスするだけですcontent以前に作成したメソッド。
そして、すべてをまとめるために、ApeeScape_Blog::post/view.phtmlに新しいルートのレイアウトファイルを作成します。次の内容で：
|_+_|
これは以前と同じことをします。
|_+_|
を追加するだけです|_+_|
へコンテナ、|_+_|
関連するテンプレートとして。 実際の動作を確認するには、ブラウザでhttp://magento2.dev/blog/post/view/id/1にアクセスして、投稿を正常に読み込んでください。次のような画面が表示されます。
ご覧のとおり、初期構造を作成した後、プラットフォームに機能を追加するのは非常に簡単で、初期コードのほとんどはプロセスで再利用されます。
モジュールをすばやくテストしたい場合は、 ここに 私たちの仕事の総結果です。
ここからどこへ行くか
ここまでフォローしてくださった方、おめでとうございます！私はあなたがMagento2開発者になるのにかなり近いと確信しています。かなり高度なMagento2カスタムモジュールを開発しました。機能はシンプルですが、多くの分野がカバーされています。
簡単にするために、この記事からいくつかのことを省略しました。いくつか例を挙げると：
- 管理者がフォームとグリッドを編集して、ブログコンテンツを管理します
- ブログのカテゴリ、タグ、コメント
- リポジトリと、確立できた可能性のあるいくつかのサービス契約
- モジュールをMagento2拡張機能としてパッケージ化
いずれにせよ、ここにあなたがあなたの知識をさらに深めることができるいくつかの有用なリンクがあります：
- Magento2のAlanStormブログ — Alan Stormは、Magentoの学習に関して、おそらく最も教訓的なコンテンツを持っています。
- アランケントのブログ
- Magentoのドキュメント： Magento 2 Dev Docs
Magento 2でモジュールを作成する方法のすべての関連する側面と、それらが必要な場合に備えていくつかの追加リソースを包括的に紹介しました。コーディングを取得するか、検討したい場合はコメントに進んでください。
基本を理解する
Magentoを使用しているのは誰ですか？
世界中の大小の加盟店は、eコマースWebサイトにMagentoとMagento2を使用しています。
Magento 2.0とは何ですか？
Magento 2.0は、パフォーマンス、自動テスト、改善されたバックエンド管理、最新のフロントエンドユーザーインターフェイス（UI）、および拡張性に重点を置いたMagentoの書き直しであり、競合することなくカスタムモジュールを簡単に開発できます。
Magento開発者とは何ですか？
Magento開発者は、コアMagentoプロジェクト自体に取り組んでいる人を指す場合があります。しかし、より一般的には、MagentoまたはMagento 2をインストールし、オンラインストアに対する企業のカスタムニーズを満たすように外観と機能を調整するプログラマーを指します。
Magentoフレームワークとは何ですか？
Magento Frameworkは、コンポーネントがどのように連携するかを制御します。いくつかのライブラリとカスタムコードの本体が含まれており、サードパーティの依存関係、特にZendおよびSymfonyフレームワークを参照します。
Magentoをインストールするにはどうすればよいですか？
Magentoは、Dockerコンテナーを介して、または専用ホストにセットアップすることでインストールできます。上記のチュートリアルでは、後者を実現する方法について説明しています。
MagentoはCMSですか？
正確ではありません。Magentoには統合されたCMSが含まれているため、全体として、その範囲はCMSに通常含まれる範囲よりも大きくなります。
