タグ付けされた質問 「bug」

Magentoの(疑わしい)バグに関する質問。独自のコードの拡張機能やバグの問題に「バグ」タグを追加しないでください。

13
Magento core_url_rewriteテーブルが大きすぎる
私は、このテーブル自体が非常に乱雑になる可能性があるという大量のレポートに気付きました。私は〜5000 SKUと〜250カテゴリ(単一ストア)でサイトを運営しており、結果としてcore_url_rewrite600,000行を超え、500MB以上のテーブルがあります非常識です。 これにより、サイトのパフォーマンスが低下し、データベースが非常に大きくなる可能性があります。私はいくつかの掘り下げを行ったが、これに関するかなりの数の投稿を見つけました。 Core_url_rewriteのバグ:インデックスで生成された各製品の膨大な量の重複したURL Magento Commerce-バグ追跡-問題#29020 //これらのリンクは、新しいボードの実装以降に削除されました これでテーブルの切り捨てとインデックスの再作成ができることがわかりましたが、これでは問題は解決せず、問題が再発するのを長引かせるだけです。 私が理解していることから、問題の一部は、製品の名前に基づいて同じURLキーを持つ製品であり、その結果、インデックス付きリンクになります。 記載されている修正は次のとおりです。 app/code/core/Mage/Catalog/Model/Url.php 〜807行目: 変化する: if ($product->getUrlKey() == '' && !empty($requestPath) && strpos($existingRequestPath, $requestPath) === 0 ) に: if (!empty($requestPath) && strpos($existingRequestPath, $requestPath) === 0 ) しかし、これでも問題を完全に解決するわけではありません。 私の質問は次のとおりです。 この問題が発生した場合、問題を繰り返し「管理」することなく、実際に問題を完全に解決する効果的で論理的かつ効率的なアルゴリズムを設定できましたか? う、本当にこのいくつかの洞察を感謝しています。 ところで:あなた自身に感謝し、あなたのテーブルが今どのように見えるか確認してください。あなたはそれを知らずにこの問題とその結果としてのパフォーマンスの影響を経験しているかもしれません-私は知りませんでした。 編集:www.Nexcess.net(Magentoプラチナホスティングパートナー)と連絡を取り合っており、core_url_rewriteかさばる結果としてテーブルの切り捨てが必要であるとクライアントから要求されていることを確認しました。 私の大きな心配は、これが持つ可能性のあるSEOの影響です。そのため、問題が再び発生するのを先延ばしにするのではなく、解決策が欲しいのです。 更新: Nexcessは、テーブル内の製品が重複しているため、SEOを実際に傷つけている可能性があると述べました。

1
EAVとタグの部分的な再インデックス付けがないのはなぜですか?
この質問はかなり長い間私を困惑させていました。 Magento 1.13.xxで導入された改善バグ修正が、部分的な再インデックス付けと呼ばれ、「製品属性」および「タグ集約データ」インデクサーをカバーしないのはなぜですか?なぜこれら2つは手動で再インデックス付けする必要があるのですか? 私の意見では、EAVインデックスは最も重要なものの1つです。部分的なインデックス再作成がないことは、各販売(および一部の人々がそれらを持っている)後にインデックスが無効になることを意味します。 明らかな何かが欠けていますか? 更新: だからここにこのバグの説明があります。販売が行われ、製品の在庫がなくなると、階層化されたナビゲーションは、構成可能な製品ではなく、単純な製品の製品属性の変更を反映します(バンドルおよびグループ化はテストしていません)。 したがって、カタログに、さまざまなサイズで利用可能なTシャツのような構成可能な製品があり、「サイズ」属性が「フィルター可能(結果付き)」であると仮定しましょう。次に、適切なカテゴリまたは検索結果の階層化されたナビゲーションに、使用可能なすべてのサイズがリストされているサイズセクションがあります。いずれかの販売後に特定のサイズが在庫切れになると、階層ナビゲーションから消えることが予想されます。これは、属性インデックスを更新し、ブロックキャッシュをフラッシュしない限り発生しません。 このバグは本当に重大です。これは双方向の脅威です。まず、階層化されたナビゲーションで自分のサイズを確認し、実際には利用できないことに気づいたエンドカスタマーは、フラストレーションであなたの店を離れます。さらに悪いことは、製品が在庫に戻ったら、階層化されたナビゲーションでは表示されないため、最終顧客が購入できないことです。したがって、収益の損失額を過小評価することは困難です。

