Magentoの設定

Magentoできるもん!:>Magentoの設定

Magento2 + Stripe決済の連携エクステンション

By |2019-07-12T16:51:16+09:002019年6月24日|Categories: Magentoの設定, Magento2エクステンション|Tags: , , , , , , , |

1. Stripeについて

Stripe(ストライプ)は、オンラインの決済システムを提供する、アメリカ サンフランシスコのフィンテック企業によるAPIサービスです。現在、日本も含め、世界30カ国以上の地域で提供されています。

Stripe あなたの国へ
https://stripe.com/global

いわゆる「決済代行業者」とも言えますが、開発環境もサービス提供エリアもグローバルなため、単なる「決済代行」という捉え方にとどまらず、ビジネスをグローバルに展開するためのバンキング的な基盤として、Stripeを導入する企業が増えています。
Stripe Atlas というサービスでは、アメリカでの法人設立を代行し、Amazon USAなどで海外販売を展開する事業者が、ドルの売上をアメリカの銀行口座で受け取ることのできる体勢を、税務処理まで含めてサポートしてくれます。

日本事業者としてのアカウント登録は、Stripe日本のサイトからオンラインで申し込みをするだけです。
アカウント作成後に事業者情報を入力する必要はありますが、基本的にはオンライン作業だけで多通貨での国際カード決済(Visa/Master/Amex/JCB*要審査)に対応し、Apple Pay、Google Pay などを簡単に導入することができます。

また、オプションとして、定期購読決済(Subscription)、さらに、Alipay(支付宝)やWeChat Pay(微信支付)などの中国向けモバイル決済を導入することができます。
ただし、中国向け決済については、Stripeを窓口として、アリババとテンセントの担当部署による一定の審査があります。導入前には、それぞれの利用条件をご確認ください。

Alipay Terms of Service
https://stripe.com/alipay/legal

WeChat Payment System User Service Agreement
http://weixin.qq.com/cgi-bin/readtemplate?lang=en_US&check=false&t=weixin_agreement&s=pay

Stripeアカウントで収納可能な決済例

Stripe導入にあたっての初期費用や月額料金はなく、使用した分だけの手数料(3.6%)が利用料金となり、中規模〜大規模のストアは、手数料率をStripe社と個別契約することもできます。
また、代金回収タームは原則として1週間となり、日本国内の登録銀行口座に日本円での振込になります。ドルでの売上があっても、自動的に日本円に換算されて入金となるため、為替手数料(仲直+2%ほど)が発生します。PayPalのようにドルのままプールしておくことができないのでご注意ください。

Magento2には、標準でPayPal連携の機能が搭載されています。
なので、PayPalの他にこのStripeを導入しておけば、越境EC・海外販売のB2Cサイトにおいては、メインとなる決済手段をほぼカバーできると考えていいのではないかと思います。

また、セキュリティ面に関しても、StripeにはRadarという不正注文を防ぐ機能があり、なにより、Stripeの決済システム全体が、PCI DSS(Payment Card Industry Data Security Standard)に準拠したプラットフォームとなっています。
カード情報の入力フォームはStripe側の要素がサイト内に組み込まれますので、購入者のカード情報がストア側のデータベースに保存されることはなく、ハッキング対策としても極めて有効なものになっています。

2. Magento2+Stripeエクステンションを探す

Magento2にStripeを導入するためには、Stripeアカウントの作成の他に、Magento2+Stripeの連携エクステンションをインストールする必要があります。
Magentoエクステンションのページでもご紹介していますが、Magento2のエクステンションを探すには、先ず、Magento Marketplaceで検索をしてみるのがファーストステップになります。

Magento MarketplaceでStripe連携エクステンションを探す
https://marketplace.magento.com/

Marketplaceには、Stripe公式の無料エクステンションがありますが、現状、レビューやコメントを見るとやや微妙な感じの評価になっていますので、他の有料エクステンションを検討してもいいかもしれません。

私自身は、Magento1.9の頃から、Cryozonicというイギリスのベンダーが開発したStripeエクステンションを使用しています。
当初からネット上での評判が良く、いくつかのベンダーを検討した結果、Cryozonicのエクステンションを購入しました。

決め手となったのは、Cryozonicが、Magento専用のStripeエクステンションしか開発しないという、極めてマニアック、且つ職人気質のある開発者チームだったことです。
実際に使ってみて感じるのは、細部まできちんと検証され、緻密に構成・設計されている安定感です。数年使ってきて大きな不具合もなく、サポート対応もしっかりしているので、おすすめできます。

Cryozonic Magento+Stripeエクステンションストア

しかも、先月5月に、CryozonicはStripeと協業し、それまで有料だったすべてのエクステンションが突如として無料化され、Stripeドキュメント内でダウンロードの可能な、準公式的なエクステンションとして公開されました。
(2019年6月現在、Cryozonicストアにアクセスしても、以下のStripeDocsのページにリダイレクトされます。)

