構成可能な製品と属性セット


18

TL; DR:構成可能製品に関連付けられている単純な製品が、構成可能製品自体と同じ属性セット内にある必要がある理由はありますか?つまり、技術的な理由はありますか?「常識」の理由を知っています。あなたは、一対販売している場合の靴を、色やサイズに応じて、すべてのバージョンはする必要がも。
長いバージョン:いくつかの設定可能な製品を「マージ」するタスクがありました。2つ以上から1つだけを作るということです。製品の量が多いため、手動でやりたくありませんでした。$product->load(..)->set...()->save()スクリプトの実行に時間がかかったためです。だから、単純な製品はどれも重なっていないと確信していたので、プロセスを短絡させた。サイズと色のユニークな組み合わせがありました。これは私がしました:

Mage::getResourceSingleton('catalog/product_type_configurable')
    ->saveProducts($mainConfigrableProduct, $simpleProductIds);

ここ$simpleProductIdsで、マージが必要な構成可能な製品すべてに関連付けられたすべての単純な製品IDの配列です。
これはほとんどの製品で完全に機能しましたが、問題のあるものがいくつかありました。
電話したら

$productIds = $product->getTypeInstance()->getUsedProductIds() 

私はすべての単純な製品IDを取得しますが、バックエンドにはそれらのほんの一部しか表示されません。しばらく掘り下げた後、表示されたのは構成可能な製品と同じ属性セットのものだけであることがわかりました。他の属性セットは最初の属性セットと非常に似ており、わずかな違いがありますが、構成可能な属性(サイズと色)が含まれています。
そして今、奇妙なこと。フロントエンドでは、すべての製品(上記のコードの$ productIds)または同じ属性セットの製品のみが表示されると予想していました。まあ間に何かがありました。

  • 20の関連製品ID-5つのサイズ、4つの色
  • バックエンドの10個の関連製品-5サイズ、2色-他の2色(10製品)は異なる属性セットにありました
  • フロントエンドで15の組み合わせ-5つのサイズ3色(???)

表示されなかった製品の属性セットを変更することで問題を解決できましたが、まだ困惑しています。

:自宅ではこれを試さないでください。または、自宅で試してみることができますが、ライブサーバーでは試せません。

回答:


13

これについて尋ねた後、私が持っている理由です。おそらくあなたが期待したものであったとしても、あなたにとって満足のいくものであることを願っています。

  1. adminhtmlインターフェースは、商人が完全に台無しにするのを困難にするために作られました。

そのため、Magentoがフレームワークとして提供している多くの機能は、ユーザーインターフェースでは使用できません。
同じ属性セットの製品のみが、構成可能製品の関連する単純な製品として選択できる理由は、それが仕様に含まれていたためです。
あなたが言ったように、それはそのように理にかなっています。

  1. 別の理由は、属性セットの目的を考えることです。それらが存在する理由の1つは、リクエスト中にロードおよび処理する必要がある属性とオプションの数を減らすことです。この考え方を構成可能変数に適用するのは理にかなっています。なぜなら、それは比較的リソースを消費する製品タイプだからです。

バックエンドがそのように構築されたため、設定可能のフロントエンドロジックは、異なる属性セットからの単純な製品を処理することを期待されていませんでした。
そのため、そこでは制限が完全に実装されていません。

おそらく、さまざまな属性セットのシンプルを使用して構成可能変数を簡単に機能させることができます。それはそのように意図されていませんでした。

私はこれ以上質問せず、どのコード相互作用がフロントエンドで奇妙な結果を正確に生成したかを自分で確認しませんでした。おそらく重要ではないでしょう。なぜなら、コードの説明ではなく、構成可能なものとは異なる属性セットから単純な製品を除外するという決定の背後にある理由を尋ねるところを正しく理解したからです。


ありがとう、Vinai。「心を吹き飛ばす」理由で、私は心の奥深くに望んでいました。楽しかったでしょう:)。これは満足のいく説明です。「奇妙な結果」については、コードを掘り下げる必要はありません。退屈したらそれをします。DBダンプがあり、同じ結果を再現する方法があります。最も可能性が高いのは、私がデータベースを直接ねじ込んだためです。結果が見つかった場合は、結果を投稿します。
マリウス

2
Tsk tsk、@ Marius-データベースには触れないでください;)
philwinkle

4
@philwinkle。宇宙は爆発すると爆発するでしょう。何と言えばいい?私は危険な生活をするのが好きです。私の防御では、「ライブサーバーでこれを試さないでください」と言いました。
マリウス

1
まだ私の心を吹き飛ばされるのを待っています... :)
ヴィナイ

2

インポートおよびエクスポートには、UnirgyのRapidFlowという拡張機能(これはあまりお勧めできません)を使用します。Proバージョンの機能の1つでは、属性セットを変更できます。もう1つは、CSVインポートによる製品の作成です。場合によっては、構成可能変数用の新しい単純な製品を作成しますが、偶然にこれらの単純な製品が親とは異なる属性セットを持っていることがあります。

Rapidflowはこれらの製品を喜んでインポートし、属性セットを変更します。結果に満足していない傾向があります。属性セット以外の属性によって構成された構成可能な製品は、製品管理でのレンダリングに失敗し、修復する必要があります。既に説明したように、親の属性セットを変更しない場合、子は単に親に適切に関連付けられません。それらはMagentoエンティティとして存在し、編集できますが、フロントエンド製品ページまたは構成可能な親の関連製品リストに子として表示されません。

そのため、純粋に技術的な観点から、単純な製品が親とは異なる属性セットに含まれることがあります。しかし、この動作はEEでもサポートされていないため、OccamのRazorは、Magentoの設計時にVarien開発者はその必要性を認識していなかったと述べています。


1
応答(および拡張機能の推奨)に感謝しますが、これは私の質問に答えません。データベースを直接変更することで問題を解決できたと言いました。私はそれをするべきではないことを知っていますが、私は何をしていたのかについて十分な知識がありました-データベースのバックアップ:)。この制限が存在する理由に興味がありました。「Varien開発者が必要性を認識しなかった」限り、あなたは間違っていると感じています。制限を実装する場合、それが理由であるに違いありません。
マリウス
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.