5
Mage_Catalog_Model_Resource_Product_CollectionにストアIDを設定する方法は?
タスクは簡単です。フラットカタログを有効にして、特定のストアビューの製品のリストを取得する必要があります。最も明白な解決策は次のとおりです。 $collection = Mage::getResourceModel('catalog/product_collection') ->setStore($storeId); 実際、setStore()メソッドはストアIDに基づいてフラットテーブルの名前を取得する_initSelect()メソッドの後に呼び出されるため、ここでは何の違いもありませんMage_Catalog_Model_Resource_Product_Collection。ストアIDはまだ設定されていないため、現在のストアIDが使用されます。 したがって、明らかな回避策は、モデルを取得する前に現在のストアIDを設定することです。 Mage::app()->setCurrentStore($storeId); $collection = Mage::getResourceModel('catalog/product_collection'); それが動作します。ただし、コレクションを1回取得する必要がある場合のみ。ループ内でコレクションを取得する必要がある場合、または2つのバックツーバックコレクションだけが必要な場合は、コレクションに特定のストアを設定できません。 その理由は Mage_Catalog_Model_Resource_Product_Flatクラスには独自の_storeIdプロパティがあり、コンストラクターでは現在のストアIDに設定されるためです。それが最初に設定される理由です。それから、何らかの理由で(天国は私が希望していることを知っていMage_Eav_Model_Entity_Collection_Abstract::_initます)、各リソースモジュールはシングルトンとしてフェッチされます。したがって、2回目の呼び出しのコンストラクタはありません。 これはすべて非常に間違っているように見えるので、私は間違っていると確信しており、Magentoの別のバグ(または2つ)ではありません。誰かがそれに光を当てることを願っています。

6
Mage :: log()が新しいMagentoアップデート(1.9.4.1)で機能しない
この新しい更新(1.9.4.1)の後、Mage :: log()は機能しません。どうやら、それはZend_Validate_File_ExtensionMage.phpの819行目と関係があるようis_readable()です。log()メソッド全体を以前のバージョンに戻し、再び機能します。 この問題を報告するためにMagentoチームに連絡できるメインチャンネルは何ですか?

1
閉じられる可能性が高いように、Magentoのバグを報告してバグ修正を送信するにはどうすればよいですか?
Magento 1.xでバグを見つけ、バグ修正も見つけました。どこで報告しますか?Magentoのコア開発者がそれを見る機会はどこにありますか?Magentoのバグトラッカーは無視され、(例えば参照メンテナンスされていないことのようです。この問題を)。 実際にパッチを提出するためにMagento Contributor Agreementに署名できますが、これらのパッチでさえしばしば拒否されると聞きました。それでは、Magentoコアにパッチを適用する他の方法はありますか? GitHubの上のMagentoの2、すべてが良くなっているようです。しかし、Magento 1のバグ修正のための場所もあるべきだと思います...
23 magento-1  core  bug 

2
Magento 1.9.2.0:テーブル「sales_flat_order_grid」には、顧客の名前の値に余分なスペースが含まれています
管理パネルで、顧客名に基づいて注文を検索する場合、名と姓の間に2つのスペースを追加する必要があります。Inspect elementウィンドウで値を見ると、値に余分なスペースが表示されていることに気付きました。どうすれば修正できますか?