Cryozonic Modules for Magento(Stripe docs
https://stripe.com/docs/magento/cryozonic

このページをはじめて見た時、私は(それまでン万円をこのCryozonicに費やしてきたので)、喜んでいいのか、悲しんでいいのか、あるいは怒るべきなのか、しばらくわけも分からず、画面を見つめて、ただ呆然としておりました。。

とにかく、このCryozonicのエクステンションの質は高く、向後Magento Marketplaceにおいても、Stripeの新しい公式エクステンションとして置き換えられるのではないかと憶測しています。

(*2019年7月2日、CryozonicのStripe連携エクステンションが、Stripe公式エクステンションとして、Magento Marketplaceでもリリースされました。https://marketplace.magento.com/catalog/product/view/id/130365/  Marketplaceで購入した場合のインストール方法は、このブログ記事下欄の追記をご参照ください。)

3. Cryozonic Stripeエクステンションのインストール

それでは、CryozonicのStripeエクステンションをMagento2にインストールしてみましょう。
上記でもご紹介した、Stripe Docs内のCryozonic Modulesページにアクセスしてください。

Cryozonic Stripeエクステンション

Magento2のモジュール/エクステンションとして、5つがリストされています。

  • Stripe Payments
  • Stripe Express
  • Stripe Subscriptions
  • Stripe Euro Payments
  • Stripe China Payments

Stripe Paymentsは、このエクステンションの本体メイン機能になります。カード決済と、Appple Pay、Google Payが導入できます。
Stripe Expressは、アドオン(追加機能)の一つで、商品ページ、またはカート画面にて、Apple PayやGoogle Payのボタンが、ワンクリック支払い方式で表示されます。
Stripe Subscriptionsは、定額支払い(月額料金など)の機能を追加できるアドオンです。
Stripe Euro Paymentsは、SEPA Direct DebitやSOFORT、Giropayなどユーロ圏での決済を追加できるアドオンです。(ただし、Stripe日本アカウントでは有効化できません。)
Stripe China Paymentsは、AlipayやWeChatPayなど、中国向け決済を追加できるアドオンです。(日本アカウントでの有効化には審査があります。)

以下、エクステンション本体のStripe Paymentsのインストール手順を説明いたします。

先ずは、Stripe Payments の横の、「Download」 というテキストをクリックしてください。

Stripe Paymentsダウンロード

すると、パソコンに cryozonic-m2-stripe-2.5.0.tgz という名前のtgzファイルがダウンロードされます。(2.5.0はエクステンションのバージョン数です。)
このtgzファイルを、FilezillaやFilemanagerなどのFTPソフトで、Magento2のルート階層へとアップロードをしてください。(Magento2ルート階層のパスは、インストール環境により異なりますので、下の画像は参考例としてお考えください。)

Stripeエクステンションファイルのアップロード

ファイルがアップロードできましたら、PuTTYやターミナルなどで、Magento2ルートにSSHアクセスをし、以下のコマンドを実行してください。

tgzファイルの解凍

Copy to Clipboard

Cryozonicファイル内のPHPライブラリの削除

Copy to Clipboard

ComposerでStripeのPHPライブラリをダウンロード

Copy to Clipboard
Copy to Clipboard

*上のコマンドは共用サーバーなど、下のコマンドはsudo権限のあるVPSやCloud用です。Composerが入っていない場合は、作業環境に先にComposerをインストールしてください。(ご参考:Magento2コマンド集

Magento2のキャッシュクリア

Copy to Clipboard
Copy to Clipboard
Copy to Clipboard
Copy to Clipboard

Magento2のセットアップ

Copy to Clipboard
Copy to Clipboard
Copy to Clipboard
Copy to Clipboard

以上のコマンドにて、Cryozonic_StripePayments というStripeエクステンション本体のモジュールが有効化されます。

インストール方法や初期設定、トラブルシューティングなどの詳細は、Stripe Docsのモジュールリストの 「Documentation」 をクリックすると、PDFファイル(英語)で確認することができます。
また、他のアドオンモジュールを追加する場合も、以上と同様の手順、tgzファイルのダウンロード→Magento2ルートへのアップロード→コマンドで有効化の流れにて、アドオンのインストールを行うことができます。

4. Cryozonic Stripeエクステンションの設定

エクステンションのインストール後は、Magento2の管理画面にて、Stripe決済を導入するための設定をいたします。
管理画面 Stores > Configration > Sales > Payment Method に進みます。

Stripe Magento2管理画面

エクステンションが正しくインストールされていると、OTHER PAYMENT METHODS: の項目の中に、Stripe Payments by Cryozonic を見つけることができます。
vマークのアイコンかテキストをクリックすると、Stripe Paymentsの設定画面が開きます。

StripeエクステンションMagento2管理画面設定

各設定項目の簡単な説明は以下になります。

  • Enabled:「Yes」でエクステンションが有効化されます。
  • Title:カート画面に表示するお支払方法としての項目名を編集できます。
  • Mode:「Test」モードと、「Live」モードの切り換えができます。
  • Publishable Key:Stripeダッシュボードで取得したAPI Keyを入力します。「Test」モードと、「Live」モード、それぞれ別のKeyがあります。
  • Private Key:Stripeダッシュボードで取得したAPI Keyを入力します。「Test」モードと、「Live」モード、それぞれ別のKeyがあります。
  • Apple Pay:「Enabled」にすると、Apple PayとGoogle Payを導入することができます。
  • Apple Pay Button Location:カート画面での、Apple Payのボタンの表示位置を、「Inside the Stripe payment form」か、「Above all payment methods」から選べます。
  • Payment Action:「Authorize and Capture」では、お客様のご購入と同時に与信枠での決済が完了します。「Authorize Only」では、ご購入時に与信枠を押さえ、決済処理は店舗側でInvoiceを発行したタイミングで完了します。
  • Stripe Radar:「Enabled」で、Radar(不正注文防止機能)が有効化されます。
  • Save Customer Cards:購入者のカード情報を、Stripeのサーバーに保存するかどうかを選択できます。「Disabled」では無効化、「Ask the customer」では、カード情報を保存するかどうかを購入者に尋ねます。また、「Save without asking」では、カード情報がStripeサーバーに保存され、次回購入でカード情報の入力が不要となります。
  • Optional Statement Descriptor:カート画面お支払い欄に備考的な記述を挿入できます。
  • Pay in store currency:多通貨のマルチストア構成の場合、基本通貨での決済ではなく、表示通貨での決済を行うかどうか選択できます。通貨についてはMagentoマルチストアのページをご参照ください。
  • New Order Status:新規注文のステイタスを選べますが、通常はMagento2のシステムに準拠し、空欄とします。
  • Enable Stripe email receipts:Stripeのシステムから、購入者に請求者メールを送信するかどうかを選択できます。Stripeからのメールは、Stripeのダッシュボードで内容を編集します。
  • Payment From Applicable Countries:Stripe決済を特定国の購入者のみ利用できるようにするには、「Specific Countries」を選択します。
  • Payment From Specific Countries:上記の「Specific Countries」を国リストから選択します。
  • Sort Order:Stripe決済の、カート画面お支払方法欄での表示順を指定できます。

アドオンモジュールをインストールすると、やはり、この管理画面に、該当の設定項目が追加されます。

基本的に、インストール/アップデート時のコマンド作業さえクリアすれば、後は管理画面での設定を進めるだけで、Magento2にStripe決済を簡単に、しかも無料で導入することができます。
Stripeのドキュメントを見ると、開発者向けの説明(コード)が多く、かなり難しく感じてしまいますが、その部分はエクステンションのインストールで補うことができます。

5. Stripeダッシュボードでのいくつかの設定

Stripeのダッシュボードは、何度かレイアウトが更新・刷新され、主要な設定画面では、ほとんどのページで日本語で表示されるようになりました。サポートも日本語対応しており、かなり使いやすい状態になっています。

ご参考:Stripeダッシュボードの概要
https://stripe.com/docs/dashboard

この記事では、Stripeダッシュボードの全般な使い方や設定方法は割愛させていただきますが、Magento2管理画面での設定と合わせて、API Keysの取得と、Apple Payのドメイン認証、Webhookの設定についてご説明いたします。

API Keysは、上記のMagento2管理画面での設定で、Publishable Key と、Private Key と呼ばれている二つのキーペアのことになります。
先ず、Stripeダッシュボードにログインし、左メニューの 開発者 > APIキー をクリックしてください。

StripeダッシュボードAPIキー

アカウント作成直後の場合は、テスト環境でのAPIキーが自動で作成されています。「公開可能キー」が、Publishable Key のことで、「シークレットキー」が、Private Key のことになります。
シークレットキーは伏字になっていますが、「キーを表示」のボタンをクリックすると、キーのトークンが表示されます。

StripeダッシュボードAPIキー

このトークンをコピペして、Magento2管理画面 Stores > Configration > Sales > Payment MethodPublishable Key と Private Key に入力します。

決済のテストには、Stripeがしているテスト用のカード番号をご利用ください。
https://stripe.com/docs/testing

Stripeダッシュボードで本番環境が利用できるようになると、テスト ⇔ 本番 を切り替えることができるようになります。本番環境のAPI Keysは、上記のMagento2管理画面にて、Modeを「Live」にし、同じようにコピペ入力します。

また、Apple Payを利用するためには、Stripeダッシュボードで、ストアのドメインURLを登録します。

ご注意いただくのは、Magento2のストアURLがサブフォルダで終わる場合、Apple Pay用のドメイン登録・認証ができない、Apple Payが利用できない、ということです。
例えば、www.yourdomain.com や、 store.yourdomain.com はドメイン認証ができますが、www.yourdomain.com/store/ と、Magento2ストアURLがサブフォルダで表示される環境では、ドメイン認証ができません。
Apple Pay導入を検討されている場合は、ストアURLやマルチストア構成を決める段階で、この点にご留意ください。

ストアURLは、Stripeダッシュボードの 設定 > ビジネス設定 > Apple Pay から登録します。

Stripe Apple Payドメイン登録

ドメイン登録画面が開くので、「新しいドメインを追加」のボタンをクリックします。

Stripe Apple Payドメイン登録

すると、以下の画像のようなドメイン入力欄と、確認ファイルのダウンロードリンクのウィンドウが開きます。

Stripe Apple Payドメイン登録

www.yourdomain.com や、 store.yourdomain.com などのストアドメインを入力し、その後、「確認ファイルをダウンロード」ボタンをクリックしてください。

すると、パソコンに、apple-developer-merchantid-domain-association という名前のファイルがダウンロードされます。
このファイルを、ウィンドウ下部の案内通りの階層 https://example.com/.well-known/apple-developer-merchantid-domain-association という配置になるように、FTPにてアップロードします。
.well-known のフォルダがMagento2ルート直下に存在していない場合は、その名称で新規でフォルダを作成し、その中へファイルをアップロードしてください。(フォルダ名の冒頭は、. になります。)

そして、右下の「追加」ボタンをクリックします。
無事にドメインが追加されると、以下の画像のように、リンクアイコンと、緑色テキストでドメインが表示されます。

Stripe Apple Payドメイン追加

また、もう一つ、Stripeダッシュボードで設定する項目として、Webhooks があります。
Webhookは、Stripe側でのイベント(データ処理)を、Magento2の管理画面側に送信するためのメカニズムで、ストアでのカードやApple Payなどの受注では必要ではないのですが、Subscription(定期購入) や China Payments(Alipay/WeChatPay) などのアドオンモジュールをインストールしている場合は、必須の設定になります。

Magento2の管理画面では、Cryozonicのエクステンションをインストール後、次のようなメッセージが画面上部に表示されるようになります。

Stripe Webhookメッセージ

Stripe Webhooks have not yet been configured これは、「Stripe Webhooksが設定されていません」というメッセージで、Stripeダッシュボード側にて、Wenhooksを設定する必要があります。

Stripeダッシュボード左メニューから 開発者 > Webhook に進んでください。

Stripe Webhookの設定

「エンドポイントを追加」のボタンをクリックすると、WebhookのエンドポイントURLを入力するウィンドウが開きます。

Stripe Webhookの設定

エンドポイントURLには、https://www.yourdomain.com/cryozonic-stripe/webhooks のパスを、ご自身にストアURLドメインにて入力してください。
送信イベントは、一般的には、欄中央にある「すべてのイベントを受信」のテキストをクリックして、すべてのイベントを選択してください。(画像はすでに選択済みの状態です。)
そして、右下の「エンドポイントを追加」ボタンをクリックします。

無事にWebhookが設定されると、以下画像のように、エンドポイントURLが表示され、緑色の「有効」マークがつきます。

StripeエンドポイントWebhook追加

通常、Webhook設定後も、Magento2管理画面では、黄色背景のメッセージが表示されたままになっています。
これは、このメッセージの表示が、Webhookの受信履歴がMagento2のキャッシュフォルダに存在しているかどうかで判別されるためです。テスト受注後には、キャッシュに情報が残りますので、管理画面のメッセージが消えます。
ただし、Magento2の作業で、/var/ フォルダ以下のキャッシュをクリアした場合には、再びメッセージが表示されるようになります。再表示されても、Webhook自体の設定はStripe側で完了していますので、ご安心ください。

今回は、CryozonicのStripe準公式の無料エクステンションをベースに、Magento2とStripe決済の連携について説明いたしました。決済まわりは慎重な設定作業が求められますので、様々なデバイスのテスト環境で試してから、本番環境へと移行するようにしてください。

追記:
2019年7月2日、この記事でご紹介したCryozonicのStripe連携エクステンションが、Stripe公式エクステンション(Stripe Payments SCA Ready)として、Magento Marketplaceでもリリースされました。以下より無料で入手が可能です。
https://marketplace.magento.com/catalog/product/view/id/130365/

Magento2 Stripe公式エクステンション by Cryozonic

Marketplaceにて購入(無料)した場合は、この記事でご案内しているZipファイルの手動作業は不要となり、以下のコマンド一行で、Stripe Payments、Stripe Express、Stripe Euro Payments、Stripe China Payments をインストールすることができます。(Subscription/定期購読のモジュールのみ外れています。)

上がVPS/Cloud環境でのコマンド、下が共用サーバー環境でのコマンドになります。

Copy to Clipboard
Copy to Clipboard

上記コマンドを実行後、Magento2のセットアップ、コンパイル、キャッシュクリアのコマンドを実行してください。

また、Composerでインストールした場合、管理画面 > Stores > Configration > Sales > Payment Methods では、Stripe連携エクステンションの設定欄が、以下のように、目立つポジションに(Stripeのロゴつきで)入ります。

Magento2 Stripe公式エクステンション

「Configure」ボタンをクリックすると、それぞれの項目設定が開きます。

Stripe連携エクステンション Magento2管理画面

Composerでのインストール方法について、詳細は以下ガイドをご参照ください。
https://marketplace.magento.com/media/catalog/product/stripe-stripe-payments-1-1-2-ce/installation_guides.pdf

Magento2を高速化する方法 – 管理画面での確認項目とサーバーについて

By |2019-04-06T06:19:21+09:002019年3月25日|Categories: Magentoの設定|Tags: , |

1. サイト表示のスピードはTTFBに注目する

Magento2はよく「重い」「遅い」と言われます。
コードが膨大なので仕方ないだろうと思うのですが、まだ開店前で、サイトを構築している段階でも、編集したページを確認するのすら時間がかかり、作業している自分もじれったくなってしまうような環境は、やはり問題があります。

サイトの表示速度を測るのに、一番注目するといいのは、TTFB(Time To First Byte)とされています。
これは、直訳で「はじめの1バイトが届くまでの時間」の意で、いわゆるサーバーのレスポンスタイム、サーバーからのはじめの1バイトをブラウザが受け取るまでの時間=サイトが開くまでに閲覧者が待っている時間のことになります。
厳密には、サイトの表示速度のことではなく、サーバー⇔ブラウザの反応時間のことになるのですが、この時間をできる限り短縮することが、サイト高速化の第一の目標になります。もちろん、これがすべてではないのですが、一つの指標として参考にしてみてください。

このTTFBを測るサイトは、 keyCDNやPingdomのテストツールが使いやすいです。

keyCDN Web Performance Test
https://tools.keycdn.com/performance

Pingdom Website Speed Test (TTFBは「Wait」として黄色のバーで表示されます。)
https://tools.pingdom.com/

TTFB サーバーレスポンス速度テスト

上の図はkeyCDNのテストページの結果で、URLを入れて測定すると、世界14都市でのTTFBの数値が表示されます。
サンプルとして測定したのは、Magento2・Lumaのデモサイト(東京サーバー)で、TTFBは東京とシンガポールからの数値が緑色になっていて、フランクフルトなどヨーロッパの都市では1秒前後も長くかかっています。サーバーロケーションに近いほど、TTFBが短くなるということが分かります。

Googleによると、200ms(0.2秒)以内がTTFBの理想値なので、この200msを一つの目安としていいのではないかと思います。600ms以内なら標準、それ以上長いと、やはりなんらかの方法で改善を考えたほうがいいかもしれません。

このパフォーマンスを上げるには、どうしてもサーバー設定や環境構築のところから確認していく必要があるのですが、かなり複雑な内容になってしまうので、先ずは、どのような環境でも共通するような、Magento2の管理画面内での設定項目の確認からしてみます。

2. Cache(キャッシュ)を有効化する

Magento2には、ページ表示を速くするために、Cache(キャッシュ)=ファイルを一時的に保存する機能が備わっています。
ページを開くのが昔のダイヤル回線のように不自然なほど遅い場合には、先ず、このキャッシュがきちんと有効になっているかどうかを確認してください。

Magento2の管理画面 SYSTEM > Cache Management をクリックすると、Magento2のキャッシュシステムの操作ページが開きます。

Magento2 Cacheキャッシュ有効状態

上記のように、緑色の[ENABLED]という表示が並んでいる状態では、すべてのCacheキャッシュが有効化されています。

しかし、以下のように、赤色の[DISABLED]という表示が並んでいる状態では、Cacheキャッシュの一部(またはすべて)が無効化されているので、有効化に切り換える必要があります。

Magento2 Cacheキャッシュ無効状態

Cacheキャッシュを有効化するには、有効化するキャッシュにチェック✔️を入れて、左上プルダウンから[Enable]を選択して、[Submit](送信)をクリックします。

Magento2 Cacheキャッシュを有効に切り換える
Magento2 Cacheキャッシュを有効に切り換える

すると、以下のように緑色の[ENABLED]に切り換わり、フルページキャッシュが有効化されます。

Magento2 Cacheキャッシュを有効に切り換える

ただし、Magento2がProductionモードになっている時には、上記のプルダウンで[Enable]の選択肢がリストになく、管理画面からキャッシュを有効化することができません。(Magento2のモードについては、Magento2のモード変換と静的ファイルの展開についてをご参照ください。)
この場合は、Magento2のルートにSSHアクセスして、以下のコマンドラインで、キャッシュを有効化させます。

php bin/magento cache:enable

Cacheキャッシュの有効化は基本的なことなので、Magento2を使い慣れている人には当たり前のことなのですが、稀に、なんらかの事情で(特に、エクステンションをインストールしたりモードを変更したりした際のセットアップ後に)、Cacheキャッシュが勝手に無効化されてしまう場合があります。原因がよく分からないのですが、急激にサイトのスピードがダウンした時などは、フルページキャッシュが効いていない可能性が高いので、Cacheキャッシュの状態を確認してみてください。

3. CSSとJSファイルの最適化

次に、CSSとJSファイルを最適化します。CSSファイルとJavascriptのファイルを最小化することで、読み込みファイルの総量を軽量化することができます。

先ず、管理画面 STORES > Configuration > Advanced > Developer > JavaScript Settings / CSS Settings へ進みます。

CSSとJavascriptの最適化

それぞれの項目を、以下のように設定します。

JavaScript Settings
Merge JavaScript Files: Yes にします。JSファイルをマージ(結合)することで、軽量化します。
Enable JavaScript Bundling: No にします。バンドルをYesにすると効果的なケースもありますが、一般的にバンドルされたJSファイルが大きくなりすぎて逆効果になることが多く、推奨されていません。(ご参考: https://inchoo.net/magento-2/javascript-bundling-magento-2/
Minify JavaScript Files: Yes にします。JSファイルを最小化します。

CSS Settings
Merge CSS Files: Yes にします。CSSファイルをマージ(結合)することで、軽量化します。
Minify CSS Files: Yes にします。CSSファイルを最小化します。

設定をしたら、右上のオレンジ色の [Save Config] ボタンをクリックして保存します。
その後、SYSTEM > Cache Management に進み、[Flush Magento Cache]ボタンをクリックして、Magento2のキャッシュをクリアしてください。

4. HTMLファイルの最適化

次に、HTMLファイルを最適化します。HTMLファイルを最小化することで、読み込みファイルの総量を軽量化することができます。

上記2と同じページ内の、管理画面 STORES > Configuration > Advanced > Developer >Template Settings へ進みます。

HTMLファイルの最適化

以下のように設定します。

Template Settings
Minify HTML: Yes にします。HTMLファイルを最小化します。

設定をしたら、右上のオレンジ色の [Save Config] ボタンをクリックして保存します。
その後、SYSTEM > Cache Management に進み、[Flush Magento Cache]ボタンをクリックして、Magento2のキャッシュをクリアしてください。

CSS、JS、HTMLの最適化でのご注意

  • Magento2がproductionモードの場合、Advanced > Developer のパネルは管理画面からアクセスできません。いったんdeveloperモードに変更し、上記を設定したら、もう一度productionモードへ戻してください。その際に、6. Magento2をprudctionモードにする で紹介するコマンドの順で実行してください。
  • CSS、JS、HTMLの各ファイルの最適化では、CDNや他のキャッシュ系サービスとの共用でコードが衝突し、サイトのページが崩れたり、カート画面がブランクになってしまうケースが報告されています。設定後は、必ずサイトの表示を確認し、テスト注文も入れるようにしてください。もしトラブルが発生している場合は、先ずHTMLの最小化を無効にして、再確認をしてみてください。
  • productionモードに変更後、最適化が効いていないと思われる場合は、Apacheサーバーでは .htaccessファイルでの MAGE_MODEの値をproductionに、Nginxサーバーでは、nginx設定ファイル中のMAGE_MODEの値をproductionに変更してください。(ご参考: https://magento.stackexchange.com/questions/251861/magento-2-not-minifying-js-css-or-html-in-production-mode

5. Flat Catalogを有効化する

Magento2の商品データベースは、デフォルト状態では、Entity-Attribute-Value (EAV) というシステムを利用しています。
この状態だと、一つの商品に複数のattributes(属性)が結びついている場合、その商品ページを表示するために、Magento2は複数のデータベースのテーブルを参照しなければなりません。
しかし、Flat Catalogを有効にすることで、この複数のテーブルを一つにまとめることができます。そのぶん、商品ページの表示スピードが速くなります。

このFlat Catalogを有効化するためには、STORES > Configuration > CATALOG > Catalog > Storefront に進みます。
そして、画面をややスクロールして、Use Flat Catalog Category と、Use Flat Catalog Product の項目を見つけます。

Flat Catalogの有効化

右のUse system valueのボックスに入っているチェックマークを外して、それぞれの項目を、以下のように設定します。

Use Flat Catalog Category: Yes にします。
Use Flat Catalog Product: Yes にします。

設定をしたら、右上のオレンジ色の [Save Config] ボタンをクリックして保存します。
その後、SYSTEM > Cache Management に進み、[Flush Magento Cache]ボタンをクリックして、Magento2のキャッシュをクリアしてください。

すると、Magento2管理画面の上部に、以下のようなメッセージが表示されます。

indexが無効です

これは、Magento2のIndexに無効になっているものがあります、という意味で、Flat Catalogをインデックスする必要があるということです。

Magento2にCronが設定されていると、指定の時間帯でIndexerが動くので、このメッセージはしばらくして自動的に消えます。
Cronが設定されていない場合は、お使いの環境でCronを設定してください。Cronについては、Magento2 Cron(クロン)の設定方法の記事をご参照ください。

6. Magento2をproductionモードにする

Magento2には、「モード」があります。
インストール直後は、通常 defaultモードになっていて、これは、サイト構築の段階で最も推奨されるモードです。
しかし、サイト構築が完成し、いざ開店、本番環境への移行となりましたら、Magento2のモードを productionモードに変更してください。このproductiomモードの状態だと、/pub/フォルダ以下に静的ファイルが配置され、Magento2の表示速度が一番速くなります。
Magento2のモードについては、Magento2のモード変換と静的ファイルの展開についての記事をご参照ください。

Magento2をproductionモードに変更するには、管理画面からの操作ではなく、SSHアクセスのコマンド作業が必要になります。
productiomモードへの変更は、以下のコマンドを実行します。

php bin/magento deploy:mode:set production --skip-compilation
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
php bin/magento setup:static-content:deploy ja_JP #日本語ストアがある場合

7. 使用していないエクステンションを無効化する

Magento2には、デフォルト状態で、サードパティーのエクステンションが同梱されています。名前をあげると、Dotmailer、Amazon、Klarna、Vertex などです。
これからのサービスは、本来、Magento2のコアコードとは関係なく、利用する人だけが任意でインストールすべきエクステンション(モジュール)になります。使用していない場合は、モジュールを無効化することで、Magento2への負担を多少でも減らすことができます。

ご参考:
https://www.yireo.com/blog/2018-05-23-disabling-annoying-3rd-party-magento-modules
https://www.integer-net.com/make-magento-2-small-again/

エクステンション(モジュール)の状態を確認したり、無効化するには、以下のコマンドを実行してください。

# Magento2コア以外のエクステンションリストを見る
php bin/magento module:status | grep -v Magento_

# エクステンション無効化の例
php bin/magento module:disable Klarna_Core Klarna_Ordermanagement Klarna_Kp
php bin/magento module:disable Amazon_Core Amazon_Login Amazon_Payment
php bin/magento module:disable Dotdigitalgroup_Email
php bin/magento module:disable Temando_Shipping
php bin/magento module:disable Vertex_Tax

# セットアップ
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento setup:static-content:deploy
php bin/magento cache:clean
php bin/magento cache:flush

8.サーバースペックを確認する

Magento2では、なるべく高スペックのサーバーで運営することが必要と言われています。
では、どのくらいのスペックならいいのか、ということですが、Magentoの公式ドキュメントに、推奨環境が説明されています。

Upgrading the Magento applications and extensions you obtain from Magento Marketplaces and other sources can require up to 2GB of RAM. If you are using a system with less than 2GB of RAM, we recommend you create a swap file; otherwise, your upgrade might fail.
https://devdocs.magento.com/guides/v2.3/install-gde/system-requirements-tech.html

上記の引用は、メモリの説明で、2GBを推奨値としています。

しかし、2GB以下はダメかというと決してそういうわけでもなく、メモリ2GB以下の環境では、Marketplaceからのアップデートやエクステンションのダウンロードをうまく進めるために、swap(スワップファイル)を作成してください、と注記しています。逆に言うと、スワップファイル/領域を作成すれば、2GB以下のメモリでも、なんとか凌ぐことができると解釈できます。
さらに言うと、Setup WizardやComposerを使用しない通常稼働の状態では、2GBメモリ以下(1GBなど)でも問題ない、ということにもなります。

swap(スワップ)は、共用サーバーでは作成できない環境が多いので、最小メモリでMagento2にトライするには、VPSの環境が一番ふさわしいかもしれません。

ただ、これはテスト環境やサイト構築時、開店当初の段階での推奨値なので、ストアの商品数やアクセス数の増加により、必要とされるスペックも変わってくることにご注意ください。

また、Magento2バージョンとPHP、MySQLの各バージョンの整合、PHPのエクステンション(OPcacheなど)が正しくインストールされて機能しているかも、上記リンクを参照しながら確認してください。

9. Webサーバーの構成を見直す

Magento2を動かすWebサーバーとしては、Apache(アパッチ)サーバーか、Nginx(エンジンエックス)サーバーか、大きく二つの選択肢があります。

例えば、日本のMagento第一人者、Veriteworksの西氏がさくらのナレッジで公開されているチュートリアルでは、Apacheサーバーをベースにすべてが説明されています。
https://knowledge.sakura.ad.jp/serialization/use-magento/

大変優れたチュートリアルで、学ぶことが多いのですが、Apacheサーバーでは、特に本番環境において、Varnishというキャッシュを導入することが強く推奨されます。実際、上記「Magentoを本格的に運用する」の記事の中でも「Varnishは不可欠」と明言されています。
Apacheサーバーを選ぶ場合、本番環境では、Varnishを入れることが必須と考えたほうがいいでしょう。

ただし、オープンソースのVarnishは、SSL(HTTPS)接続をサポートしていません。
そのため、SSL terminationとして、別途プロキシを設定する必要があります。海外のMagento2ユーザーでは、そのプロキシに、Nginxを採用するのが一般的となっています。

Apache+Varnish+Nginx(SSL)はアーキテクチャが複雑になり、設定が難しく、しかもメモリ消費が激しくなると言われています。Varnish単独で別サーバーを用意するか、同居の場合は、高スペックのサーバーを利用することになります。

Magento2サーバーApacheかNginxか

一方、はじめからNginxサーバーを選択する方法もあります。
この場合、Nginx+PHP-FMP(FastCGI)の組み合わせになり、設定も比較的容易で、パフォーマンスも良好です。Apache+Varnishと比べると、その半分のメモリで運用しても問題ないという報告があります。

スタートアップの小〜中規模のストア構築で、コマンドラインの作業に抵抗がない方は、VPSにNginxサーバーでMagento2を構築するのが、最もコストパフォーマンスのいい選択になるのではないか、と私は考えています。

また、必要になれば、NginxにもVarnishを入れることができます。Nginxをサーバーとしてもプロキシとしても設定できるので、Apache+Varnishの構成と比べるとアーキテクチャの複雑さが緩和され、メンテナンスの負担も軽くなると言われています。
商品点数が数万以上で、1,000人以上が同時にアクセスするような大規模サイトでは、Varnishを入れて足腰を強くすることが、サイトパフォーマンスの維持に有力な対処方法となります。

ただし、Nginxにも欠点があります。
現在、Magento2をNginxサーバーでホストすると、管理画面のSetup Wizardが利用できない(表示されない)というバグが報告されており、今後いつ修復されるか、はっきりと分からない状況です。SetupWizardを利用する方は、Nginxでの運用はいましばらく様子見をしたほうがいいかもしれません。
ご参考: https://magento.stackexchange.com/questions/222345/magento-2-2-2-web-setup-wizard-not-visible-in-backend

  • Apache+Varnish
  • Nginx+PHP-FMP(FastCGI)

Magento2をこのどちらのサーバー構成で運用するのがいいかは、古くから(笑)いろいろと議論されており、結局は、運用者が使いやすほうを選べばいいのではないか、と言われています。
ご参考:https://magento.stackexchange.com/questions/175438/nginx-or-apache-for-magento-2-x

ちなみに、Magentoサーバーでご紹介しているSiteGroundは、Apacheベースの共用サーバーになります。
SiteGroundでVarnishを設定することはできないのですが、SiteGround特製のNginxプロキシによるキャッシュシステムや、CloudflareのCDNとの連携、また、バックエンドにMemcacheなどを簡単に導入することができます。さらに、Cloudプラン(cPanelつき)では、HHVMを設定することも可能です。
本格運用にどこまで耐えられるかと言われると疑問は残りますが、海外サーバーの場合、コマンド作業の苦手な人でもcPanelからの直感的操作のみでMagento2サイトの外部環境を構成することができます。初心者の方は1〜2年くらい共用サーバーで修行をしてMagento2に慣れ、それからVPSへという流れがステップ的に無理のない選択になるのではないかと思います。

10. Redis、GZIP、HTTP/2、その他

その他、必ず導入したほうがいいものとして、Redisがあります。
Redisとは何か、ときちんと説明するのは難しいのですが、ここでは簡単に、Magento2のセッションデータをディスクに格納し、Magento2のパフォーマンスをバックエンドで改善してくれるツール、データベースのキャッシュシステム、と理解してください。
Redisはオープンソースで、VPS環境で比較的容易に導入することができます。同様のシステムにMemcacheがありますが、RedisとMemcaheの併用は不可で、どちらか一つと言われれば、Redisを選ぶのが一般的です。

また、GZIPという、ファイル圧縮もサーバー側のファイルで設定でき、HTTP/2の設定も、ファイルの読み込みを速くする効果があります。RedisもGZIPもHTTP/2も、Apache、Nginxの両サーバー環境での設定が可能です。

その他、有料サービスになることが多いのですが、CDN(Content Delivery Network)やロードバランサーの導入も、Magento2のスピードアップに貢献します。

今回の記事は、特に後半が駆け足になってしまい、サーバー構成の一つひとつの詳細な設定方法を説明することはできないのですが、冒頭のスピードテストを繰り返しながら、それぞれの環境でベストなパフォーマンスになるよう、様々なツールやサービスを上手に組み合わせて、理想的なMagento2環境を構築してください。

Magento2.3管理画面の無料デモを公開!

By |2019-04-13T15:33:34+09:002019年1月26日|Categories: Magentoの設定, Magentoバージョン, Magentoテーマ|Tags: , , , |

1. Magento2系最新バージョンの管理画面デモ

以前よりリクエストのあったMagento2管理画面のデモを一般公開しました。
こちらのリンクより、Magento2 管理画面(Backend)のログイン画面にアクセスできます。管理画面の中に入るには、以下の画像のログイン情報をご利用ください。

Magento2 管理画面 無料デモ(こちらからログイン)>>

Magento2管理画面ログアウト

管理画面からログアウトをするには、画面右上のアカウントアイコンの▼マークをクリックすると、プルダウンが開きますので、そこから「Sign Out」をクリックしてください。

また、こちらの管理画面内で編集作業をすると、FrontendのMagento2デモLumaテーマの表のサイトに直接反映されますので、どうぞご留意ください。もちろん変更や編集をしていただいて構いませんが、次にアクセスされる方のために、できるだけ元に戻しておいていただけますと大変ありがたいです。
尚、一部機能には制限をさせていただいておりますので、どうぞご了承ください。
サイトのどこかに不具合があったり、レイアウトがガタガタに崩れていたりしましたら、お問い合わせよりご一報をいただくか、Magentoフォーラムにてご投稿いただけますと助かります。

Magento2管理画面

Backend(管理画面)

Magento2デモ Lumaテーマ

Frontend(表のサイト)

2019年1月現在、このデモサイトは、Magento2系の最新バージョン、2.3.0をインストールしています。画面のインターフェイスは、2.2系から大きく変化はしておらず、2.3系の目玉であるPWA Studio(PWAストア開発ツール)は本体に同梱はされていません。Page Builderについては、2.3.1バージョンから有料のCommerce版に先行搭載されています。
今後も公式のアップデートがありましたら、このデモサイトも随時アップデートをしていく予定です。(*)

Magento2がどんなものか興味がある、とりあえず管理画面を見てみたい、すこしだけ触ってみたい、そんなニーズにお応えするために、管理画面デモを公開しました。ぜひ実際にログインして、中を見て、Magento2がどんなものかをご確認ください。

2. Ultimoテーマのデモサイトアップデート

また、Magentoデモのページでもご案内しているUltimoテーマも、デモサイトを2.3系にアップデートしました。
マルチストアも、English、简体中文、繁体中文の、3ストアビューの構成に変更し、それぞれ異なるUltimoテンプレートをインポートしています。右上の言語スイッチャーからストアの切り換えができ、3つのサブドメインで表示されます。どのストアも、中身はほぼLumaテーマのサンプルサイトのままで、骨組のみを設定し、細かい部分は編集していません。
中国語ストアも、コンテンツは英語のままですので、言語ロケールをインストールすると、どの部分が翻訳に反映されのるか一目瞭然になっております。

Magento2 Ultimoテーマデモ English
Magento2 Ultimoテーマデモ English(公開終了)
Magento2 Ultimoテーマデモ 中国語(簡体字)
Magento2 Ultimoテーマデモ 中国語・簡体字(公開終了)
Magento2 Ultimoテーマデモ 中国語(繁体字)
Magento2 Ultimoテーマデモ 中国語・繁体字(公開終了)

今回のデモサイトのアップデートで、Magento1.9系のMadison Islandサンプルテーマは公開を終了させていただきました。
また、Magentoテーマにてご紹介している、FastestテーマやClaueテーマも、デモサイトは公開終了としました。Portoテーマにつきましては、機会を見て、最新バージョンのデモサイトを設定し直す予定です。

Magento定番Ultimoテーマを購入する(英語)

追記(2019年2月25日):
Portoテーマの新しいデモサイト(Magento2.3)も公開しました。Magentoデモにてご確認ください。

* 追記(2019年3月29日):
LumaテーマとUltimoテーマのデモサイトを、2.3.0→2.3.1にアップデートいたしました。

追記(2019年4月13日):
UltimoテーマとPortoテーマのデモサイトは、公開を終了とさせていただきました。

Magento2.3リリース!PWAを実装した新しいMagento

By |2019-03-09T08:40:03+09:002018年11月25日|Categories: Magentoの設定, Magentoバージョン|Tags: , , , , |

1. Magento2.3.0リリース

先日、Magentoの公式ブログにて、Magento2.3.oバージョンが、2018年11月28日にリリースされると公表されました。来年1月〜3月くらいにずれこむことも噂されましたが、当初の予想通り、2018年秋-冬にリリースとなりました。

今回の2.3系は極めて重要なアップデートで、これによってMagento2は、新しいECサイトのスタンダードを実現した、と言っていいくらいのインパクトを持つのではないかと思います。

Magento2.3リリース

同日には、Magento2.2系以下のアップデートもリリースされます。
すでにMagento2.2系で運営されている方は、当面は2.2の最新バージョンへのアップデートをして、2.3.0はデモでさわることが推奨されます。来春以降には2.3.1、2.3.2、と修正がされてくるでしょうから、そのあたりでライブ環境へのテストをしてみるのがスケジュール的にはいいかもしれません。

今回の2.3で新しく実装されるものとしては、PWA(Progressive Web Application)と、Page Builder の大きく二つの機能があります。特にPWAに関しては、多くのEC事業者が待ち望んでいた革新的なものになると思います。

2、Magento PWA – ECストアのモバイルアプリ化

PWAは、一言で言えば、ECサイトのモバイルアプリ化機能です。

本当は「アプリ」ではないのですが、PWAの実装により、ユーザーがモバイル環境で、MagentoのECサイトを「まるでアプリのように」利用することができるようになります。サイト(PWA)のアイコンがスマートフォンのホーム画面に設置でき、ストア内のローディングもブラウザより速く、プッシュ通知機能や一部オフラインでの稼働も可能となります。
PWAで集客してストアへ誘導するというわけではなく、PWAがストアになっているので、PWA内でユーザーからのご注文が完結します。

元々PWA(Progressive Web Application)は、Googleが2015年頃から開発していたオープンソースの技術で、Magento社はそれを導入し、Magento PWA Studioという、MagentoのコアとなるモジュールとしてGitHub上で開発してきました。そして、このPWAは、GraphQLという言語をサポートする2.3系から、Magento2本体機能に実装される事になりました。

スマートフォンが普及し、ユーザーからのアクセスがスマホからが主流となるここ数年の流れの中で、ECサイトの運営者は、コンバージョンの低下に悩んできました。PCサイトからのコンバージョンが平均3%とすると、スマホからのコンバージョンは(レスポンシブにしていても)1%程度と言われています。
一方、ユーザーのモバイルアプリの利用時間が飛躍的に伸び、大手ECプラットフォームのモバイルアプリからのコンバージョンは、5-6%と高い数字が報告されています。

しかし、自社サイトをモバイルアプリ化するのはコストが高く、また実際にアプリをリリースするにはApp StoreやGoogle Playストアの審査を経なければならないので、小規模の事業者にとってはハードルが高く感じられてきました。

PWAは、そのようなEC事業者の悩みを解決する革新的な技術です。
つまり、Magento2でECストアを構築すれば、ブラウザで閲覧されるサイトに加えて、それがそのままアプリのような外見で、まるでアプリのような感覚で、ユーザーの手元のスマートフォンでも動いてくれるのです。PWAがコンバージョンの上昇にプラスに働くのは必至と考えられます。

ただ、アプリストアからのダウンロードという形での集客はできないので、あくまでサイト来訪者にPWAアイコンをアプリ風に設置してもらうことが導線となります。そこがネックといえばネックですが、通常のエンドユーザーにとっては、一度端末にPWAがインストールされれば、それがネイティブアプリなのかPWA(Webアプリ)なのかで大きな違いはなく、それよりもスマートフォンで実際に快適に利用できるかどうかがポイントになります。

このスマホ全盛時代においては、ECストアのモバイル経験をより良くし、多様化、洗練化させていく方向に対応していくしかありません。ですので、すでにストアをアプリ化した事業者にとっても、PWAは有力なツールといえるので、今後、ECストアの形態として一般的なものになっていくと思われます。

Googleの技術ということもあり、将来的には、サイトがPWA化しているかどうかが、SEOのアルゴリズムにも加味されるようになる可能性もあります。

3、Page Builder – 直感的デザインツール

Page Builderは、Magento管理画面内での直感的なデザインツールです。

同種のものは、サードパーティのベンダーからもいつくか出ていましたが、今回、Magento本体にもオフィシャルに導入されることになりました。
これにより、コードが分からないサイト運営者も、クリックとマウスドラッグとテキスト入力だけで、ある程度自由にページデザインをすることができるようになりそうです。

正直、 Magento2のレイアウト設計は複雑です。
classがテーマのxmlファイルで組み込まれていたり、デフォルトのLumaのものだったり、管理画面のwidgetから任意で組み込むこともできたり、また、それらがCMSで編集できるとしても、どのCMS Blockに紐づけられているかを、ビジュアルで確認することができません。なので、「ここをこう変更したい」と思っても、どこを編集すれば反映されるのか、あるいはコードをいじらなければ変更ができないのかが、サイトのインターフェイスを見ているだけでは分からないのです。

このPage Builderの導入により、管理画面から直感的にページデザインを組むことができるようになるので、レイアウトの複雑さが改善され、Magento2を初めてさわる人にはとても便利なものになると期待されます。
(もちろん、従来のCMS編集がベースになっているので、Page Builderは無効にしておくこともできると思います。)

4、Magento2.3系からが、本当のMagento2(になりそう)

上記のPWAとPage Builder以外に、Magento2.3の新しい特徴としては、PHP7.2のサポート、非同期APIリクエスト対応、Elasticsearch対応、複数在庫元管理の対応、WYSIWYGのアップグレードなど、大きな変更があります。
また、Google ReCAPTCHAや管理画面ログインでの二段階認証の標準装備など、セキュリティ機能面での向上もあります。

昨年の12月には、Magento2は本当に使えるのか?などという(ちょっと挑発的な題で)記事を書きましたが、1年が経ち、ついにMagento2は、本物のMagento2になりつつあるという感を抱いています。

特に、PWAの実装は、今後のECサイトのあり方を決定づける、エポックメイキング的なものとなるかもしれません。
具体的な仕様は、実際にMagento2.3をさわってから、また後日このブログにてご報告させていただければと思います。

追記(2019年3月9日):
PWAもPage Builderも、3月中にリリースされる2.3.1バージョンからの実装となりそうです。
PWAは、Magento2の既存テーマのシステムとは違い、ReactというJavaScriptによって、デザインを一から作成しなければなりません。つまり、管理画面でPWA設定を有効にすればすぐにMagento2のストアがPWA化されるというわけでもなく、PWAストアのための新しい開発や作り込みが必要となります。なので、開発のためのツールがMagento2に導入される、という風に理解したほうがいいかもしれません。PWAの作り込みがどこまで簡単になるか(非開発者でも作業できるようになるか)は、いまのところ何とも言えません。
VeniaというPWAのサンプルストアが、Magentoの開発チームにより公開されています。スマートフォーンでアクセスをするか、Chromeでスマホ画面表示でご確認ください。


Magento2 PWAサンプルストア Venia
https://veniapwa.com/

Magento2とMailgun(SMTP/外部メールサーバー)の連携

By |2019-06-23T11:50:01+09:002018年10月19日|Categories: Magentoの設定, Magento2エクステンション|Tags: , , |

1. Magento2のメール送信について

Magento2によるサイト構築においては、はじめの設定で、そのメール送信についても気を配らなければなりません。
ECサイトは、ユーザーからの受注があると、一般的に注文完了メールを自動で送信します。つづいて、手動の確認メール、発送メール、フォローメール等々と、そのプラットフォームから、ユーザーにメール送信をする機能が備わっています。

Magento2にも、もちろんメール送信機能は備わっています。しかし、はじめてMagentoでサイト構築をする人にとって、このECサイトにとって当たり前とも言えるメール送信の設定は、決して簡単な作業ではありません。Magentoは多機能なのですが、皮肉なことに、ECの基本機能ほど、その設定がややこしく、面倒くさいのです。

Magentoサーバーで紹介しているSiteGroundであれば、cPanelからMXレコードを設定し、ストアの独自ドメインでメールアドレスを作成することができます。あとは、そのアドレスをMagento2の管理画面にて送信元として入力・登録すれば、とりあえずのメール送信はできることになります。
ところが、この場合、cPanel内でドメイン認証などの対策を行っても、送信したメールが迷惑メールのフォルダに入ってしまったり、途中でスパムとしてはじかれてしまったりすることがあるので、到達率の面でやや問題があるといえます。

そこで、この記事では、サーバー内のPHPのmail関数に依存するのではなく、外部のメールサーバー(SMTP)を利用して、Magento2のためのメールアドレスを設定する方法をご紹介いたします。これは、テスト環境やサイト構築中の段階では特に必要な作業ではありません。しかし、ライブ環境への移行前、ストア開店前までには、外部サーバーによりメール送信のできる環境を整えるのが、より信頼性のある、無難な選択肢となります。

メール配信サービスとしては、G Suite、Amazon SES、SendGrindなどが有名ですが、今回は、Mailgunという無料~で使えるサービスをご紹介したいと思います。個人的には、今のところ、このMailgunが(ネーミングはちょっと物騒なのですが)、Magento2との相性が一番いいように感じています。

Mailgunは、英語からの申し込みページしかないのですが、設定が比較的簡単で、同じクレジットカードで複数の無料アカウントを作成することができるので、サイトを複数運営している場合でも汎用性があり、とても便利です。

以下は、通常の受信/送信にはcPanelで設定したメールサーバを使うことを前提に、MailgunはMagento2からの送信専用サーバーとして設定する方法の説明になります。(cPanelからのメールアドレスの作成については、SiteGround Email Tutorialsをご参照ください。)

尚、cPanelのないクラウドやVPS環境でMagentoを構築する場合、サーバー内でメールホスティングまで管理するのは大変な作業になるので、Zohoメールなどをご検討いただいてもいいかもしれません。
G Suiteと類似したサービス内容ですが、Zohoには独自ドメインを利用できる無料プランがあり、モバイルアプリも安定していて高機能です。また、検索すると日本語での解説も多いので、気軽にはじめることができます。
ZohoとMailgunで完全無料のメールホスティングを構築することができるので、特に新規でサイトを立てる際にはおすすめの組み合わせになります。

Mailgunに登録する前に、Mailgunで使用するメールアドレスを、cPanelやZohoのサービスから予め作成し、送受信ができるようにしておいてください。Mailgunの登録は、Mailgunのプラットフォームから新規でメールアドレスを作成するというわけではなく、あくまで既存のメールアドレスに対して、Mailgunという外部の送信サーバーを利用できる環境を追加する、というイメージになります。

2. Mailgunの申し込みと認証について

MailgunのConceptというプランが、Pay As You Go(使った分だけの支払い)で、毎月10,000通までのメール送信が、無料となります。また、毎月100件まで、送信先のメールアドレスがアクティブなホンモノのアドレスかどうかを無料でチェックすることもできます。これは、ValidationというAPIを利用するサービスで、SMTPの送信設定だけではこの機能は作動しないので、無料枠をこえる心配はありません。

Mailgun価格

https://www.mailgun.com/pricing-simple
Conceptプランの[Sing up]のボタンをクリックして、申し込みページに進みます。

Mailgun申し込み

上記のように入力し、右下のプランが「Concept – Pay As You Go」になっているのを再確認し、[Create Account]のボタンをクリックします。
(画面の中央あたりの「Add payment info now」のチェックマークをはずすと、クレジットカードの情報を入力しなくてもアカウントを作成することはできますが、その場合は受信専用のアカウントになり、メールの送信機能が使えなくなってしまうので、ご注意ください。)

Mailgunメール認証

アカウント作成直後に、メールアドレスの認証メールが送信されます。
Mailgunのダッシュボードにも、サイト上の黄色の背景バーに「認証メールを送信しました」というメッセージが表示されています。メールボックスをチェックして、「Hi 名前, Please verify your Mailgun account」という件名のメールを開いてください。
そのメールの中にあるリンクをクリックすると、メールアドレスの認証は完了で、つづいて、ショートメール(SMS)による本人認証画面が自動で立ちあがります。

Mailgunの認証SMS

国は日本が自動で選択されていますので、お持ちの携帯電話番号を入力し、[Send Verification Code]をクリックしてください。
Mailgunは、同じクレジットカードで複数のアカウントを作成できますが、このSMSの認証では、短期間に複数の認証を同じ携帯番号で行おうとすると、エラーになるケースもあるようです。その場合は、別の携帯番号、ご家族やご友人、同僚の方の番号をご入力ください。(SMSによる認証はこの初回のみです。)

[Send Verification Code]をクリックすると、コード入力画面に切り替わりますので、届いたSMSの文面の中にある6ケタの数字を入力してください。
そうすると、アカウントの認証は完了で、ダッシュボードの画面上のバーも緑色に色が変わります。これで、Mailgunのアカウントがアクティブになりました。

Mailgunのアカウント認証

つづいて、ドメインの設定作業に移ります。
上記ダッシュボードの画面をスクロールすると、以下のような Add Your Domain という大きなボードがあります。

Mailgunにドメイン追加

[Add Your Domain Now]のボタンをクリックすると、以下のようなドメイン追加のフォームページが開きます。

Mailgunにサブドメイン追加

画像の字がやや小さいのですが、「サブドメインでの設定を推奨します」ということが書かれています。
これはどういうことかと言うと、使用するメールアドレスが you@mydomain.com の場合は、ここで mydomain.com を入力するのではなく、mydomain.com のサブドメイン、例えば mg.mydomain.com の入力を推奨しています。おそらく、メインドメインのゾーンでMXレコードを重複しないためということだと思います。
サブドメインでMialgunを設定しても、メインドメインのメールアドレスで送信することができますので、ご安心ください。

Mailgunのメールサーバを利用できるようにするために、お使いのDNSプロバイダーの管理画面にて、任意のサブドメインを設定してください。事例では、mg.mydomain.comですが、これは、mail.mydomain.comでも、mailgun.mydomain.comでも、自分に分かりやすいものであれば、自由な任意のスペリングで構いません。
サブドメインの設定の仕方は、それぞれご利用中のサーバー、もしくはDNSプロバイダーのドキュメントをご参照してください。

サブドメインが作成できたら、そのサブドメインをフォームに入力し、[Add Domain]ボタンをクリックします。
すると、次のようにDNS情報を追加してくださいという指示の画面が開きます。

MailgunのDNSの設定

画像の字が小さいのですが、まとめると以下の表の内容となります。
DNSでの作業方法については、お使いのサーバー、DNSプロバイダーの説明をご参照ください。

SiteGround(cPanel)でのDNSとMXの編集とについては、以下のページをご参照ください。
https://www.siteground.com/tutorials/cpanel/dns-zone-editors/
https://www.siteground.com/tutorials/email/mx-record/
また、Mailgunのヘルプページの解説もご参考ください。
https://help.mailgun.com/hc/en-us/articles/202052074-How-do-I-verify-my-domain-

Type Host Name Value
TXT mg.mydomain.com v=spf1 include:mailgun.org ~all
TXT mailo._domainkey.mg.mydomain.com k=rsa; abcdefghijklmno(暗号化)pqrstuvwxyz1234567890…..
CNAME email.mg.mydomain.com mailgun.org
Type Priority Value
MX 10 mxa.mailgun.org
MX 10 mxb.mailgun.org

mg.mydomain.comの部分は、自分のサブドメインに置き換えて考えてください。暗号化されているような文字列については、Mailgunダッシュボードからコピペしてください。
DNSの入力画面の画像は(プロバイダーによりまちまちなので)省略させていただきますが、入力後しばらくすると、Mailgunのドメイン情報のページが、以下のように黄色や赤色のアイコンが表示され、反映待ちの状態となります。

MailgunのDNS反映待ち

しばらく待ったら、手動で[Check DNS Records Now]のボタンをクリックしてみます。
DNSが設定され、ネットワークに浸透が進んでいれば、黄色や赤色のアイコンが、以下のように緑色に変わります。
24時間~48時間という待ち時間の記載もありますが、実際には早ければ数分で反映されます。

MailgunのDNS反映

DNSチェックのアイコンが緑色に変わった後、ドメインの認証までに更にもうしばらく(10分~くらい)時間がかかります。
ドメイン(サブドメイン)が認証されると、Domain InformationのStatusが、 未承認の黄色マークから、Activeの緑色のマークに変わります。

Mailgunドメイン認証済

これで、Mailgun側での設定が完了したことになります。

3. Magento 2 SMTPエクステンションのインストールと設定

つづいて、Magento2 にてMailgunのSMTPを設定します。これは、SMTP連携のエクステンションを利用します。
Magento2のSMTPエクステンションで無料のものは、以下の二つが有名です。

Mageplaza https://github.com/mageplaza/magento-2-smtp
Magepal https://github.com/magepal/magento2-gmail-smtp-app

どちらでもいいのですが、今回は上のリンク先のMageplazaのエクステンションをComposerでインストールします。
同じエクステンションについて、Mageplazaのサイトでも設定方法が説明されているので、ご参考ください。
https://www.mageplaza.com/blog/how-to-configure-mailgun-smtp-in-magento-2.html

Composerによる作業については、Magento2日本語、またMagento2アップデートのページにて、Composerを使った作業動画を解説していますので、ご参照ください。SSHアクセスをして、基本的なコマンドを入力する作業自体は大きく変わりません。
以下が、今回のMageplazaのSMTPエクステンションをインストールする際のコマンドになります。

Magento2のルートへ移動
cd [Magentoルートへのパス]

メンテナンスモードへ
php bin/magento maintenance:enable

Composerインストール(※必要な場合のみ)
curl -sS https://getcomposer.org/installer | php
php composer.phar

Magentoのキャッシュクリアと既存の生成ファイル削除
php bin/magento cache:clean
php bin/magento cache:flush
rm -rf pub/static/*
rm -rf var/di/* var/generation/* var/cache/* var/log/* var/page_cache/* var/view_preprocessed/pub/*
rm -rf generated/code/* generated/metadata/*

SMTPエクステンションのインストール(ダウンロード)
php composer.phar require mageplaza/module-smtp

Magentoアップデート
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento indexer:reindex
php bin/magento cache:clean
php bin/magento cache:flush

メンテナンスモード解除
php bin/magento maintenance:disable

コマンドについては、Magento2コマンド集もご参照ください。
※Composerのインストールコマンドについては、すでにその環境にComposerがインストールされている場合は不要です。

エクステンションのインストール後、Magento2の管理画面にアクセスすると、以下のようにMageplazaのエクステンションの設定画面が入っています。
STORES > Configuration > Mageplaza Extensions > SMTP で設定画面を開いてください。

Magento2 SMTPエクステンション

先ずは、General Congifuration > Enable Mageplaza SMTP を、プルダウンで Yes に変えてください。(インストール直後は、No になっています。)
つづいて、SMTP Configuration Options > Host の入力欄のすぐ横にある[Load Settings]のボタンをクリックしてください。これにより、既成のプロバイダーのデフォルト値を自動で入力することができます。以下のように、画面全体にスライドするようにSMTPプロバイダーのリストが表示されます。

Magento2 SMTPエクステンション

リストの中から Mailgun をクリックしてください。
すると、下記のように Mailgunのデフォルトの設定値が表示されますので、[Load Settings]のボタンをクリックしてください。

Magento2 SMTPエクステンション

すると、スライドのリスト画面が閉じ、以下のようにMailgunの設定値が入力されます。
Host: smtp.mailgun.org、Port: 587、 Protocol: TLS になっていることを確認してください。(Load Settingを使わずに手動でこう入力しても構いません。)

Magento2 SMTPエクステンション

つづいて、それ以外の空欄になっている Username や Password の入力ですが、これは、先ほど Mialgunのサイトで登録したドメイン認証情報のページから該当のワードをコピペします。

MailgunドメインのSMTP情報

上の画像の Default SMTP Login が管理画面に入力するUsernameDefault Password が管理画面に入力するPasswordになります。
(尚、MailgunのAPIを利用したほうがメール送信は速くなるのですが、Magento2とMailgunのAPI連携エクステンションが開発されていないため、既存のエクステンションで可能なSMTPでの連携を行っています。)

Mageplaza Mailgun SMTPの入力

上の画像のように、先ず Authentication をプルダウンで、LOGIN に変更してください。それから、Mailgunのページからのコピペで、UsernamePasswordを入力してください。

ここで入力内容を保存してもいいのですが、このまま同じ画面内から、メール送信が正しくできるかどうかをテストすることができます。
下の Send Test Emailのタブを開くと、下のようなメール送信テストの入力画面が開きます。
Send to の欄に、任意の(受信可能な)メールアドレスを入力し、[Test Now]のボタンをくりっくしてください。

Mailgun SMTPテストメール送信

以下のように、Success というダイアログが表示されれば、テストメールの送信は成功で、MailgunのSMTPがMagento2と連携できたことになります。
実際に、メールボックスにMageplazaのテストメールが届いていることを確認してください。

Mailgun SMTPテストメール送信成功

テストメールの送受信が確認できたら、管理画面右上のオレンジ色の[Save Config]ボタンでいままでの入力内容を保存しください。
そして、System > Cache Management から、Magento2のキャッシュをクリアしてください。

尚、もし今回Magento2にてはじめてメールアドレスを設定する場合には、このMageplazaのエクステンション設定の他に、管理画面内の基本的なメール設定も必要になります。
以下の設定ページでの入力を完了後に、テストメールの送信を試してみてください。

  • Stores > Configration > General > Store Email AddressSender Emailに、Magento2ストアのメールアドレス(例:you@mydomain.com)を入力してください。五個所ありますが、少人数でのストア運営の場合は、原則としてすべて同じメールアドレスを入力します。
  • Stores > Configuration > Sales > Sales EmailsSend Order Email Copy To に、Magento2ストアのメールアドレスを入力してください。ここも同様の入力欄がいつくかありますが、少人数運営の場合、原則としてすべて同じメールアドレスを入力します。受注処理メールのBccが届くようになります。
  • Stores > Configration > General > Contacts > Email OptionsSend Emails Toに、Magento2ストアのメールアドレスを入力してください。サイトからのお問い合わせの内容が届くようになります。

メールテンプレートの編集等については、また別の機会に記事にしたいと思います。

以上、Magento2と外部メールサーバーMailgun(SMTP)の連携方法について説明いたしました。

(追記)エクステンションのアンインストール方法

今回のブログ記事でインストールをした、MageplazaのMagento2 SMTPエクステンションを、アンインストールする方法をご紹介いたします。万一不具合が起きた時や、他のSMTPエクステンションを試したい時にご参照ください。

Composerを使ってインストールをしたエクステンションは、Composerを使ってアンインストールする必要があります。
管理画面で、Enable Mageplaza SMTPDisable(無効)にしてから、SSHで以下のコマンドを実行してください。

ポイントは、エクステンションの名称が2種類あって、Magento2に対して指示する名称は、Vendor_Moduleのように頭文字大文字にアンダースコアが使われ、Composerに対して指示する名称は、vendor/moduleのように、小文字スラッシュが使われる点です。
Composerに対する名称はインストール時と同じものですが、Magento2に対する名称が分からない場合は、php bin/magento module:status というコマンドで、モジュール名のリストを見ることで判明します。

Magento2のルートへ移動
cd [Magentoルートへのパス]

メンテナンスモードへ
php bin/magento maintenance:enable

Magentoのキャッシュクリアと既存の生成ファイル削除
php bin/magento cache:clean
php bin/magento cache:flush
rm -rf pub/static/*
rm -rf var/di/* var/generation/* var/cache/* var/log/* var/page_cache/* var/view_preprocessed/pub/*
rm -rf generated/code/* generated/metadata/*

SMTPエクステンションの無効化
php bin/magento module:disable Mageplaza_Core Mageplaza_Smtp --clear-static-content

SMTPエクステンションのアンインストール(*データベース削除)
php bin/magento module:uninstall -r Mageplaza_Core Mageplaza_Smtp

SMTPエクステンションのComposerからの削除
php composer.phar remove mageplaza/module-smtp
php composer.phar remove mageplaza/module-core

Magentoアップデート
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento indexer:reindex
php bin/magento cache:clean
php bin/magento cache:flush

メンテナンスモード解除
php bin/magento maintenance:disable

(* )データベースの削除も行うと、それまでのデータが完全に消去されますのでご注意ください。
いったんアンインストールして、後日また再インストールする場合は、データベースの削除をするコマンドは実行せず、とばしてください。再インストール後に、以前のデータが読み込まれます。

追記(2019年6月1日):
Mailgunのダッシュボードのレイアウトが、この記事の画像とはやや変更になっていますが、基本的な設定方法は同じです。

Magento2のアップデート方法(動画の解説)

By |2019-01-19T14:16:11+09:002018年7月18日|Categories: Magentoの設定, Magentoバージョン|Tags: , , |

動画:Magento2.2.2 → 2.2.5へ Composerでアップデート

Magentoのアップデート全般については、Magento2アップデートをご参照ください。
また、アップデート前には、必ずバックアップをとるようにしてください。

1. Magento2のマイナーアップデートについて

先日2018年6月末にMagento2.2.5がリリースされたので、一週間ほどの検討後、2.2.3から2.2.5へのアップデートを行いました。
前バージョンの2.2.4はネットでの評判が良くなかったので、事実上スキップしました。2.2.5では、2.2.4で投入されたバグの大部分が修正されているようです。

私がMagento1からMagento2へ移行したのは、2017年の末、Magento2.2.1バージョンの時で、以後、2.2.1 → 2.2.2 → 2.2.3 → 2.2.5 とアップデートをしてきました。このように、2.2.x の x の部分の数字でのアップデートを、一般的に、Magento2の「マイナーアップデート」と呼びます。上の動画では、Composerを使い、Magento2.2.2から2.2.5へマイナーアップデートをしています。

基本的に最新バージョンを使うべきと思ってはいますが、実際のライブ環境でアップデートを実行すべきかどうかは、導入しているテーマやエクステンションの対応状況を見て、また、そのバージョンの評判なども念入りにチェックし、自分なりのタイミングを慎重に探るべきと考えています。
セキュリティ的には最新バージョンのリスクが一番小さいのかもしれませんが、アップデートの作業そのものに決して小さくはないリスクがあるので、そのバランスの見極めが大切になります。一般論ではなく、各自、自分のサイトの現実的な事情から最適な判断をしていく必要があるのだろうと思います。

2. Magento2アップデートのコマンド一覧

前置きが長くなりましたが、以下、ComposerによるMagento2のアップデート動画で入力したコマンドの一覧です。
コマンドは、すべてMagento2のルートディレクトリ(Magento2のインストールされている階層)で実行します。動画では、cd public_html/demo とMagento2のルートに移動しています。ご自身の環境により、ファイルパスは置き換えてください。

バージョン確認
php bin/magento --version

メンテナンスモードへ
php bin/magento maintenance:enable

Composerインストール(必要な場合)
curl -sS https://getcomposer.org/installer | php
php composer.phar

Magentoのキャッシュクリアと既存の生成ファイル削除
php bin/magento cache:clean
php bin/magento cache:flush
rm -rf pub/static/*
rm -rf var/di/* var/generation/* var/cache/* var/log/* var/page_cache/* var/view_preprocessed/pub/*
rm -rf generated/code/* generated/metadata/*

Composerのキャッシュクリア
php composer.phar clear-cache

Magentoアップデート
php composer.phar require magento/product-community-edition 2.2.5 --no-update
php composer.phar update
php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento indexer:reindex
php bin/magento cache:clean
php bin/magento cache:flush

メンテナンスモード解除
php bin/magento maintenance:disable

上記コマンドは、冒頭がすべて php になっています。
しかし、動画では、php71 と入力しています。これは動画内の作業環境のデフォルトのphpがphp5.6バージョンなので、別にphp7.1のバイナリを指定しているためです。通常の共用サーバーでは、php のみのコマンドが一般的なので、この解説記事でも便宜的に php で表記しております。例えば、php71 bin/magento --version は、php bin/magento --version になります。
また、VPSやクラウドなどroot権限のある環境では、php ではなく、sudo コマンドの使用が一般的です。例えば、php bin/magento --version は、sudo bin/magento --version となります。さらに、同環境でComposerをグローバルにインストールしている場合、例えば、php composer.phar update は、sudo composer update となります。
コマンドの冒頭は、ご自身の環境により適宜読み替え/置き換えてください。ご不明な点は、先ずはお使いのサーバー会社にお問い合わせされることをおすすめいたします。

尚、コマンド作業がはじめての方は、先ずは「SSHアクセス」や「PuTTY 使い方」「ターミナル 使い方」などのワードで検索をし、コマンドラインの基本をおさえてください。日本語で検索して、わかりやすいサイトがたくさんヒットします。

それでは、各コマンドについて簡単な説明をいたします。

バージョン確認
php bin/magento --version
これは、文字通りMagento2のバージョンを確認するためのコマンドです。ご自身のMagento2のバージョンを確認するためには、Magento2の管理画面の右下にバージョン数が表示されているので、それを見ると分かります。ですので、アップデートのために、あえてこのコマンドを実行する必要はありません。今回はこの動画のために、アップデートの前後に確認の意味で実行しています。

メンテナンスモードへ
php bin/magento maintenance:enable
このコマンドで、Magento2をメンテナンスモードに切り替えることができます。ユーザーからのサイトへのアクセスは遮断されるので、本番環境の場合は事前にアナウンスをしておいてください。

Composerインストール(必要な場合)
curl -sS https://getcomposer.org/installer | php
php composer.phar
Composerが入っていない場合、このコマンドでComposerを新しくインストールしてください。Composerの有無については、次節の説明をご参照ください。
尚、二つ目のコマンドはインストールが正しくされたかどうかを確認するためのものなので、必ずしも必要なわけではありません。

Magentoのキャッシュクリアと既存の生成ファイル削除
php bin/magento cache:clean
php bin/magento cache:flush
rm -rf pub/static/*
rm -rf var/di/* var/generation/* var/cache/* var/log/* var/page_cache/* var/view_preprocessed/pub/*
rm -rf generated/code/* generated/metadata/*
上の二つのコマンドでMagento2のキャッシュをクリアします。また、rm ではじまるコマンドで、Magento2の pub/static var generated 以下のフォルダ内ファイルをすべて削除します。これにより、Magento2が生成している既存ファイルが消えるので、アップデート後に新しいファイルが自動生成されても、エラーとなりません。

Composerのキャッシュクリア
php composer.phar clear-cache
これは、すでにComposerの導入されている環境でMagento2をアップデートする際に必要となるコマンドです。Composerのキャッシュがサーバーに保存されていると、ダウンロード/インストールが正常に行われないケースが稀にあるので、念のため事前にキャッシュをクリアにしておきます。
このアップデート時にはじめてComposerをインストールする場合は、このComposerのキャッシュクリアは特に必要ではないので、とばしていただいても構いません。

Magentoアップデート
php composer.phar require magento/product-community-edition 2.2.5 --no-update
php composer.phar update
この二つのコマンドが、今回のアップデート動画のキモになります。
一つ目のコマンドで、composer.json ファイル内のMagento2のバージョン情報を、2.2.5 へ書き替えています。他のバージョンへのアップデートの際には、この数字を置き換えてください。--no-update というオプションは、文字通り「アップデートはしない」という意味で、アップデートのためのコマンドなのにアップデートしないようにさせているのは不思議なのですが、おそらく、ここで一息にMagentoをアップデートはさせず、つづく次のコマンドで、Composerで管理している他のライブラリと同時にアップデートをさせているのだろう、と私は理解しています。
動画で見ていただけるように、php composer.phar update のコマンド後に、新しいバージョンのライブラリが、vendor フォルダ以下にダウンロード/インストールされます。環境によってはダウンロードが開始するまで時間がかかることもありますので、そのままじっと待ってください。

php bin/magento setup:upgrade
php bin/magento setup:di:compile
php bin/magento indexer:reindex
php bin/magento cache:clean
php bin/magento cache:flush
上記のコマンドで、Magentoのデータベースの更新、コンパイル、indexの更新、キャッシュクリアを行っています。この一連のコマンドは、アップデート時に限らず、新しくエクステンションをインストールしたり、テーマをインストールしたりする際にも使う、Magento2の定番コマンドです。

メンテナンスモード解除
php bin/magento maintenance:disable
最後に、上記コマンドでメンテナンスモードを解除してください。

3. Composerのインストールについて

Composerでアップデートをするので、Composerが必要になります。
Magento2本体をインストールした時、はじめからComposerでMagento2をインストールしていれば、その環境にはすでにComposerが入っています。しかし、cPanelから1クリックでMagentoインストールしていたり、Zipファイルから手作業でインストールしていたりする場合は、アップデート前にComposerをインストールする必要があります。
今回の動画では、Composerのない環境でのアップデートを前提にしていますので、動画内でComposerのインストールも行っています。

共用サーバーをお使いで、ご自身の環境にComposerが入っているかどうか分からないという方は、FilezillaやFile Managerで、Magento2のルートからMagentoのファイル群をざっと見てください。
以下の画像のように、composer.json と composer.lock のファイルがあるのに、composer.phar というファイルが見当たらないのなら、その環境にComposerはインストールされていません。Composerがインストールされていなくても、composer.json と composer.lock の二つのファイルは(Magento2の本体ファイルに同梱されているので)元々存在します。Composerのインストールの有無は、composer.phar というファイルの有無でチェックしてください。

また、root権限のあるVPS等で、Compserがグローバルにインストールされているかどうかは、composer -v のコマンドで確認することができます。Composerがインストールされている環境であれば、Composerのバージョン情報が表示されます。

Composerインストール

4. Magento2のパーミッションについて

もう一点、アップデート前に確認しておくのは、パーミッションの設定です。
共用サーバーでMagento2をインストールしている際には、適切なパーミッションに自動で設定されているのが一般的ですが、VPSやクラウド環境では、ご自身でパーミッションを再確認する必要があります。
Magento2のパーミッションについては、公式ドキュメントFile systems access permissionsを見るのが一番信頼性が高いのですが、曖昧模糊とした表現で、これだけでは余計に混乱してしまうかもしれません。
具体的にどう設定すべきかについては、フォーラムサイトMagento 2 folder/file permissionsで論じられていますので、各自の環境にあわせてご参照ください。

ちなみに、パーミッションの設定が原因でアップデートに失敗すると、本来ダウンロード/インストールされるべきファイルがごっそり消失してしまうという事態に直面します。bin/magento のファイルも消えてしまうケースもあり、Magento2のすべてのコマンドが効かなくなります。つまり、サイトが壊れます。
この場合、応急処置としては、bin/magento ファイルをMagento2のオリジナルファイル群からコピー&アップロードをして、chmodコマンドで実行権限を与え、とりあえずコマンドラインだけは機能するように復旧します。その後、Magento2をいったん元のバージョンにダウングレードをして、すべてのフォルダ/ファイルを復活させます。そしてパーミッションの再チェックを行い、Composerのキャッシュをクリアします。
元のバージョンに戻すためには、ちょうどアップデートのコマンド php composer.phar require magento/product-community-edition 2.2.5 --no-update の部分のバージョン数を元のバージョン数 (例 2.2.2)に置き換えて実行してください。
道に迷ったら迷った地点まで戻るのが鉄則ですが、アップデートのトラブル時にも元に戻すのが王道になります。ただ、元に戻そうにも戻らないという状況もあり得ますので、そのような事態も想定し、バックアップは必ずとっておくようにしてください。

5. Magento2のモードについて

本番環境でMagento2がproductionモードになっている場合は、Magento2のアップデート前に、developerモードに変更をしてください。(*)
流れとしては、メンテナンスモードにした後、php bin/magento deploy:mode:set developer とdeveloperモード変更のコマンドを入力してください。そして、アップデート終了後(メンテナンスモード解除後)に、再度、php bin/magento deploy:mode:set production とproductionモードに戻してください。
Magento2のモードについては、Magento2のモード変換の記事をご参考にしてください。

(*)万一アップデートでエラーが発生すると、developerモードの場合、そのエラーメッセージがブラウザに表示されてしまうので、事前にテスト環境でアップデートが問題なくできることを確認してください。基本的にはdeveloperモードでのアップデートが推奨されますが、本番環境においては、念のためにproductionモードのままアップデートをしてもいいかもしれません。

Magento2アップデート

Magento2アップデート

Magento2の三つのアップデート方法、マイナーアップデートとメジャーアップデートの違い、アップデート前の準備や注意事項など、Magento2のアップデート全般について説明しています。

Magento2アップデート

Magento2の通貨設定と為替レート自動アップデートについて

By |2019-05-03T10:59:44+09:002018年6月10日|Categories: Magentoの設定|Tags: , , |

1. Magento2のベース決済通貨の設定について

Magento2では、商品価格の表示や決済回収となる通貨を複数設定することができます。
マルチストアにして、各ストアで別の通貨を設定することもできますし、シングルストアで複数の通貨を設定し、ストアに通貨切り換えスイッチを表示することもできます。また、マルチストアで、それぞれストアごとに違った通貨(一つでも複数でも)を設定することもできます。

ただ、決済のベースとなる通貨は、マルチストアの構成に関係するので、詳細はMagentoマルチストアもご参照ください。
決済ベースの通貨を基準に、任意の為替レートを手動で入力したり、APIで外部からレートを取り入れたり、またそのAPIにより自動でレートを更新したりすることができます。
さらに、支払い方法によっては、ベース通貨での決済が固定となるか、あるいは、ベース通貨での決済かストア上での表示通貨での決済か選択できるものもあります。

Magento2通貨設定

上の画像は、Magento公式ドキュメントから拝借したもので、Magento2における通貨設定のイメージになります。

ポイントとなるのは、base currency scope(決済ベース通貨の設定)を、global(default)の層で固定するか、websiteの層で固定するか、自由に選択ができる点です。

globalの層でベース通貨を設定すると、Magentoで構成するすべてのストア(すべてのwebsite > すべてのstore > すべてのstore view)の決済が、一つのベース通貨に固定され、商品の値付けは一つの通貨でしか行えません。もちろん、ストアに表示する通貨は多通貨を設定し、デフォルトの表示通貨を別の通貨にすることもできますが、商品価格の基準はベース通貨となります。
上の公式ドキュメントの画像では、globalでアメリカドルを設定している図と解釈できます。右下のstore viewは日本円表示ですが、websiteのベース通貨がアメリカドルなので、store viewの日本円は、ドル円の為替レートにより変動的に(もしくは固定レートで)表示されることになります。

一方、websiteの層でベース通貨を設定すると、websiteごとに決済ベース通貨を選ぶことができます。そのMagentoが二つのwebsiteを持つのなら、wesiteAはアメリカドル、websiteBは日本円というふうに、仮に同じ商品を販売するとしても、それぞれ別の通貨で値付けを行うことができます。それにより、為替レートの変動を気にすることなく、商品登録画面上から、直接日本円で商品価格を設定できます。
上の公式ドキュメントの画像でいうと、右側のwebsiteのベース通貨を日本円で設定し、その下層のstoreも日本円、store viewも日本円(+多通貨表示)というイメージになります。こうすることで、商品の値付けを日本円で行うことができます。

Magento2のベース通貨の設定

このbase currency scope(決済ベース通貨の設定)は、Magento2の管理画面 Stores > Configration > Catalog > Catalog > Price の Catalog Price Scope で設定します。
上記画像の欄で、プルダウンで、Global(default)か、Websiteか、自由に選択ができます。
Globalに(Magento全体に)ベース通貨を統一してしまうか、それとも、Websiteごとにベース通貨を設定するかが選択できるのです。

2. Magento2の多通貨の設定について

Magento2の管理画面で具体的に通貨を設定するには、上記の Base Currencyに加えて、Default Display Currency、Allowed Currencies と、合計三つの項目で通貨を選択します。
これは、以下の画像のように、管理画面 Stores >Configration > General > Currency Setup の Currency Options で設定をいたします。

Magento2での多通貨の設定

Base Currencyは、上記でも説明いたしましたように、Magento2での決済ベースとなる通貨です。
Catalog Price Scopeを「Global」にしている場合は、Magento2のDefaultの層でのみ設定できます。Catalog Price Scopeを「Website」にしている場合は、Magento2に構成している各Websiteの層でそれぞれ設定できます。

Default Display Currecnyは、そのストアのデフォルトで表示する通貨で、各Store viewの層で設定ができます。
例えば、WebsiteのBase Currencyが日本円であったとしても、そのStore viewのDefault Display Currencyがアメリカドルであれば、ユーザーがそのストアにアクセスすると、商品価格はアメリカドルで表示されます。商品の値付けは日本円ですが、為替レートにより計算されたアメリカドルの価格がストアに表示されます。

Allowed Currenciesは、そのストアで表示のできる通貨リストのすべてで、複数を選択することができます。画面で複数通貨を選択する際には、キーボードの「Ctrl」(Macの場合は「command」キー)を押しながら選択すると、選択された通貨がすべてブルーで反転して、同時に設定できます。
一般的に、Allowed Currenciesで複数通貨を設定すると、ストアのヘッダー部に通貨スイッチャーが表示され、ユーザーが任意で表示通貨を切り換えることができるようになります。
例えば、WebsiteのBase Currencyが日本円で、Default Display Currencyがアメリカドル、そしてAllowed Currenciesに日本円、アメリカドル、ユーロが設定されていると、ユーザーがアクセスすると、商品価格はアメリカドルで表示されます。しかし、ユーザーは通貨スイッチャーにより、商品価格を日本円かユーロに切り換えることができます。その際、表示される日本円価格は、ストア運営者が商品の値付けを行った日本円と同じ価格になります。アメリカドルとユーロの表示価格は、為替レートにより計算された価格となります。

マルチストア構成で、Store viewにより異なる通貨を設定、表示させる場合には、下の画像のように、管理画面左上のStore viewの切り換えスコープで該当のストアを選択し、それぞれ設定をいたします。マルチストアの場合、Store viewの切り換えで、そのストアに適用される管理画面が開きますので、ストアごとにそれぞれ設定を分けることができます。これは通貨設定に関わらず、他の設定でも同じ仕様です。

Magento2 Store viewの切り換え設定

また、通貨の設定で注意していただくことは、Allowed Currenciesの選択リストには、Base CurrencyとDefault Currencyが含まれている必要があるということです。
例えば、Base Currencyがアメリカドルで、Default Currencyにイギリスポンドを選ぼうとしても、Allowed Currencyの項目で「イギリスポンド」を選択してないと、Default Currencyの保存でエラーになってしまいます。なので、先ずはAllowed Currencyに「イギリスポンド」を追加し、その後にDefault Currencyで「イギリスポンド」を設定する流れになります。

Magento2の通貨スイッチャー

上記は、Magentoデモ・事例でご紹介しているZENVAVAというサイトですが、ヘッダーの右上に通貨スイッチャーがあります。
このサイトは、WebsiteでBase Currencyをアメリカドルで設定し、Store viewでDefault Display Currencyもそのままアメリカドルにし、Allowed Currenciesで、AUD(オーストラリアドル)、GBP(イギリスポンド)、CAD(カナダドル)、EUR(ユーロ)、USD(アメリカドル)を設定しています。

インストールしているデザインテーマによって、スイッチャーの位置は違いがありますが、おおよそ上記のイメージになります。マウスオーバーすると、通貨リストのプルダウンが現われます。
また、有料/無料のエクステンション(Geo IP等の名称)を入れると、ユーザーのアクセスしたIPアドレスからユーザーの滞在国/地域を特定し、該当通貨を自動でデフォルト表示させることもできるようになります。エクステンションの導入については、Magentoエクステンションもご参照ください。

2. Magento2の通貨レート自動アップデート方法

Magento2には、デフォルトで、三つの通貨レートプロバイダーとの連携モジュールが入っています。Yahoo financeとWebservicex、そしてFixer.ioです。
APIで通貨レートをワンクリックで取り込んだり、時間を決めて自動でレート更新を行うことができるようになっています。

ところが、この連携モジュール、三つもあるのですが、2018年6月現在、Magento2のプラットフォームできちんと動作するものがありません。
唯一、Fixer.ioは動いていたのですが、先日の6月5日に、Fixerで大きなシステム変更があり、無料プランではEuroベースの為替レートしか取り込むことができなくなってしまいました。
現在、Fixer.ioの月額10ドルのプランを購入すると、すべてのベース通貨でのレートを読み込むことができるようになります。

ただ、この状況がずっと続くのは考えづらいので、いずれ近いうちに、安定的に為替レートをインポートできる無料サービスが、またMagento2で簡単に使えるようになるのではないかと思います。

Free currency converter fixer.io stopped working
https://magento.stackexchange.com/questions/228588/free-currency-converter-fixer-io-stopped-working

例えば、上記のMagentoフォーラムのページでは、有志の開発者が無料で新しい自作モジュールを公開しています。
これを自分でフォルダに整理し、app/code/以下に手作業でアップロードすれば、通常のエクステンションのマニュアルインストールと同じ要領で、無料の為替レートモジュールをMagento2に入れることができます。
(実際にご利用される場合は、テスト環境で試していただき、自己責任にてお使いください。私も試しましたが、きちんと動作しています。)

このように、Magentoコミュニティで自然発生的に生まれる解決策が、様々な検証の後、Magentoのコアコードに(そのままではないにしても)採用されるようになることもあります。(*)

Magento2通貨レート取り込み

この通貨レート取り込みツールは、上記画像のように、管理画面 Stores > Configration > General > Currency Setup の Scheduled Import Settings で設定をいたします。

画像では、コミュニティで公開されている無料モジュール(Free Currency Converter)を選択しています。
レートの更新スケジュールは、時刻と、頻度(毎日/毎週/毎月)の二項目で設定することができます。ここで設定する時刻は、Magento2にとっての時刻で、それは、Stores > Configration > General >General > Locale Options > Timezone で指定されたタイムゾーンの時刻になります。

Magento2通貨レート

自動更新スケジュールで取り込んだ通貨レートは、上記画像のように、Stores > Currency Rates で確認をすることができます。
また、自動更新を使わず、この画面から手作業で最新のレートをインポートすることもできます。その場合は、Import Serviceで、APIツールを選び、下の[Import]ボタンをクリックし、右上のオレンジ色の[Save Currency Rates]をクリックすると、新しい通貨レートを保存、適用することができます。
あるいは、ツールを使わずに、この画面上で手作業で直接にレートを入力し、保存することも可能です。自社の固定レートを採用する際にも、ここでレートを入力したり、変更したりすることができます。

以上、Magento2での通貨の設定についてご説明いたしました。

追記(2019年5月3日):
Free Currency Converter APIは、Magento2.3よりデフォルトで連携モジュールが搭載されるようになりましたが、2019年2月末頃より、APIキーの設定が必須となり、現在、通貨レートの読み込みができない状況になっています。時期Magento2.3.2では、修正が施される可能性があります。
https://github.com/magento/magento2/pull/22461
https://github.com/magento/magento2/issues/21487

Magento2のモード変換と静的ファイルの展開について

By |2018-04-09T18:24:58+09:002018年3月23日|Categories: Magentoの設定|Tags: , , |

1. Magento2のモードについて

Magento2には、defaultモード、developerモード、productionモードの、三つのモードがあります。

Magento2にモードがある? 三つのモード? と言われても、そんなことは寝耳に水だ、というかたもいるかもしれません。私自身、Magento2に「モード」があることは、Magento2をいじりはじめてから数カ月後に知りました。それまでは、Magento2に三つのモードが存在することなどまったく知らずに作業をしていました。

何をきっかけに「モード」の存在に気づいたのかというと、それは、ある日突然に、ということでもなく、なにかトラブルにぶつかって検索していると、’developer mode’ ‘production mode’ という言葉をよく見かけていたので、Magento2にはそういう「モード」というものがあるらしい、程度の認識はあったのだと思います。

いま最も鮮明に憶えているのは、defaultモードからdeveloperモードに変換した後、もう一度defaultモードに戻ることができなかったことです。defaultモードは、文字通り、デフォルトの状態でのみ可能なモードで、一度別のモードに変換すると、再びdefaultモードには戻せない、という、この事実を知った時は(大げさですが)衝撃的でした。

Why can’t one switch back to the default mode on Magento 2?
https://magento.stackexchange.com/questions/112523/why-cant-one-switch-back-to-the-default-mode-on-magento-2

上記のフォーラムでも、「defaultモードは、Magento2のインストール時のみで、一度モードを変換すると、もうdefaultモードには戻れない。戻る必要もないし、戻る方法もない」のようなことが書かれています。

つまり、cPanelからMagento2をインストールしたり、ComposerでMagento2をインストールしたり、あるいはファイルから手動でインストールしたり、そのインストールしたフレッシュな状態のMagento2は、おしなべてdefaultモードで、はじめてMagento2に触れる場合は、たいていはそのdefaultモードのままサイト構築の作り込みをしているのです。

話しが前後しましたが、私もやはりdefaultモードでサイト構築を進めていました。
Magento2には ‘developer mode’ や ‘production mode’ という「モード」があるらしいという認識は頭の片隅にありましたが、自分の作業しているMagento2がいまどのモード下なのかということに関しては、サイトの表示されないエラーに直面し、どうにも修復できない行き詰りの状況になるまで、きちんと確かめていませんでした。

Magento2が壊れた時、developerモードであれば、ブラウザにエラーログも表示され、バグの解消作業がやりやすい、と一般に言われています。
なので、私も、当面のエラー修復のヒントを得るために、Magento2をdeveloperモードに変換しようとしました。そして、その時になって、ふと「いま、一体なんのモードなんだろう」と、当たり前のような疑問を、ようやく実際に確かめることになったのです。

Magento2のモードを確認するには、二つの方法があり、一つは、/app/etc/env.php のファイルの中の、‘MAGE_MODE’ => ‘default’ で判明します。
もう一つの方法は、Magento2のルートで以下のコマンドを打ちます。

php bin/magento deploy:mode:show

そうすると、default / developer / production いずれかの回答が返ってきます。
その時、私に返ってきた答えは ‘default mode’ で、これで、私ははじめてdefaultモード(インストール時のデフォルト状態)の存在を知りました。

Magento2モード変更のコマンド

‘developer mode’ が「開発環境モード」で、 ‘production mode’が「製品モード(本番環境モード)」だろうことは容易に想像できます。それぞれのモードへは、以下のコマンドで変換することができます。

php bin/magento deploy:mode:set developer
php bin/magento deploy:mode:set production

モードの転換ができると、Enabled developer mode. のようなメッセージが表示されます。
ただし、先述したように、php bin/magento deploy:mode:set default と打っても、default modeに切り換えることはできません。上記の画像でも、Cannot switch into given mode “default” とエラーが出ています。一度defaultモードを離れたら、原則として、後はdeveloperモードで構築をつづけ、本番環境への移行時に、productionモードに変換することになります。

問題は、このモード変換が、Magento2の管理画面からの操作では不可能だということです。
Magento2系は「モード」を備え、あたかもユーザーの利便性を向上させたかのように見えますが、一般の運営者にとっては、この「モード」の存在は、単に面倒が増えただけとも言えます。車で言えば、ギアチェンジをするのに、わざわざボンネットを開けねばならないような使い勝手の悪さです。
ちょっと愚痴っぽくなってしまうのですが、この一点を見るだけでも(意図的なのかMagento社のリソース不足なのかは不明ですが)、いかに現行のMagento2が、運営者の視点を切り落としてリリースされているかが分かります。

もちろん、defaulモードのまま構築し、defaultモードのまま本番環境に移行することはできます。できますが、実際にdefaultモードのままでは(特に本番環境では)マイナス面が大きいと言えます。
次に、defaultモード、developerモード、productionモード、それぞれのモードの特徴を見てみます。

2. defaultモード/developerモード/productionモード

公式ドキュメントのAbout Magento modesにそれぞれのモードの説明があるので、簡単にまとめたいと思います。

defaultモード

  • 静的ファイルのキャッシュが有効になる。
  • 例外(エラー)メッセージは、ブラウザに表示されず、/var/reports/ のlogファイルに書き込まれる。
  • header内のカスタムX-Magento-*のhttpリクエストとその反応は隠れる。

developerモード

  • 静的ファイルのキャッシュが無効になる。
  • Verboseログが提供される。
  • 自動コードコンパイラが有効になる。
  • /var/reports/ 内のエラーリポートが詳細化し、エラーメッセージがブラウザにも表示される。
  • header内のカスタムX-Magento-*のhttpリクエストとその反応を表示する。
  • サイト全体のパフォーマンスは遅くなる。

productionモード

  • 例外(エラー)メッセージは、ブラウザに表示されず、/var/reports/ のlogファイルに書き込まれる。
  • 静的ファイルのキャッシュが有効になる(キャッシュのみになる)。
  • 自動コードコンパイラが無効になる。新しくアップデートされたファイルがシステムに書き込まれない。
  • Magento管理画面で、キャッシュの「有効/無効」の選択肢がなくなる。

また、前項で触れた Why can’t one switch back to the default mode on Magento 2? のページの画像を参照して、わかりやすい表にしてみます。

Magento2のモードの違い
機能 defaultモード developerモード productionモード
ブラウザでのエラー表示
自動コード生成
クラス定義 reflectionベース reflectionベース 事前コンパイル
静的ファイルのマテリアライズ シンボリックリンク 事前コンパイル
Configファイルの有効化
自動テーマ登録

ここで説明されていることは、正直、かなり難しいと感じる内容で、私もよく理解できていない項目もあるのですが、重要な点としては、各モードにより、Magento2の静的ファイル(Static View Files)の生成方法が違う、そのマテリアライズ(静的ファイルのMagntoファイルシステムへの書き込み)も違う、ということが挙げられます。
これはサイトの表示速度にも影響し、実際のファイル構造にも大きく関わることなので、Magento2でサイトを構築/運営するのなら、必ず押さえておくべきポイントになります。個人的には、defaultモードはサード、developerモードはセカンド、productionモードはトップ、というように、マニュアル車のギアチェンジを想像するとイメージが摑みやすいのではないかと思います。

また、developerモードは構築開発にふさわしい状態ですが、ブラウザからのアクセスにより、その度ごとに /pub/static/ 以下に静的ファイルのシムリンクが生成されているので、サイトのパフォーマンスが極端に低下します。なので、大きなバグやエラーに悩むことがないのであれば、defaultモードのまま構築作業を進め、本番環境への移行時に、直接、defaultモードからproductionモードへ切り換える手順をとっても、特に問題はないと思われます。

3. Magento2の静的ファイル(Static Files)の生成展開について

Magento2は、PHPという動的なプログラムで書かれていますが、ブラウザでの表示速度を最適化するために、画像やCSS、JSなどのファイルを、静的ファイルとして生成展開し、キャッシュする機能を備えています。そして、その展開されるファイル群は、/pub/static/ 以下のフォルダに配置されます。
静的ファイルの展開方法や、キャッシュの有無は、各モードにより、以下のような違いがあります。

defaultモード

  • SSHでのコマンドを実行しなくても、ブラウザからのリクエストによりファイル展開される。
  • /pub/static 以下の静的ファイルは、マテリアライズ化され、キャッシュされる。
  • 画像、CSSなどの編集後は、Static Fileのキャッシュをクリアしないと、変更が反映されない。

developerモード

  • SSHでのコマンドを実行しなくても、ブラウザからのリクエストによりファイル展開される。
  • /pub/static/ 以下の静的ファイルは、キャッシュされず、リクエストの度ごとにシムリンクが生成される。
  • 原則として、静的ファイルのキャッシュをクリアしなくても、変更が反映される。

productionモード

  • php bin/magento setup:static-content:deploy により、事前にファイル展開をする必要がある。
  • /pub/static/ 以下の静的ファイルは、オリジナルソースへの直接リンクにより生成される。
  • 画像、CSSなどの編集後は、php bin/magento setup:static-content:deploy のコマンドを実行しないと変更が反映されない。

default、developer、production と、モードによるファイルの生成の違いは、やや分かりづらい面があるのですが、developer が自動生成、productionは事前展開、defaultはその真ん中くらい、と、おおざっぱに摑んでおいてもいいのではないか、と私は思います。厳密には(defaultについては)間違いかもしれませんが、サイト運営者にとっては、何より、本番環境への移行局面が重要になるので、developerモードとproductionモードの違いは、必ず意識しておいてください。

各モードのファイル展開の違いについては、公式ドキュメントよりも、Which compilation commands are needed in developer mode and when? で明解に論じられていますので、詳しく調べたい場合には、こちらを土台にしてみてください。

重要なポイントは、本番のproductionモードにおいては、カスタマイズCSSの追加など、静的ファイルに変更があるような編集を行った後は、PuTTYなどでSSHアクセスをして、php bin/magento setup:static-content:deploy のコマンドで、ファイル展開を逐次行わないといけないという点です。defaultやdeveloperモードにおいては、静的ファイルをコマンドで展開させる必要はありません。しかし、productionモードに変換した後に、この展開コマンドを実行しないと、フロントのサイトに変更内容が反映されないのです。

英語以外の言語ロケールをインストールしている場合には、言語ロケール毎に展開コマンドの実行が必要になります。例えば、日本語ストアの静的ファイルを展開させるには、php bin/magento setup:static-content:deploy ja_JP を実行します。通常の展開コマンドの半角あとに、言語ロケールのコードを入力するかたちになります。言語ロケールについては、Magento多言語化のページ、もしくは、Magento2の日本語化の記事もご参照ください。

また、php bin/magento deploy:mode:set production のコマンドにより、はじめてMagento2をproductionモードに変更する際には、自動でファイル展開が行われます。しばらく時間がかかることが多いので、画面を見守っていてください。

productionモードに転換すると、サイト表示速度が、体感でも速くなったのが分かります。一方で、/pub/static/ 以下に、Magento2のすべての静的ファイルが言語ロケール毎に配置されるので、サーバーのディスク使用量が急激に上昇します。特に、マルチストア構成にしている場合、また、CMSページ数や画像数が多い場合は、この点もご留意ください。

Magento2 Cron(クロン)の設定方法

By |2018-03-21T12:17:16+09:002018年3月16日|Categories: Magentoの設定, SiteGroundについて|Tags: , , |

1. Cronとは

前回のMagento2日本語化の記事では、Composerを使ったインストール方法を紹介いたしました。Composerは、Magentoの初心者にとってとっつきにくい、分かったような分からないような躓きの要因の一つですが、Magento2では、このComposerと並んで、もう一つ、Cron(クロン)というものも、なかなか面倒な存在です。

例えば、Magento2を苦労してようやっとインストールした直後、管理画面にアクセスすると、以下の画像のようなメッセージで迎えられることがあります。

Magento2 Indexer Invalid エラー Cronが動いていない

One or more indexers are invalid. Make sure your Magento cron job is running.「一つ以上のIndexが無効です。MagentoのCronが動いているか確認してください」という意味で、まだCronが設定されていないことを伝えています。「invalid」という不穏な響きの言葉のせいで、インストール直後の喜びが台無しになります。(というか、なりました。私は。)

Cron(クロン)というのは、UNIX系のコンピュータで、時間ごとにスケジュールを決めて動作するプログラムのことです。ギリシャ語のChronos(時間)を語源にしているようです。
Magento2では、多くの機能をCronに依存するシステム構成になっており、Cronがないと作動しない重要な機能としては、以下のものがあります。

  • Magento2からのメール送信(注文確認や発送完了メールなど)
  • Reindexing – 商品やカテゴリなど変更データのアップデート/フロントへの反映
  • 商品価格ルールの変更
  • ニュースレターの配信
  • ユーザーへの通知(価格変更や在庫数のお知らせメール)
  • 為替レートの自動更新
  • Googleサイトマップxmlの生成

このリストをざっと見るだけでも、Cronが設定されていないと、Magento2がECプラットフォームとしてはきちんと機能してくれないことが分かります。

Magento1.9系においても、Cronの設定は必要でしたが、ここまで大きな役割を持つことはありませんでした。Indexについても、Magento1では、管理画面からクリックするだけで手動でReindexを行うことができました。ところが、Magento2においては、Cronが動いていないとindexerも動かないので、新規で商品やカテゴリを登録すると、キャッシュのクリアだけではデータが更新されず、フロントに反映されないという事態にぶつかります。

冒頭のindexerのエラーメッセージはこの状態へのアラームなのですが、とりあえずindexエラーを解消するだけであれば、SSHアクセスでMagento2のルートへ移動し、reindexコマンドを実行することで解決できます。

cd [magento-root-path]
php bin/magento  indexer:reindex

上記でindexerが動き、管理画面 System>Index Managementの赤いエラーバーも緑色に変化します。

しかし、Cronが動くようにならないとMagento2のシステムは不完全なままなので、本番環境への移行前には、必ずCronを設定し、Cronがきちんと動いていることを確認する必要があります。

実は、Magentoのための海外サーバーで紹介しているSiteGroundでは、1クリックでMagentoをインストールすると、Magento2のためのCronコマンドが自動でサーバー側に設定されます。バージョンやプランによりそのままでは使えないのですが、基本コマンドは設定されるので、インストールの後に、PHPバイナリーやスケジュールの修正を、cPaneからl編集することになります。
SiteGroundをご利用されている方は、次項の、cPanelでのCron設定方法を参照してください。

Cronの設定については、cPanelのある環境か、または、VPSやクラウドなどcPanelのない環境かによって、大きく二つの方法があります。
以下、順にそれぞれの方法についてご説明いたします。

2. cPanelでのCronの設定方法

cPanelとは、サーバー管理上の様々な操作を、画面上から直観的に行うことができるコントロールパネル(管理画面)のことで、海外サーバーで多く採用されています。
先述したように、Magentoサーバーで紹介しているSiteGroundにもcPanelが標準インストールされていて、1クリックでのMagentoインストール時に、サーバー側に自動でCronコマンドも設定されます。

設定されたCronの内容を確認したり修正編集したりするには、cPanelの「Cron Jobs」アイコンをクリックします。

cPanel の Cron Jobs アイコン

Magento2をcPanel(Softaculous)からインストールした後に、Cron Jobsの画面に入ると、以下のように、Magento2のCronが設定されているのを確認できます。

cPanel の Cron 設定

画像上部のAdd a New Cron Jobは、新しいCronを設定する際に入力する欄で、下部のCurrent Cron Jobsに、現在設定されているCronの一覧が表示されます。

Magento2は、一般に3つのCronを設定します。基本的な設定コマンドについては、公式ドキュメントConfigure and run cronの案内によると、以下のようになります。

* * * * * [path to php binary] [magento install dir]/bin/magento cron:run | grep -v “Ran jobs by schedule” >> [magento install dir]/var/log/magento.cron.log
* * * * * [path to php binary] [magento install dir]/update/cron.php >> [magento install dir]/var/log/update.cron.log
* * * * * [path to php binary] [magento install dir]/bin/magento setup:cron:run >> [magento install dir]/var/log/setup.cron.log

また、同案内の2.2バージョン以降の説明では、以下のような実例をあげています。

* * * * * /usr/bin/php /var/www/html/magento2/bin/magento cron:run 2>&1 | grep -v Ran jobs by schedule >> /var/www/html/magento2/var/log/magento.cron.log
* * * * * /usr/bin/php /var/www/html/magento2/update/cron.php >> /var/www/html/magento2/var/log/update.cron.log
* * * * * /usr/bin/php /var/www/html/magento2/bin/magento setup:cron:run >> /var/www/html/magento2/var/log/setup.cron.log

冒頭に並んだ五つのアスタリスク * の部分は、時間帯ごとのスケジュールを意味していて、順に、

Minute(0 – 59)・Hour(0 – 23)・Day of Month(1 – 31)・Month(1 – 12)・Day of Week(0 -6)

のタームを表示しています。
Day of Weekの数値は、0から6まで曜日順に振り、0が日曜日を指します。

また、アスタリスクの * は、毎分、毎時間、毎日、のように、そのタームでの連続実行の意味になり、上記のように * が五つ並んでいると、スケジュールは「毎分」として設定されます。
スケジュールの配列は、カンマ(,)により併記するルールもあり、例示を見たほうが分かりやすいと思います。

* * * * *   毎分(1分間に1回)実行する
*/5 * * * *  5分間に1回実行する
0,30 * * * *   0分と30分に(1時間に2回)実行する
0 0 * * *     0時0分に(1日に1回)実行する
30 15 * * *     15時30分に(1日に1回)実行する
0 0,12 * * *    0時0分と12時0分に(1日に2回)実行する
0 0 1 * *         毎月1日の0時0分に(1カ月に1回)実行する
0 0 1 1 *         毎年1月1日の0時0分に(1年間に1回)実行する
0 0 * * 0        毎週日曜日の0時0分に(1週間に1回)実行する
15,45 12 * * 4     毎週木曜日の12時15分と12時45分に(1週間に2回)実行する
0,15,30,45 * * * * 毎時間の0分、15分、30分、45分に(1時間に4回)実行する

ぱっと見ると難しそうなのですが、タームの順をおさえれば書き方のルールはシンプルです。また、cPanelからの操作では、いくつかの一般的なスケジュールは、プルダウンの選択肢から選んで設定することもできます。

cPanelからのCronスケジュールの追加

Magento2のCronでよく使われるスケジュールは、* * * * *(毎分)や、*/5 * * * *(5分に1回)などになります。
もちろん、プルダウンからだけでなく、*/15 * * * *(15分に1回)など、手動で任意の数値を入力することもできます。
また、スケジュールやコマンドの修正は、Current Cron Jobs(設定済みCronリスト)の右側にある edit をクリックすると、手動で入力、変更することができます。

気をつけておくことは、Cronタスクは、サーバーへの負荷がかなり大きく、サーバー会社によっては、短いインターバルでのCron設定ができないケースや、あるいは、まったくCronの設定ができないサーバーもあります。
注文メールの送信などにも関わるCronタスクなので、安定した運営を重視するなら、毎分(* * * * *)でCron設定のできるサービスへの移転を検討してみてもいいかもしれません。

2-1. PHPバイナリーを確認する

次に、Cronコマンドで注意するのは、PHPバイナリーです。PHPバイナリーというのは、Magento2をインストールしたサーバーでの、PHPファイルの配置された場所を示しています。
スケジュールの数値の後に、半角空けて、PHPバイナリーのパスを記入します。2.2の公式ドキュメントでは、例として、/usr/bin/php が使われています。これは、一般的なApacheサーバーでのパスになるのですが、あくまでも例なので、これをそっくりそのまま記述しても、Cronがきちんと動作してくれるとは限りません。
先ずは、自分の環境で、PHPバイナリーがどこにあるのかを確認しなければなりません。

PHPバイナリーを確認する方法はいくつかありますが、最も確実なのは、PuTTYなどでSSHアクセスをして、Magentoのルートから、以下のコマンドを実行します。

which php

そうすると、例えば、/usr/bin/php もしくは、/usr/local/bin/php などのように、PHPバイナリーのパスを端的に返答してくれます。通常は、これをそのままCronコマンドに記述します。

しかし、このサイトでも紹介している海外MagentoサーバーのSiteGroundのように、サーバーアカウント内で、ディレクトリによりデフォルトとは違うPHPバージョンを適用させている場合は、そのバージョンでのPHPバイナリーを記述する必要があります。

今回、上記画像のケースは、PHP7.1バージョンを適用させたディレクトリに、Magento2.2.3を1クリックインストールしています。実は、アカウントのデフォルトではPHP5.6バージョンなのですが、Magento2.2以降、PHP5.6のサポートが外れたので、インストール前に、あらかじめ該当ディレクトリにPHP7.1を適用させているのです。
そこで、PHP7.1のバイナリーのパスを確認するために、PuTTYで、次のようにコマンドを打ちます。

which php71

そすると、(このSiteGroundサーバーの環境では)、/usr/local/bin/php71 と、回答があります。これが、Cronに入れるべき正しいPHPバイナリーになります。

Cron PHPバイナリーの変更

SiteGroundのcPanelから1クリックでMagentoインストールをすると、上の三つのCronが自動設定されているので、右側の edit をクリックして、各Cronのスケジュールと、PHPバイナリ(コマンドの冒頭部分)を修正します。

先ず、スケジュールに関して言うと、はじめの段階で、

9,27,40,52 * * * *
8,16,40,49 * * * *
8,24,30,59 * * * *

Minuteのタームにランダムな数値が設定されています。
これは、cPanelからのインストール時に、三つのCronに任意の実行時間(1時間に4回ずつ)を与えています。例えば、一番上のCronは、各時間の9分、27分、40分、52分と、1時間に4回ずつ実行するという意味です。
三つのCronで分の時間がずれているのは、サーバーへの負荷を少しでも分散するためなのかもしれませんが、いずれにせよ、1時間に4回ずつというルールの下で、ランダムに設定されていると考えていいでしょう。
このスケジュール数値を、以下のように、Minute に並んでいる数字を削除し、かわりにアスタリスク * を入力して、毎分実行のスケジュールに変更します。

* * * * *
* * * * *
* * * * *

そして、次に、PHPバイナリーの変更です。
1クリックインストールでは、三つのCronそれぞれに、php というバイナリーが設定されています。しかし、先述したように、今回の事例では実際のPHPバイナリーは、/usr/local/bin/php71 なので、以下のようにコマンド冒頭のバイナリーを変更し、三つのCronを変更します。

* * * * * /usr/local/bin/php71 /home/アカウント名/public_html/dekirumonn.com/demo/update/cron.php >> /home/アカウント名/public_html/dekirumonn.com/demo/var/log/update.cron.log
* * * * * /usr/local/bin/php71 /home/アカウント名/public_html/dekirumonn.com/demo/bin/magento setup:cron:run >> /home/アカウント名/public_html/dekirumonn.com/demo/var/log/setup.cron.log
* * * * * /usr/local/bin/php71 /home/アカウント名/public_html/dekirumonn.com/demo/bin/magento cron:run | grep -v “Ran jobs by schedule” >> /home/アカウント名/public_html/dekirumonn.com/demo/var/log/magento.cron.log

もし、Magento2を、SiteGroundサーバーアカウントの公開フォルダ直下にインストールしているなら、Magento2のルートパスの部分は以下のようになります。

* * * * * /usr/local/bin/php71 /home/アカウント名/public_html/update/cron.php >> /home/アカウント名/public_html/var/log/update.cron.log
* * * * * /usr/local/bin/php71 /home/アカウント名/public_html/bin/magento setup:cron:run >> /home/アカウント名/public_html/var/log/setup.cron.log
* * * * * /usr/local/bin/php71 /home/アカウント名/public_html/bin/magento cron:run | grep -v “Ran jobs by schedule” >> /home/アカウント名/public_html/var/log/magento.cron.log

さらに、もしSiteGroundにおけるMagentoルートのPHPバージョンが7.1ではなく、PHP7.0の場合には、以下のようにPHPバイナリーを変更します。

* * * * * /usr/local/bin/php70 /home/アカウント名/public_html/update/cron.php >> /home/アカウント名/public_html/var/log/update.cron.log
* * * * * /usr/local/bin/php70 /home/アカウント名/public_html/bin/magento setup:cron:run >> /home/アカウント名/public_html/var/log/setup.cron.log
* * * * * /usr/local/bin/php70 /home/アカウント名/public_html/bin/magento cron:run | grep -v “Ran jobs by schedule” >> /home/アカウント名/public_html/var/log/magento.cron.log

以上のコマンドは、SiteGroundでのCron設定の例なので、他のサーバーでそのまま使用できるとは限らないので、ご注意ください。
ただ、他のサーバーでも、cPanelのある環境では、上記のように、画面からの直観的な入力だけで、Magento2のCronの設定、設定変更が可能です。

また、cPanelの同じ Cron Jobs 画面の上部 Cron Email にて、メールアドレスを入力すると、Cronの実行でエラーが発生した場合に、そのメールアドレス宛にリアルタイムでエラーメッセージが届きます。

3. コマンドラインでのCron設定

cPanelのない環境では、SSHでサーバーにアクセスして、コマンドによりMagento2のCronの設定をします。
SSHは、WindowsではPuTTY、Macではターミナルなどのツールを使うのが一般的です。SSHアクセスの方法については、お使いのサーバー会社の説明をご参照ください。
以降は、SSHアクセスした後での、コマンドラインによるCronタブ設定の一例です。

Cronタブを編集するには、SSHで以下のコマンドを打つのが一般的です。

crontab -e

しかし、上記では、ルート権限のユーザー(root)で、Cronを作成することになってしまいます。
Magento2のCronは、Magento2のユーザーで作成する必要があります。

通常、VPSやクラウド環境に自分でサーバーを立ちあげる場合は、セキュリティ上の理由でrootとは別のユーザーを作成します。Magento2のインストールディレクトリも、そのドキュメントディレクトリの所有者は、ルート権限のあるユーザー(root)ではなく、別のユーザー(www-dataなど)に変更をします。
このドキュメントディレクトリのユーザーのことを、Magento2の公式案内では、しばしば、Magento file system owner と呼んでいます。

このCronの作成にあたっても、Magento2をインストールしたディレクトリのユーザーにて、コマンドを実行します。
仮に、Magento file system ownewのユーザーが、www-data であった場合は、以下がCron編集のコマンドになります。

sudo -u www-data crontab -e

このコマンドを打つと、画面にCronタブが表示され、PuTTYやターミナルで、直接Cronを入力編集することができるようになります。
以下は、PHPバイナリーが、/usr/bin/php で、Magento2のインストールルートディレクトリが、 /var/www/html/ の場合のコマンド例です。

* * * * * /usr/bin/php /var/www/html/bin/magento cron:run | grep -v Ran jobs by schedule >> /var/www/html/var/log/magento.cron.log
* * * * * /usr/bin/php /var/www/html/update/cron.php >> /var/www/html/var/log/update.cron.log
* * * * * /usr/bin/php /var/www/html/bin/magento setup:cron:run >> /var/www/htmlvar/log/setup.cron.log

PHPバイナリーのパスについては、cPanelでのCron設定でも説明しているように、which php のコマンドで回答を得られます。また、Magento2のルートパスについては、各自のインストール環境により異なりますので、任意に変更してください。

コマンドでのCronの編集

また、Cronの実行でエラーがあった場合に、メールで通知を受け取るには、

MAILTO=”sample@yourdomain.com”

という一行をCrontabに追加します。(” “内のメールアドレスは、任意で変更してください。)

ただし、毎分実行のCronでエラーが頻発すると、大量のメールを受信することになるので、ご注意ください。はじめの設定時に、Cronがきちんと実行されるかどうかを監視するには有効です。

Crontabの入力ができたら、入力内容の保存をし、Crontabの画面を閉じます。PuTTYでは、Ctrl + x ボタンを押し、保存しますかの問いに Y と入力します。

その後、新しいCrontabをリスタートするには、以下のコマンドを実行します。

Ubuntuの場合
sudo /etc/init.d/cron restart

CentOSの場合
sudo /etc/init.d/crond restart

また、保存したCronの内容を確認するには、以下のコマンドを打つと、Cronが表示されます。ユーザー名(www-data)は環境により任意で変更してください。

sudo -u www-data crontab -l

ちなみに、Cron編集作成のコマンドは、 -e でしたが、これは、editのeで、上記のCrontabの内容を確認する(見る)コマンドは、lookのl、なので、-l というふうに理解すると、二つのコマンドを混同することなく覚えられます。

コマンドでのCron設定は、環境によりPHPバイナリーのパスやユーザー名が異なるので、もし分からない場合は、お使いのサーバー会社に問い合わせて聞いてみてもいいかもしれません。

以上で、Magento2のCron設定の説明は終了です。

Magento2+日本語をComposerでインストール(動画の解説)

By |2019-05-18T15:09:09+09:002018年2月28日|Categories: Magentoの設定, Magento日本語化, SiteGroundについて|Tags: , , , |

*Magento2の日本語化についてご注意(2019年5月追記)

2019年5月、最新のMagento2.3バージョン以降に対応した、新しい日本語エクステンションがリリースされました。
新しい日本語エクステンションも、Composerでのインストールが可能で、この記事の動画にてご案内している作業と同じようにインストールすることができます。

2.2系以前の日本語ロケール/日本語ローカライズ
php composer.phar require veriteworks/m2-japaneselocale
php composer.phar require magento-japan/m2-jplocalize:dev-master

2.3系以降の新しい日本語エクステンション
php composer.phar require community-engineering/japan-common

Magento2.3.xを日本語化するには、2.2系以前の二つのコマンドの代わりに、2.3系以降の新しいエクステンションをインストールするコマンドを実行してください。

詳細は、Magento2.3に日本語エクステンションをインストールするの記事をご参照ください。

1.Magento言語ロケールについて

Magentoは、言語ロケール/言語パッケージという一種のエクステンションをインストールすることで、多言語化することができます。適用できる言語は、Magentoルートで、bin/magento info:language:list  のコマンドを入力するとリストアップされます。

Magento2言語ロケールのコードリスト

Magento2のデフォルトインストールでは、English(United States)の、en_US が基礎言語として展開されます。ここに、日本語ロケールをインストールすると、Magentoの基本機能のテキストを日本語に置き換えて表示することができます。言語コードは、原則として、ISO 639-1の言語コード二文字と、ISO 3166の国コード二文字の組み合わせで決まります。日本語ロケールのコードは、ja_JP となります。
中国語のロケールはやや特殊で、中国大陸の簡体字はzh_Hans_CN、香港の繁体字はzh_Hant_HK、台湾の繁体字はzh_Hant_TWとなっています。Magentoの言語ロケールについての説明は、Magento多言語化/翻訳のページもご参照ください。

言語ロケールは、すでにインストールされているMagentoに後から追加インストールすることもできますが、以下の動画では、Magento2の本体と日本語ロケールを、Composerを使って同時にダウンロード/インストールしています。

(先にMagento2をインストールし、後から日本語ロケールをインストールする場合、Magento2のストアを日本語化するためには、管理画面の Stores> Configuration> General> Locale Options で 「Japanese/日本語」を選択してください。)

先ず、PuTTYでSSHアクセスをして、Magentoをインストールする階層/ディレクトリ(Magentoルート)へ移動します。cd というのが、ディレクトリの移動のコマンド(change directoryの省略)で、cd public_html/dekirumonn.com/demo で、今回のMagentoルートへ移動できます。(どのディレクトリにMagentoをインストールするかは各人の任意ですので、作業環境によってコマンドのパスは変更してください。)

2. Composerのインストール

Magento2をインストールする前に、Composerをインストールします。
Composerとは何なのか、なぜMagentoをインストールするためにMagentoとは関係ない(ように見える)ものをインストールする必要があるのか、ComposerがなくてもMagentoのインストールはできるのではないか? そんな疑問にとらわれる人が多いと思います。そこで、検索をすると、「Composerとは、PHPアプリケーションのライブラリ/パッケージの依存関係を管理するツール」というような説明がたくさんヒットします。そして、余計に混乱します(笑)。日本語を読んでいるのに、さっぱり意味が分らないのです。

Composerの公式サイトを訪れると、上の日本語の意味とおおよそ同じであろう説明が英語で書かれています。Composer is a tool for dependency management in PHP. It allows you to declare the libraries your project depends on and it will manage (install/update) them for you. やはり、これだけではよく分かりません。dependency というのがキーワードで、この語の含まんとする概念をよく理解することが、Composerの働きを知るのに重要そうだ、くらいのイメージは湧きます。
つづけて英語で検索してみると、例えば、What is a dependency or package manager?では、”dependencyとは何なのか?”とストレートに質問している人がいます。それに対して、”A dependency is another library that the one you are using requires.”という回答があります。直訳すれば、「あなたがいま使っているライブラリが必要としているもう一つ別のライブラリ、それがdependencyだ。」くらいの意味になります。質問者の理解は進み、次のように要約します。

Library – A collection of already pre-written code to make my life easier so I don’t have to write everything from scratch(ライブラリとは、すでに書かれてある定型コードの集積で、それがあれば自分で一から書く必要などなく、私の人生を楽にしてくれるもの)
Package – Collection of libraries that are built on each other or using each other one way or another(パッケージとはライブラリの集積で、そこでは複数のライブラリが様々な方法でお互いを使い、お互いに必要とされながら組み立てられている)
Dependencies – Managing how these libraries are related to each other and which ones are essential to run the code. For example library “A” is using code from library “B” so I need both if I want to use codes from library “A”. (Dependencyとは、これらのライブラリが相互にどのように関わっているのかを見極め、そして、あるコードを走らせるためにはどのライブラリが不可欠なのかを突きとめること。例えば、ライブラリAがライブラリBのコードを使っている場合、ライブラリAを使うためには、ライブラリAもライブラリBも両方とも必要となる)

この英語を読むと、dependencyの語の表現している概念がどのようなものなのか、なんとなくイメージすることができます。
技術的にきちんとした理解に至らずとも、運営者としては、いかに使いこなすかということのほうが大切なので、ここでは、Composerとは、Magento本体やMagentoエクステンションのインストールを楽にし、全体をひとつのプロジェクトとして管理してくれるもの、Composerがあればアップデートやバージョン情報も一元化できる、くらいのイメージを摑んでおけば充分だと思います。

さて、Composerをインストールするには、次のコマンドを使います。

curl -sS https://getcomposer.org/installer | php

動画の中では、

curl -sS https://getcomposer.org/installer | php71

と、最後に 71 という数字をつけています。

これは、PHP7.1バージョンを指定しています。なぜ指定しているのかと言うと、この動画での環境(SiteGround)が、デフォルトではPHP5.6バージョンだからです。しかし、cPanelのPHPバージョン管理で、特定ディレクトリを別のPHPバージョンで運用することができます。Magento2.2以降は、PHP5.6をサポートしなくなったので、今回のMagentoインストール先のディレクトリに、あらかじめPHP7.1を設定しています。そのため、Composerをインストールするコマンドにおいても、デフォルトのPHP5.6ではなく、PHP7.1の環境でのインストールですよと、明示的に指定をしています。(海外サーバーのSiteGroundについては、Magentoサーバーのページをご参照ください。)

今回の動画では、すべての phpコマンドで、php71となっています。ご自身の環境にあわせて、ここは読みかえてください。

尚、ルート権限のある環境でユーザーを作成している場合は、sudoコマンドとなります。Composerもサーバー全体にグローバルに利用することができるので、Composerをインストールした後に、mv composer.phar /usr/local/bin/composer とファイル移動をするのが一般的です。動画では、ローカルのまま使用しています。

Composerのインストール後に、php71 composer.phar と打つと、きちんとインストールされているかどうかを確認することができます。動画では一瞬で、スクロールも戻していないので見えづらいかもしれませんが、以下のような画面が表示されれば、Composerが正しく入っていることになります。

Composerインストール

3. Magento2のダウンロード

つづいて、このComposerを使って、Magento2のファイルをダウンロードします。コマンドは以下のようになります。

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

これは、Magento2のファイルの格納されているサーバー倉庫/リポジトリ(repo.magento.com)から、Magento2のCE版の最新版をダウンロードするためのコマンドです。Magento2のバージョンを指定したい時には、php71 composer.phar create-project --repository-url=https://repo.magento.com/ magento/project-community-edition=2.2.2 等と、最後に=バージョン数を入れます。
また、このコマンドでダウンロードをする場合、Magento2のファイルが、project-community-edition というフォルダ内にダウンロードされます。フォルダ名を変更するには、php71 composer.phar create-project --repository-url=https://repo.magento.com/ magento/project-community-edition your-folder-name と、半角空けて最後に任意のフォルダ名(この場合はyour-folder-name)を入れ、指定することもできます。

動画では、比較的スムースにMagento2ファイルのインストール(ダウンロード)がはじまっていますが、実は、この動画を撮る前に、練習で一度同じ作業をしています。なので、その際にダウンロードしたデータがComposerのキャッシュに残っているので、キャッシュからの読み込みとなっています。はじめてMagento2ファイルをダウンロードする場合は、もしかしたら、止まってしまったのか、、?と不安になるくらいに時間がかかることが多いので、しばらく待って、画面を見守ってください。

4. Magento2ファイルの移動(cPanel FileManagerでの作業)

Magento2ファイルのダウンロードが完了したら、一度PuTTYを離れて、FTPでの作業をします。
動画では、cPanelに付属しているFileManagerを使用しています。

Magentoルートを見ると、先ほども触れたように、project-community-edition というフォルダが作成されています。その中にMagento2のすべてのファイルがダウンロードされているので、この状態だと、もともとMagento2をインストールしようとしていたディレクトリの一つ下の層にファイルが配置されているかたちになります。なので、動画では、このフォルダ内のファイルを、すべて選択&マウスドラッグで、一つ上のディレクトリへ移動しています。

もちろん、Magento2のダウンロードのコマンドでフォルダ名を指定し、そのままそこをMagentoルートとして運用することも可能です。その場合、PuTTYでの作業で、ディレクトリをひとつ下げて、次の日本語エクステンションをダウンロードするコマンドを打つことになります。なので、FTPでは、逆に、composer.phar ファイルを、一つ下層の該当フォルダ内へ移動することになります。(ルート権限があり、Composerをグローバルにインストールしている場合は、composer.pharファイルの移動は必要ありません。)

コマンド作業に慣れているかたは、FTPを使わずに、コマンドのみでファイル移動をすることもできます。

また、Magentoデモで紹介しているLumaテーマのように、Magento2のサンプル商品データも同時にインストールする場合は、php71 bin/magento sampledata:deploy のコマンドで、Magento2のインストール前に、サンプルデータもダウンロードします。
(Composerを使ってサンプルデータ入りのMagento2をインストールする場合、サーバー環境によっては、数時間~というフレームでかなり長い時間がかかりますので、作業のタイミングにご注意ください。)

はじめてMagento2の本体やサンプルデータをダウンロードする時には、Magento Marketplaceで取得をしたPublic Key(Username)とPrivate key(Password)の入力を求められます。事前にMarketplaceのアカウントを作成し、Keyを準備しておいてください。詳しくは、Magento2.3に日本語エクステンションをインストールの記事をご参照ください。

5-6. 日本語ロケール/日本語リージョンのダウンロード

この段階で、Magento2を英語のまま通常通りにインストールするなら、ブラウザでのインストール画面へと進みます。しかし、今回は、Magentoインストール前に、日本語エクステンションを事前にダウンロードすることで、はじめからデフォルト言語を日本語としてMagento2をインストールしてみます。

今回の動画でインストールしている日本語エクステンションは、Veriteworksさんの開発された日本語ロケール/リージョン(ローカライズ)です。エクステンションの詳細は、Veriteworksさんのサイトをご参照ください。https://principle-works.jp/magento2-extension/japanese-localize
Veriteworksさんのエクステンションは、Magento Marketplaceにも掲載されているのですが、最新バージョンのコードは、GitHubで公開されています。

日本語ロケールをダウンロードするコマンドは、以下のようになります。

php71 composer.phar require veriteworks/m2-japaneselocale

また、日本語リージョン(ローカライズ)をダウンロードするコマンドは、以下のようになります。

php71 composer.phar require magento-japan/m2-jplocalize:dev-master

Composerでダウンロードをする場合、一般にそのパッケージのレポジトリ(倉庫)は、Packagistになります。大抵は開発者のかたで、GitHubとPackagistを連携されているので、GitHubにあるパッケージをComposerでダウンロードするときは、基本的にPackagistから読み込みをしていることになります。

尚、後者の日本語ローカライズのコマンドのほうは、php71 composer.phar require magento-japan/m2-jplocalize と打つと、バージョン情報を入れてくださいという趣旨のエラーが出てしまうので、コマンドの最後に、:dev-master と追加し、デフォルト(バージョン指定なし)としてダウンロードしています。

この二つの日本語化エクステンションを入れると、日本語/日本円決済対応の、日本市場で利用のできるECプラットフォームのベース機能をMagento2に追加できたことになります。

また、ComposerでダウンロードしたMagento2のすべてのエクステンションは、vendor フォルダ以下に配置されます。動画で確認していなかったのですが、今回の二つの日本語エクステンションは、以下の画像のように配置されています。

Composerでインストールした日本語エクステンション

注意すべきは、この vendor ディレクトリは、Composerでのインストールをしたエクステンションのみが配置されるということです。
例えば、GitHubでエクステンションのzipファイルを自分のPCにダウンロードし、FTPでここにアップロード、解凍しても、Magento2側としては、新しいエクステンションが入ったと認識してくれません。
FTPを使い、手動で一般のエクステンションをアップロードする場合は、vendor フォルダではなく、app/code 以下に配置することになります。ちょうど、Magentoテーマのページで紹介している動画で、Ultimoテーマをアップロードしたのと同じような作業になります。そして、アップデート後に、コマンドでファイルを展開させます。

尚、言語ロケールのパッケージファイルを手動でアップロードする場合は、エクステンションとしては別枠扱いのようになり、app/code ではなく、app/i18n というフォルダへアップロードします。i18n がない場合は、自分でそのフォルダを作成します。
ちなみに、i18n というのは、internationalization の省略で、この語が長いので、iとnの間に18文字あるよ、みたいな意味合いとして慣用的に使われているようです。

7. ブラウザでMagento2をインストール

Magento2本体と、日本語ロケール/日本語リージョンのダウンロードができたら、いよいよMagento2のインストールになります。
Magento2のルート、ストアURLにブラウザでアクセスしてください。すでにストアURLを開いている場合は、ブラウザの更新ボタンを押してください。そうすると、Magento2のSetup Wizardインストール画面に自動でリダイレクトされます。

ここからは、基本的に画面の指示通りに進み、必要な項目を入力すればいいので、作業そのものは簡単です。
ただし、はじめの環境チェックでNGになり、なかなか次のステップへ進めない場合は、お使いのサーバーの設定やパーミッションを見直す必要があります。先ずはサーバー会社に問い合わせてみるのがいいと思います。

また、Nginxサーバーの場合は、Setup WizardでMagento2をインストールすることができません。エラー、とかではなく、はじめから対応していません。信じられないかもしれませんが、公式ドキュメントでもそう明記してあります。なので、Nginxの場合は、コマンドラインからのインストールになります。

動画では、SiteGroundという海外老舗サーバーを利用しています(GoGeekプラン*)。格安ですが、Magento2も一通り構築・運営できるスペックがそろっているので、極度の英語アレルギーでなければ、ぜひチャレンジされることをおすすめします。特に、海外向けの越境ECサイトとしてMagento2での構築を計画されているなら、海外サーバーは日本国内のサーバーよりも好条件になります。
(*SiteGroundのStartupプランでは、メモリ不足でComposerでのモジュールインストールができないという報告をいただきました。Composerをお使いになる場合は、上位プランをご検討いただくか、他のVPSサービス等をご利用ください。)

また、Setup WizardでMagento2のインストールをはじめる前に、cPanelのMySQL Databasesなどで、Magento2用の新しいデータベースを作成しておいてください。そして、動画のように、作成したデータベースの情報を入力してください。
今回はデモサイトなので、admin管理画面のパスやユーザー名は、単純にadminで進めていますが、実際のインストールでは、第三者に推測されにくいワードを使用してください。
HTTPSのオプションは、SSLを入れていないテスト環境などでは、チェックせずにそのままインストールを進めてください。後で、管理画面の設定から、フロントもバックエンドも、httpsに変更することができます。

最後に、管理画面内の言語について。
デフォルトを日本語にしてMagento2をインストールしても、管理画面内の言語は英語のままになっています。日本語に変更したい場合は、管理画面の右上、人のアイコンのプルダウン > Account Setting > Interface locale で「日本語/Japanese」を選択すると、管理画面内が日本語表示に切り替わります。
ただ、Magentoの構築では、なにか壁にぶつかった時、英語で検索をして問題解決の糸口に辿りつくことが多く、その際に管理画面が日本語表示だと、かえって分かりづらくなってしまうケースもあります。
個人的には、もし英語表示に抵抗がなければ、フロントが日本語ストアでも、バックエンドの管理画面は英語のままにしておくことをおすすめいたします。

補足. 言語ロケールのCSVファイル翻訳編集について

Magento2にインストールした日本語ロケールの翻訳テキストは、CSVファイルで編集することができます。
日本語CSVファイルは、画像のように、[magento2ルート]/vendor/veriteworks/m2-japaneselocale/ja_jp.csv に配置されています。このja_jp.csvファイルをダウンロードし、CSVファイルを編集できるエディターで開いてください。文字化けしてしまう場合は、文字コードをUTF-8にして、開きなおしてください。

Magento2日本語ロケールCSVファイル

ja_jp.csvファイルには、左側に、Magento2の基礎言語となっている英語(en_US)のフレーズがリストアップされており、その右側に、英語フレーズに対照するように、日本語翻訳のフレーズが入力されています。
翻訳のテキストを変更したい場合は、この日本語フレーズを編集し、CSVファイルを保存、そして元の場所にアップロード上書きをします。また、CSVファイルに行を追加し、新たに日本語翻訳の項目を追加することもできます。

変更を反映させるためには、Magento2のキャッシュをクリアし、SSHアクセスをして、日本語ロケールのファイルを再展開します。コマンドは以下のようになります。(環境によりphp71は置き換えてください。)

php71 bin/magento setup:di:compile
php71 bin/magento indexer:reindex
php71 bin/magento cache:clean
php71 bin/magento cache:flush

Magento2が、Productionモード(ライブ環境)になっている場合は、さらに以下のコマンドで展開させます。

php71 bin/magento setup:static-content:deploy ja_JP

もし上記をしても変更が反映されない場合は、ブラウザやサーバー側のキャッシュもクリアしてください。

Defaultモード/Developerモードでは、php71 bin/magento setup:static-content:deploy ja_JP で静的ファイルを展開させようとするとエラーになるので、php71 bin/magento setup:static-content:deploy ja_JP -f と、-f をつけて、強制的に日本語ファイルを展開させてみる方法もあります。

以上、Magento2を日本語化するためのComposerでのインストール動画の解説でした。

まとめ. Magento2日本語環境インストールのコマンド

Composerインストール

コピーする

Magento2ファイルダウンロード(共用サーバー)

コピーする
コピーする

Magento2ファイルダウンロード(VPS/Cloud)

コピーする
コピーする

日本語ロケールダウンロード(共用サーバー)

コピーする

日本語ロケールダウンロード(VPS/Cloud)

コピーする

日本語リージョンダウンロード(共用サーバー)

コピーする

日本語リージョンダウンロード(VPS/Cloud)

コピーする
Magento多言語化

Magento多言語化と翻訳

Magento言語ロケールで基本機能の多言語化が可能です。コンテンツの翻訳は、APIの利用でMagento2と翻訳システムを連携することもできます。

Magento多言語化と翻訳