タグ付けされた質問 「magento-1.14」

私はMagento Enterprise 1.14.1.0のショッピングカート価格ルールをいじってみましたが、問題に遭遇しました。 定義されたカテゴリから3つのアイテムを購入し、15ポンド以上使った場合、10ポンドの割引が適用されるような単純なルールを作成しようとしました。以下の私の設定を参照してください。 私のバスケットには、IDのカテゴリーから3つのアイテムと、ID 5のカテゴリーから1つのアイテムがあります3。 このルールを有効にしてバスケットを表示すると、致命的なエラーが発生します。スタックトレースの一部を次に示します。ご覧のとおり、私はすでにxdebug.max_nesting_level恐ろしいレベルにまで引き上げています。 Fatal error: Maximum function nesting level of '18000' reached, aborting! in /dev/builds/1_14_1_0/lib/Varien/Object.php on line 344 Call Stack: 0.0003 348680 1. {main}() /dev/builds/1_14_1_0/index.php:0 0.0020 694956 2.Mage::run() /dev/builds/1_14_1_0/index.php:89 0.0068 1819640 3.Mage_Core_Model_App->run() /dev/builds/1_14_1_0/app/Mage.php:684 0.0509 9129168 4.Mage_Core_Controller_Varien_Front->dispatch() /dev/builds/1_14_1_0/app/code/core/Mage/Core/Model/App.php:354 0.0626 11074424 5. Mage_Core_Controller_Varien_Router_Standard->match() /dev/builds/1_14_1_0/app/code/core/Mage/Core/Controller/Varien/Front.php:172 0.0658 11765288 6. Mage_Core_Controller_Varien_Action->dispatch() …

8 magento-enterprise  shopping-cart-price-rules  promotions  enterprise-1.14  magento-1.14 

magentoレポート（具体的には、売上>注文レポート）では、現地時間で日数がバケット化されると予想していました。 これは、少なくともmagento 1.14.2.2では、そうではないようです。未加工の注文を注文レポートと比較すると、ローカルタイムゾーンではなくUTCでバケット化されているため、一部の注文がレポートで正しくバケット化されていないことがわかります。 タイムゾーンがシステムで正しく設定され、有効期間の統計が更新されました。 私はMagento 1.9.2.2を試してみましたが、結果はローカルのタイムゾーンによってバケット化されているようです。これは、構成の問題、またはおそらくバグの可能性があることを意味すると思いますか？ 誰でもこの問題を確認または拒否できますか？

7 magento-1.9  reports  magento-1.14 

問題： 製品の保存は過去12か月間で徐々に遅くなっています バックグラウンド： Magento Enterprise 1.14.1（この問題は1.13.0.2にも存在します） 〜15,000製品、〜700カテゴリ、2店舗 Solr 3.6 調査： 遅い製品の保存が問題になった後、遅いクエリログを調査したところ、同じクエリがポップアップ表示さ"UPDATE `catalogsearch_query` SET `is_processed`=0"れたことがわかりました。ローカルで同じクエリを実行すると、最大7〜10秒かかりました。 この遅いクエリの理由は、サイトが検索の負荷が高く、catalogsearch_queryテーブル内の400,000行を超える行がすべて0で更新されているためです。これは、MySQLテーブルに格納するのに大量のデータではありませんが、このような頻繁なイベントで更新する膨大な量。 プロセスのxdebugging後に問題をさらに悪化させるには、各製品の間にMagentoがMage_CatalogSearch_Model_Resource_Fulltext :: resetSearchResults（）メソッドを5回ヒットし、Enterprise_CatalogSearch_Model_Observer :: processProductSaveDeleteEvent（）を呼び出すcatalog_product_save_commit_afterイベントのバックを保存します。 したがって、5回* 3秒は、15秒が各製品の節約に追加されます。5回はやり過ぎに思われ、このオブザーバーによってトリガーされたプロセスの最後にresetSearchResults（）が何度も呼び出されるのは見落としのようです。 さらに調査するとis_processed、Solr統合が実施されている場合、データベースのこのフィールドはほとんど使用されないようです。 誰かがこの問題に遭遇しましたか？ どのような行動をとりましたか？ 近づくための提案はありますか？ 私の最初の考えは、プロセスを再構築して、その影響を完全に調査した後、catalogsearch_queryのクエリを削除することです。

7 product  solr  save  magento-1.14