Magentoのアップグレードの見積もりは、最新のインストールに適用された変更に関する情報を収集し、それらの変更が問題を引き起こす可能性があるかどうかを確認し、それらを回避するのに必要な時間を評価するプロセスです。
すべての変更は、文字通りに分割することができるコアオフとにコア。
コア外の変更は、アップグレードで上書きされないものです。これらは、サードパーティの拡張機能、ローカルスコープ（app / code / local / Mage）に配置されたコアファイル、およびカスタムテーマです。
では、コア変更はMagentoの上で直接適用されるコアファイル（アプリ/コード/コア）、ローカライズファイル（アプリ/ロケール/ en_USの）、コアテンプレートなどいくつかのJavaScript、外部ライブラリめったにそれにもかかわらず、カスタマイズされていない考慮に入れなければなりません。
コア外の変更
サードパーティの拡張機能
アップグレード中、サードパーティの拡張機能が問題の主な原因です。つまり、より多くの拡張機能を使用して、それらを分析する必要があります。
最初に確認することは、拡張機能によって提供される機能がアップグレード先のMagentoのバージョンにまだ実装されていないかどうかです。例えば、のようないくつかの拡張機能Yoast_CanonicalUrl、Mxperts_CustomerAddressまたはをFontis_Wysiwyg広くMagentoの1.3.xxで使用しないと古いが、今コアMagentoの機能の一部であり、もはや必要とされました。
次に、持っている拡張機能が本当に必要かどうかを確認する（顧客に尋ねる）ことをお勧めします。いくつかの拡張機能がインストールされていても、実際に使用されたことはありません。そのため、この時点で、一種のクリーンアップを行うことをお勧めします。
次に、確認する重要なことは、残りの各拡張機能とアップグレードするMagentoのバージョンとの互換性です。一部の拡張機能に互換性がなく、同様の拡張機能が利用できない場合、一部の機能を失うか、既存の拡張機能を変更して互換性を確保するかを選択できます。
注：サードパーティの拡張機能を直接変更するのではなく、古い拡張機能を拡張する新しい拡張機能を作成してから、新しい拡張機能のブートストラップXMLに依存関係を設定します。
これらすべてを実行した後、残りの各拡張機能の実際の分析を提供できます。常にetc/config.xmlファイルの検査から始まります。次の3つを確認する必要があります。
- クラスの書き換えはそれ自体ではクリーンな手法ではありませんが、場合によっては他の方法はありません。したがって、Magentoの新しいバージョンで書き換えられたクラスが変更された場合、これは潜在的な問題になる可能性があります。
- レイアウトの更新によりアップグレードで問題が発生する可能性は低くなりますが、拡張機能が新しいMagentoバージョンで廃止されたブロックを参照している場合は、この問題を回避する必要があります。
- SQL更新は、アップグレード中に非常に過小評価されている問題の原因です。この問題は、サードパーティの拡張機能がデフォルトのMagentoテーブルの一部のフィールドを参照する外部キーを作成しているときに発生します。その結果、このフィールドは変更できなくなります。そして、ネイティブインストールスクリプトがこのフィールドを更新しようとすると、サイレントに失敗します。その後、このフィールドを参照する次のインストールスクリプトはすべて、アップグレードをクラッシュさせます。
app / code / local / Mage
拡張機能を使い終わったら、app/code/local/Mageディレクトリを見てみましょう。ここでは、修正されたコアファイルがlocalスコープに移動されています。そこに何が修正され、どのような理由で変更されたのかがわからないので（それらをそこに置いたのがあなたでなかった場合）、白髪が必ずかかります。そのため、それぞれをオリジンと比較し、追加された機能を新しいバージョンの対応するファイルに移行する必要があります。
カスタムテーマ
最後の一連のオフコア変更は、カスタムテーマです。これは大したことではないように見えるかもしれませんが、実際にはこれは灰色の領域です。Magentoのベーステーマはバージョンごとに変更されており、各カスタムテーマはそれらの変更の一部を模倣する必要があります。残念ながら、何を探し、何を移行する必要があるかを決定する特効薬はありません。そのため、アップグレード後にいくつかの大きな驚きと些細な不注意に備えてください。
コア内の変更
完璧な世界には何もありません。しかし、安価で多く提供しているサードパーティの開発者に悪用された後、Magentoをインストールした場合、何でも期待できます。したがって、コア内の変更は、アップグレードプロセス中に上書きされるものです。ほとんどの場合、エラーは発生しませんが、その結果、そのような残忍な方法で追加された機能は失われます。
コア内の変更を検出する唯一の方法は、Magentoインストールのすべてのファイルを同じバージョンのクリーンファイルと比較することです。gitで行うことをお勧めします。どうして？それはすべての改行と空白をうまく処理するからです。
Magentoのインストールがgitの下にない場合でも、ファイルを別のディレクトリにコピーしてからgit initを実行できます。次に、最初のコミットを行い、「クリーン」なMagentoファイルをコピーして実行しgit statusます。次のようなものが得られます。
変更されたファイルの数に応じて、git diff各ファイルまたはバッチ全体で一度に実行できます。これにより、行われたすべてのコア内変更の包括的なリファレンスが提供されます。phpStormのようなgitビジュアライゼーションがある場合、人生はずっと簡単です：
そうすることをお勧めします。git diff > changes.txt常に手作業で変更のリストを入手してください。
コアの変更のリストがあると、新しいバージョンに転送する必要があるものと、そのために必要な時間を見積もることができます。
ここで、実際のアップグレードについていくつかアドバイスをしたいと思います。このプロセスは十分に文書化されているため、実行するコマンドとクリックする場所を記述しません。ただし、いくつかの重要なことに重点を置きたいと思います。
- 開発環境でアップグレードすることを想定しています。実稼働サーバーでアップグレードを実行することは自殺です。
- アップグレード中は、本番環境で何も変更させないでください。Magentoをバージョン管理下に置くか、一時ファイルの書き込みを禁止します。
- すべてのサードパーティの拡張機能を無効にしますが、最初に無効になった拡張機能をメモして、後で有効にしないようにします。
- サーバーで実行されているMagentoクリーンアップスクリプトがあるかどうかを確認します。それ以外の場合で始まるすべてのテーブルを切り捨て
dataflow_*、log_*、report_*。
- アップグレード時にデフォルトのテーマに戻します。
アップグレードスクリプトの完了後：
changes.txt実際に移行する価値があるすべてのコア内の変更を移行する前に行った参照。app/code/local/Mageアップグレード前に見つかった変更を移行します。- サードパーティの拡張機能を1つずつ有効にします。
- テーマを元に戻し、結果を運用サーバーと包括的に比較します。
- 結果に満足したら、運用環境に展開します。
結論
これはすべて怖いように聞こえますが、定期的にアップグレードし、コアをクリーンに保ち、本当に信頼できるベンダーからのみ拡張機能をインストールする場合、本当に必要な場合にのみ、この記事で説明する困難のほとんどに直面することはありません。Magento EcoSystemを健康に保つと、報酬が与えられます。
ポスト台本
非常に複雑な場合は、最新のMagentoの新規インストールからやり直して、ストアのテーマと機能を段階的に移行するのが理にかなっています。これには間違いなく時間がかかりますが、最終的には、何が起こっているのかを完全に認識した健全なMagentoシステムになります。