異なるMagentoバージョンにモジュールの互換性を保つ

今日、私は次の問題に遭遇しています：私が開発したモジュールは、Magento 1.7バージョンストアで非常にうまく機能します。ここで、Magento 1.5ストアでも動作するように適応させる必要があります。

互換性がバラバラになっている1つのポイントは、クラスを拡張している私のコレクションですMage_Core_Model_Resource_Db_Collection_Abstract。このクラスはMagento 1.5には存在しませんが、getMainTable（）などの優れた機能を備えています。私ができることの1つは、代わりにVarien_Data_Collection_Dbinから継承されたクラスを使用することですMage_Core_Model_Resource_Db_Collection_Abstract。これは機能しますが、getMainTable（）メソッドを使用できなくなります。それが実際に存在する1.7ストアでさえも使用できません。

このようなバージョン固有の癖をどのように処理しますか？バージョン1.7が既に持っているものを実装し、それによってそのバージョンでコードを複製するカスタムクラスを書くのはばかげているようです。逆に、機能がなく、代わりにハードコーディングのようなより悪いコーディング習慣を使うのは悪いことです。それで、後方互換性のあるMagentoモジュールを書く上で良いアプローチはありますか？

magento呼び出しの親の実装のバージョンに応じて、必要なすべての関数を実装する中間クラスを作成するか、独自の実装を使用できます。

model / Int.php

<?php
  if (!version_compare(Mage::getVersion(), '1.7', '>=')) {
    class N_M_Model_Int extends Mage_Core_Model_Resource_Db_Collection_Abstract
    {
    }
  } else {
    class N_M_Model_Int extends Varien_Data_Collection_Db
    {
      public function getMainTable()
      {
        // my implementation
      }
    }
  }
?>

model / Final.php

<?php
  class N_M_Model_Final extends N_M_Model_Int
  {
    // common code between all the versions
  }
?>

これはあなたが探している正確な答えではないかもしれませんが、多くの人が古いバージョンの拡張機能を開発しているとは思えません。

アップグレードするだけで、とにかく避けられない

明らかな解決策は1.5の顧客が1.7にアップグレードすることです（とにかく1.5はひどく壊れたリリースです）。

しかし、あなたがしなければならない場合

それに取り組む必要がある場合、それは、必要なコア機能をバックポートするために、セカンダリ基盤モジュールでモジュールをバックアップする場合にすぎません。その後、アップグレードの時期になると、依存関係モジュールは単に削除/削除することができます。

欠点は、単一の関数を追加/変更するためだけに抽象クラスをオーバーライドする可能性があることです。これに費やした時間は、最初からストアをアップグレードするだけで十分です。

拡張機能に下位互換性を持たせることに関しては、奇妙なやり方のようですが、新しいリリースで妥協することになります。拡張機能は自然に古くなる傾向があるため、下位互換性があります。開発して、前方互換性を持たせます。

サードパーティのモジュールのソースコードを見たことがあるなら、それらはMage::getVersion()呼び出しと条件ステートメントで満たされる傾向があります-すべてマルチバージョン互換です。その厄介で、避けるべきです。現実には、Magentoのバージョンごとに、異なるバージョンの拡張機能が必要です。そうしないと、クラスメソッドに偏差があり、条件ステートメントの数が増える拡張機能をサポートする必要があります。

ここに理由の良い例がありますが

私はあなたの論理を理解しています。しかし、1.4.1> 1.4.2アップグレードやEAV販売テーブルなどの場合に何が起こるかは削除されました。この表に基づいて操作された新しい関数はすべてフラットになりました。そのため、これをバックポートしようとすると、その価値よりもはるかに面倒です。これは極端な場合があり、投資する時間を明確に判断します。

Magentoの最新バージョンはいつまでも動くターゲットとなり、新しいモジュールを古いストアで動作させるか、古いモジュールを新しいストアで動作させるかを選択できます。私たちはむしろ何をしたいのか知っています。関数の廃止は遅く、優雅であり、それらを新しくするための十分な時間があります。

あなたが直面しているものは、修正がかなり簡単です。1.6以降、一部のMysql4クラスはResourceクラスに移動しましたが、Magento開発者が必要な作業を行っているため、下位互換性は引き続きサポートされています。

Mage_Core_Model_Resource_Db_Collection_Abstractクラスの場合は、代わりにMage_Core_Model_Mysql4_Collection_Abstractを使用します

Mage_Core_Model_Resource_Db_Abstractクラスの場合は、代わりにMage_Core_Model_Mysql4_Abstractを使用します

これらのMysql4クラスに移動すると、それらは空白であり、Resourceクラスを適切に拡張しているだけです。

これがあなたを助けることを願っています

Domen Vrankarの回答に加えて、次のようなこともできます。

<?php

if (!version_compare(Mage::getVersion(), '1.7', '>=')) {
    $code = "\nclass N_M_Model_Int extends Mage_Core_Model_Resource_Db_Collection_Abstract\n";
} else {
    $code = "\nclass N_M_Model_Int extends Varien_Data_Collection_Db\n";
}

$code .= <<<FEED
{
    //class implementation

} // END OF CLASS
FEED;

eval ( $code );

誰かがこの方法を好むかどうかはわかりませんが、SweetTooth Rewardsがこれを行うのを見てきました。