2

1.5Magento のバージョンを からにアップグレードしたいです1.7.0.2。しかし、私の以前のチーム メンバーは、多くのコア ファイルでコードを作成しました。そのため、アップグレードは困難です。このために、すべてのファイルをコアからローカルに同じフォルダー構造でコピーしてオーバーライドすることにしました。

お気に入り

/app/code/core/Mage/Sales         to /app/code/local/Mage

/app/code/core/Mage/Backup        to /app/code/local/Mage

/app/code/core/Mage/Catalog       to /app/code/local/Mage

/app/code/core/Mage/CatalogSearch to /app/code/local/Mage

/app/code/core/Mage/Checkout      to /app/code/local/Mage

/app/code/core/Mage/Contacts      to /app/code/local/Mage

/app/code/core/Mage/Reports       to /app/code/local/Mage

これは正しい方法ですか？これは Magento サイトのパフォーマンスに影響しますか?

4

5 に答える 5

4

コアの変更 (直接またはインクルード パス経由) よりもオブザーバーとクラスの書き換えを使用する方が良い理由は、クラス定義全体をオーバーライドする必要がほとんどないためです。後者の方法は単純に手間がかかりますが、以前のカスタマイズがどのように実装されたかに関係なく、過去の変更を新しい機能とマージする必要があります。これは、すべてのソフトウェア アップグレードに当てはまります。

専門家になりましょう: バニラ 1.5.xx コードベースに対して差分を実行し、可能な限りコアから変更をマージします。少なくとも、大幅に変更されたクラスまたはスーパークラスであるクラスのみをapp/code/local/Mage/に移動し、それらを 1.7.0.2 バージョンと比較してマージを完了します。

コア (通常はMysql4フォルダーの下) で変更されたリソース モデルは、書き換えによって適応させるか、対応するResourceパスに移植する必要があることに注意してください。

于 2013-04-04T14:40:48.770 に答える
0

あなたはすでにそれを言った、あなたの前任者は彼のコアハックでアップグレードを困難にしました. パフォーマンスについて心配する必要はありません。app/code/local 内のコードがパフォーマンスに悪影響を与えることはありません。しかし、異なるバージョンの多くのコードは一緒にうまく動作しない可能性が高いため、関数について心配する必要があります。

あなたが提案するのは、クリーンアップの最初のステップですが、次のステップは更新ではありません。

  1. コア ハックを app/code/local に移動
  2. それらをモジュールに変換し、必要に応じてクラスの書き換えを使用しますが、常にオブザーバーを優先します。書き換えは、元のコピーを変更するべきではありませんが、それらを拡張し、オーバーライドをできるだけ少なくする必要があります。
  3. マジェントを更新する
  4. 書き直されたクラスを新しいバージョンに適応させる

すべてのステップの後、システムを徹底的にテストし、可能な限り自動化します。

1.7 はほとんどの部分で 1.5 と下位互換性があるため、ステップ 4 はそれほど多くないはずです。

大変な作業ですが、これはあなたが継承した技術部門であり、更新により給料日が来ます. このプロセスで最も複雑なことは、コア ハックが何をしているか、それらが一緒に属していて、それらが本当に必要かどうかを調べることです。

于 2013-04-04T06:19:24.133 に答える