4
Magento 1 EE v 1.14.3.x(およびCE 1.9.3.x)でのセッション検証の失敗
400〜500人の訪問者と1日あたり40〜50件の注文があるMagentoショップを探しています。最近、システムがMagento EE 1.14.2.4からMagento EE 1.14.3.2にアップグレードされ、ログに奇妙な例外がいくつかあることに気付きました。 exception 'Mage_Core_Model_Session_Exception' in /var/www/.../app/code/core/Mage/Core/Model/Session/Abstract/Varien.php:418 私はその例外を追いかけていましたが、次のセッション検証コードがセッションの検証に失敗したため、例外が発生していることを知っています。 class Mage_Core_Model_Session_Abstract_Varien extends Varien_Object { // ... protected function _validate() { // ... if ($this->useValidateSessionExpire() && isset($sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP]) && $sessionData[self::VALIDATOR_SESSION_EXPIRE_TIMESTAMP] < time() ) { このifブロックは、Magentoからの最新リリースでファイルに追加されました。これは明らかにブレーキの変更です。詳細は以下をご覧ください。 例外は非常に頻繁に発生し、1日に数十回です。しかし、上記の条件に文字通りtrueを設定しない限り、例外につながる条件を再作成することはできません。例外はほとんどの場合、製品詳細ページと1ページのチェックアウトの最後のステップで発生します。ショップはb2bショップです。製品ページを表示したり、チェックアウトしたりするには、ユーザーがログインする必要があります。つまり、セッションが無効化/期限切れになると、ユーザーはログインページにリダイレクトされます。現時点では、チェックアウト中にこの問題を修正することがより重要です。 ユーザーの観点から何が起こるか:ユーザーはカートを満杯にし、チェックアウトに進み、最後のステップに進み、「注文を送信」ボタンを押しても何も起こりません。舞台裏では、MagentoのJSはAJAXリクエストを実行し、JSはJSONを受信することを期待していますが、このエラーが発生するとログインページのHTMLが返され、JavaScriptで解析できず、何もしません。これはユーザーにとっては非常に紛らわしいです。 まあ、それは完全なユーザーシナリオではありません。ユーザーに連絡し、カートに入れて注文を送信するまでに数日待っていたと伝えました。人々は単にそれを覚えていないので、正確に何を意味するのかわかりません。 PHPセッションの有効期間-350000(秒で最大4日)Cookieの有効期間-345600(4日) 実際の質問は次のとおりです。 どのようなユーザーの行動が例外につながるのかをどのように見つけることができますか? 更新 これまでのところ、リクエストに応じて次のクラスで例外が発生することを知っていますが、残念ながら何も意味しません。 /catalogsearch/result/?q=… Mage_Core_Model_Session /checkout/cart/ Mage_Core_Model_Session /checkout/onepage/saveOrder/… Mage_Rss_Model_Session /customer/account/loginPost/ Mage_Core_Model_Session …

4
EE 1.14.2 / CE 1.9.2:引用アイテムがログイン時に正しくマージされない(カート内の製品が重複する)
Magento EE 1.14.2(CE 1.9.2にも影響します)で、カートに関する奇妙なバグを見つけました。 再現する手順: 顧客Aとしてログインします 製品Xをカートに追加します 別のブラウザに切り替える 製品Xをカートに追加します 顧客Aとしてログインします 予想されるカート: 2 x製品X 実際のカート: 1 x製品X 1 x製品X つまり、製品はマージされません。 ブラウザを切り替える代わりに、セッションCookieをクリアするか、製品に別の数量を選択することもできます。 これの最悪の副作用は、アイテムごとに最大注文数量が適用されることです。私の場合、製品には100%の割引がありましたが、一度しか注文できませんでした。この小さなトリックを使用すると、無料で任意の数量で注文できます。 なぜこれが起こり、どうすればそれを防ぐことができますか?

3
PHP 5.5のバグ-非推奨の機能:preg_replace()
PHP 5.5にアップグレードした後、Webサイト、ストア、またはストアビューを追加すると、次のエラーが表示されます。このバグはMagento 1.9.0.1にまだ存在しています Exception message: Deprecated functionality: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in app/code/core/Mage/Core/Helper/Abstract.php on line 238 Trace: #0 [internal function]: mageCoreErrorHandler(8192, 'preg_replace():...', 'app...', 238, Array) #1 app/code/core/Mage/Core/Helper/Abstract.php(238): preg_replace('# <(?![/a-z]) |...', 'htmlentities('$...', 'New Store Name') #2 app/code/core/Mage/Adminhtml/controllers/System/StoreController.php(175): Mage_Core_Helper_Abstract->removeTags('New Store Name') #3 app/code/core/Mage/Core/Controller/Varien/Action.php(418): Mage_Adminhtml_System_StoreController->saveAction() #4 app/code/core/Mage/Core/Controller/Varien/Router/Standard.php(250): Mage_Core_Controller_Varien_Action->dispatch('save') …
16 bug  php-5.5 

2
「フロントコントローラーが100回のルーター一致の反復に達した」エラーの原因は何ですか?
Magentoの開発者として私はこの問題に何度も直面しましたが、いくつかのモジュールがロードされず、ルーターもエラーが発生した場合、それが設定ミスの問題であることを知っています。ほとんどの場合、アクションなしで解決されますが、キャッシュをフラッシュする場合もあります これについて複数の投稿を読んで、Magento coreフロントコントローラーapp/code/core/Mage/Core/Controller/Varien/Front.phpに追加のコードを配置してデバッグしようとしましたが、最後に、モジュールルーターが見つからない理由のみを表示します。それが発生するたびに、どのURLがエラーを発生させているかを確認しようとしますが、これはコードトレースと同じ役に立たない情報です。いつも同じです モジュールの競合が原因である可能性がありますか?たぶんそれは何か間違ったことをしているcronタスクですか?たぶん古いMagentoバージョンのいくつかの間違ったコード?問題は、この問題はバージョン1.7以降では発生しないことです(発生した場合は完全に散発的です)。メインフローには、次のようないくつかのコードの違いがあります。 Mage::register('application_params', $params); のrun()メソッドapp/code/core/Mage/Core/Model/App.php、または $this->_shouldSkipProcessModulesUpdates() _initModules()メソッドをチェックイン... 原因を明確に見つけた人がいるはずだと信じたい。任意のヒント?


1
管理構成:選択した複数選択値に応じてフィールドを表示
選択された複数選択入力に基づいてフィールドを表示したい...値が1つしか選択されていない場合、次のコードは正しく機能します。複数の値を選択すると、1つのフィールドのみが表示されます(最初にソースモデルから選択) <enabled> <label>Enabled</label> ... <source_model>adminhtml/system_config_source_enabledisable</source_model> </enabled> <!-- this gives three options - shop, ebay, amazon --> <channels> ... <frontend_type>multiselect</frontend_type> <source_model>module/system_config_source_channels</source_model> <depends> <enabled>1</enabled> </depends> </channels> <mail_template_shop> ... <depends> <enabled>1</enabled> <channels>shop</channels> </depends> </mail_template_shop> <mail_template_ebay> ... <depends> <enabled>1</enabled> <channels>ebay</channels> </depends> </mail_template_ebay> 関連コード: app / code / core / Mage / Adminhtml / Block …

1
Magento Enterpriseのバグを報告するにはどうすればよいですか?
Magento Enterprise 1.13のウェブサイト制限と1ページチェックアウトのバグを発見しました。回避策を開発中ですが、バグチケットも送信したいと思います。 バグを報告しようとすると、利用可能なバージョンはCommunity Editionに限定されます。エンタープライズのバグを報告するための正しいプロセスは何ですか?

3
データURIとCSSファイルのマージに関する問題
Mage_Core_Model_Design_Package(beforeMergeCss)のRegExが期待どおりに機能しないため、Magento CSSファイルのマージはホスト名を私のdata-urisに見せかけています。ホスト名を相対画像パスの前に付加する必要がありますが、データURIの前には付加しません。 $cssUrl = '/url\\(\\s*(?!data:)([^\\)\\s]+)\\s*\\)?/'; $contents = preg_replace_callback($cssUrl, array($this, '_cssMergerUrlCallback'), $contents); CSSコード: background: #fafafa url("data:image/svg+xml;base64, PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZlcnNpb249IjEuMSIgeD0iMHB4IiB5PSIwcHgiIHdpZHRoPSI2cHgiIGhlaWdodD0iM3B4IiB2aWV3Qm94PSIwIDAgNiAzIiBlbmFibGUtYmFja2dyb3VuZD0ibmV3IDAgMCA2IDMiIHhtbDpzcGFjZT0icHJlc2VydmUiPjxwb2x5Z29uIHBvaW50cz0iNS45OTIsMCAyLjk5MiwzIC0wLjAwOCwwICIvPjwvc3ZnPg==") no-repeat; マージ後の結果: background: #fafafa url("http://shop12.dev/skin/frontend/shop/default/styles/data:image/svg+xml;base64")PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZlcnNpb249IjEuMSIgeD0iMHB4IiB5PSIwcHgiIHdpZHRoPSI2cHgiIGhlaWdodD0iM3B4IiB2aWV3Qm94PSIwIDAgNiAzIiBlbmFibGUtYmFja2dyb3VuZD0ibmV3IDAgMCA2IDMiIHhtbDpzcGFjZT0icHJlc2VydmUiPjxwb2x5Z29uIHBvaW50cz0iNS45OTIsMCAyLjk5MiwzIC0wLjAwOCwwICIvPjwvc3ZnPg==") no-repeat; これを回避するには?使用したRegExのシンタックスを修正する方法を見つけることができませんでした。(GIFを使用することは私にとって実際の解決策ではありません)
9 magento-1.8  css  bug  regex 

1
構成はフロントモデルとバックエンドモデルに「依存」します
構成の「依存」機能に問題があります。 通常、<depends>いくつかの構成オプションに追加されますが、指定されたオプションの値が一致しない限り、それは非表示になります。 例えば: <option_one> <label>Option 1</label> ... </option_one> <option_two> <label>Option 2</label> ... <depends><option_one>1</option_one></depends> </option_two 明らかに、いくつかのフィールドが欠けていますが、要点はわかります。オプション2は、オプション1の値が「1」の場合にのみ表示されます。 私の問題は、これをバックエンドモデルとフロントエンドモデルのオプションに適用しようとすると、これに依存しないことです。 <option_three> ... <frontend_model>module/adminhtml_form_field_test</frontend_model> <backend_model>adminhtml/system_config_backend_serialized_array</backend_model> ... <depends><option_one>1</option_one></depends> </option_three> このオプションはオプション1を考慮せず、常に表示されるだけです。 私は何か間違っているのですか、それともバグですか、それとも「設計どおりに機能する」のですか?

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.