Magento2をベースとしたプロジェクトでやってはいけないこと
この記事は公開から 1年以上が経過しています。現在の最新情報との整合性については弊社では一切の責任を負いかねます。
弊社では多くのMagentoを用いたサイト構築のプロジェクトに対して技術的なアドバイスや実装面での支援を行っています。
これはMagento1の時代からずっと変わらずにご提供しているサービスで、弊社のサービスの原点ともいえます。
最近特に多いのは、やはりMagento2をベースにしたプロジェクトです。
昨年後半からご相談が急に増え始め、今ではMagento1での新規プロジェクトは全く聞かなくなりました。
それはそれで良いことなのですが、Magento2を採用されたプロジェクトの幾つかでは「やってはいけないカスタマイズ」がMagento1とは別の形で行われていました。
今回はそんな「Magento2でやってはいけないこと」についてお伝えしたいと思います。
バージョン管理をしていない
「バージョン管理?なにそれ?」という方もおられると思いますが、バージョン管理を行わずに、Magento2をベースにしたプロジェクトをすすめるのは大変危険です。
Magento2の基本ソースコード一式だけでも大変な量があり、バージョンが上がるたびに広範囲に変更が行われます。
新設された機能・処理ばかりであればよいのですが、仕様変更や機能廃止などもあるため、バージョン管理システムによる差分抽出機能なしには適切な把握はほぼ不可能と行っても良いでしょう。
にも関わらず、バージョン管理を行わず、かつプロジェクト責任者が実装者の作業を適切に管理できていないケースが多く見られます。
まずはプロジェクトを始める際にバージョン管理を行う。これはとても重要です。
vendor下のディレクトリに手を加えている
Magentoに限った話ではありませんが、最近のPHPで書かれたWebアプリケーションの多くは、composerを使用しています。
composerの仕様として、サードパーティ製のライブラリはvendorディレクトリに配置されるようになっています。これはMagentoも同じです。
さて何が問題かというと、「composerによるライブラリの更新時には、変更箇所が消去される」ということです。もちろん変更箇所が改変される際にcomposerが警告してくれるケースもありますが、なんの警告もなく更新が行われることもあります。
怖いのはMagento自体のアップデートもcomposerを使っている、ということです。
何かしら改変を加えていた場合、Magento自体のアップデートに伴って、その改変箇所が消去されてしまい、動作しなくなるということが考えられます。
そういった状況を避ける意味でも、vendor下には手を加えないのが理想です。MagentoのテンプレートやCSS、JavaScriptなどの修正はカスタムテーマとして行うべきですし、標準仕様では満足できない箇所については既存のエクステンションを導入するか、自前のエクステンションとして開発するべきです。
なお、composerでインストールすることを目的としたエクステンションのアーカイブファイルをvendor下にartifactディレクトリを作成して配置することは問題ありません。（別のディレクトリでもよいのですが）
やってはいけないことは以下の2つです。
- composerが管理していないエクステンションやライブラリをvendor下に配置する
- vendor下でcomposerが管理しているファイルに手を加える
Magento自体のバージョンが古い
Magento2はMagento1と異なり、セキュリティパッチがリリースされません。
Magento2でサイトを運営する上では、常に新しいバージョンに追従していく必要があります。ですから新しいバージョンがリリースされた際に、試験用の環境できちんと動作試験を行い、問題がないようであれば本番へと適用するという体制を整える必要があります。
ところが、以下のようなプロジェクトの場合はアップデートが行われていないことが多々あります。
- 導入しているエクステンション・テーマの関係でアップデートができない
- vendor下に手を入れていて、アップデートが難しくなっている
- 開発者にそもそもアップデートする気がない
- アップデートの必要性を認識していない
1のケースは状況によっては致し方ないこともありますが、できるだけ早く開発元から新しい対応版を手に入れたほうが良いでしょう。
あるいは自社専用エクステンション・テーマの場合は評価試験を速やかに行える体制構築が必要だと思います。
2と3は非常に問題です。
2は開発担当の自業自得ですが、運営者としては大迷惑です。きちんとコアハックを修正し、アップデートできるように対処を依頼すべきでしょう。（問題は開発担当がコアハックの問題点を認識できていない事が多い、ということですが）
3は論外です。アップデートをしないということは、脆弱性を放置することと同じです。
ある製品の特定のバージョンに脆弱性があることを知りつつ、それを放置するのは巡り巡ってサイトの所有者と顧客に迷惑をかける事になります。
Magento2はきちんとカスタマイズをしていればアップデートできる構造になっているので、アップデートを放置せず、タイミングを見て適用するようにすべきでしょう。
4は本来管理画面にMagentoからの通知が出るはずなので、それを見逃している（あるいは英語アレルギーで拒否している）可能性があります。
また、開発者が意図的に通知を表示しないように手を加えている可能性があります。宣伝的な通知も出ることがありますが、本当に重要な通知が伝わらなくなることは大いに問題です。新しい通知については一通り目を通しておくか、あるいは開発者や保守担当に問い合わせるほうが良いでしょう。
Magentoの実行モードを指定していない
| パフォーマンス | 例外の表示 | ログ記録量 | 静的ファイルのデプロイ | |
| default | 中 | しない | 中 | シンボリックリンクで行われる。 |
| developer | 低 | する | 大 | シンボリックリンクで行われる。 |
| production | 高 | しない | 少 | 反映には setup:static-contet:deploy の実行が必要。 |
本来本番稼働させる環境ではproductionを指定してパフォーマンスを重視し、反対に開発・検証環境についてはdeveloperを指定して不具合などを検出しやすくすることが推奨されています。
defaultやdeveloperモードのまま本番運用に入った場合は適切なパフォーマンスが得られませんし、無用なデバッグメッセージが出てしまうこともありえます。
Magento2でサイトを構築するのであれば、稼働する環境に合わせた動作モードの指定を行いましょう。
動作モードとCSS/JSファイルのマージ・minifyについて
Magento2は非常に多くのCSSやJavaScriptファイルをページの表示に使用します。
knockout.jsを使用するページでは、さらにJavaScriptのテンプレートを利用するため、1ページあたりのHTTPリクエスト数が更に増大します。
Magentoには1系の頃から、CSS/JSのマージ機能が備わっていましたが、Magento2では標準でminify機能も備わりました。
productionモードで動作させる場合は、パフォーマンスをより高めるために、マージ機能とminify機能を有効にしておくことをおすすめします。
もちろん、テスト環境などであらかじめマージ・minifyした状態で試験をしておくことは不可欠です。
適切に書かれていないCSSやJavaScriptの場合、マージやminifyによって不具合を起こすことが多々あります。
事前にテストをせずに本番反映することは極めて危険です。
自作コードが正しく書かれていない
Magento2はコードの書き方についても明確な指針を持っています。
この特徴が明確に現れるのは、コマンドラインで以下のコマンド（以下、コンパイル処理）を実行したときでしょう。
php bin/magento setup:di:compile
ソースコードファイル中に適切なコメントが書かれていない場合、この処理はエラーで停止します。
Magentoの動作モードがproductionの場合はコンパイル処理が自動で行われるため、適切に書かれていないソースコードが本番環境に反映されてしまうと、サイトが停止する騒ぎに発展してしまいます。
本番環境に反映する前にコンパイル処理を実行し、正しく終了するかどうかを確認するようにしましょう。
サードパーティ製のエクステンションにも注意を
自作コードだけでなく、サードパーティ製のエクステンションを導入した場合も同様です。
コンパイル処理が通らないエクステンションが販売されている可能性は大いにあります。
本番に反映する前に、きちんとテストをすることが不可欠です。
