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

私は、このテーブル自体が非常に乱雑になる可能性があるという大量のレポートに気付きました。私は〜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を実際に傷つけている可能性があると述べました。

105 magento-1  url-rewrite  core  bug 

Magentoストアをデバッグするにはどうすればよいですか これは今ではあまり関係のない質問ですが、5年前にMagento SEサイトが存在していた場合、おそらく最初の質問だったでしょう。Magentoを使い始めたばかりの人や、Magentoに慣れていない人にとっては、デバッグの基本を知ることが、問題の原因を除外するための鍵となります。そして、私たちとは無関係であるにもかかわらず、私たちはこの質問を自己回答のアプローチで先取りしています。 私のサイトがダウンしている助けて！ 私の設計に問題はありますか？ サードパーティのモジュールに障害がありますか？ エラーが表示されないのはなぜですか？ これらの質問のそれぞれは、最も基本的なユーザーでも完了できるデバッグへの標準化されたアプローチに従うことにより、容易に回答できます。Magentoストアのデバッグの基本を排除するプロセスによって。

81 extensions  core  debug  theme 

この質問には2つの部分があります。 コアモジュールを無効にすると、ストアの全体的なパフォーマンスが向上しますか。その場合、管理で無効にする（フロントエンド出力を無効にする）か、このパフォーマンスの改善を確認するにはconfig.xmlで無効にする必要があります。 パフォーマンスの改善が必要な場合、ストック上のどのモジュール、CE 1.7.0.2ビルドは、パート1で回答した方法で安全に無効にできます。

27 module  performance  core 

注：PHPコードを使用して製品を編集している場合は、管理者でインデックスを再作成し、以下のように表示されない理由を考えて時間を節約してください... 私はis_salable、製品にどのように設定されているかを理解しようとしているので、私の製品が現在表示されている理由を理解しようとしています。 私が見つけることができるコードには、それを設定する場所が1つしかありません： $salable = $this->isAvailable(); しかし、私は方法や場所、この私が続く場合など、から取得して動作することはできませんisAvailable....それだけで戻って周りにループに思えます /app/code/core/Mage/Catalog/Model/Product.php public function isSalable() { Mage::dispatchEvent('catalog_product_is_salable_before', array( 'product' => $this )); $salable = $this->isAvailable(); $object = new Varien_Object(array( 'product' => $this, 'is_salable' => $salable )); Mage::dispatchEvent('catalog_product_is_salable_after', array( 'product' => $this, 'salable' => $object )); return $object->getIsSalable(); } ここから$ this-> isAvailable（）に続いて、数行進みます： **public function isAvailable() …

27 catalog  core 

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

23 magento-1  core  bug 

この問題はよく知られています。libクラスはオートローダーを介して排他的にロードされ、次のもの以外は変更できません。 libより前にチェックされるcodePoolにそれらを完全にコピーします。 PSR-0オートローダーをインストールし、オートロードクラスマップを指定し、代わりにファイルをそのフォルダー構造に完全にコピーします。[私の現在の解決策] これらのファイルの多くに潜在的に触れたいので、私は困難な状況にあります-しかし、ストアの健全性と安定性/アップグレード性のために、ライブラリクラス全体をコピーしたくありません。 現在、明らかにこの問題には潜在的な解決策がありますが、それらにはすべて独自の問題があります： 行くAOPのルートをとのようなPHPベースのライブラリを使用してゴー！AOP：最後に確認したのは、Magentoクラスが1つだけではなく、コンポーザーオートローダーによってロードされる必要があることです。Flyingmanaはこの分野でいくつかの作業を行いましたが、本番環境で使用する準備ができていないことは間違いなく、私のニーズはより迅速です。また、拡張機能として出荷したいのですが、これにはより多くの作曲家の設定が必要になります。 AOPルートに進み、ネイティブPHP拡張機能を使用します。おそらく現時点で最も有利ですが、HHVMで動作しないことは言うまでもなく、別の拡張機能をインストールする必要があります。 PHPのクラスキットおよび/またはrunkitを使用します。これは別のネイティブPHP拡張であるため、上記と同じ問題があります。 コールサイトにパッチを適用して、独自の名前空間（\Danslo\Varien_X）バージョンを使用し、元の（）バージョンから拡張し\Varien_Xます。パッチを当てるコールサイトが多すぎます。オプションではありません。 自分で転がす：できること： 独自のオートローダーを作成します。 元のクラスを別のフォルダー（{root_dir}/var/tmp）にコピーし、ラップしnamespace \Magento { < original contents > }ます。 そのファイルを含めます。 変更したクラスを含める OriginalClass extends Magento\OriginalClass {} これの欠点は明らかです。動的コード生成、正規表現、書き換えられたクラスをロードするための少しのオーバーヘッド。しかし、この時点で、〜100行をタッチ/追加したいだけで、〜5000行のコードをコピーするのに勝ると確信しています。 私は多くを求めていることを知っていますが、この問題を解決するのに役立つ現代的で比較的きれいなものがありますか？

21 overrides  core 

ページの実行時間を測定したところ、関数getBaseCurrencyCode（）が実行に1秒以上かかることがわかりました。すべてのキャッシュが有効になっています。 私は関数を調べて、次のコマンドを見ました： $this->getConfig(Mage_Core_Model_Store::XML_PATH_PRICE_SCOPE) 秒かかります。 しかし、私が使用するとき、 Mage::getConfig()->getNode(Mage_Core_Model_Store::XML_PATH_PRICE_SCOPE); それはミリ秒かかります なぜこの時間差が発生するのですか？ 何かアドバイス？ 提案された解決策を試しましたが、まだ大きな時間差があります。getConfig関数を実行してここに投稿するのにかかる時間を試して測定していただければ幸いです。 このコードをマイクロタイム関数でラップして、この関数にかかる時間を測定しようとしました すなわち、ローカルパス上：app\code\core\Mage\Core\Model この行の代わりに： $configValue = $this->getConfig(Mage_Core_Model_Store::XML_PATH_PRICE_SCOPE); 次のコードに置き換えました（microtimeと同じコード）： $start = microtime(true); $configValue = $this->getConfig(Mage_Core_Model_Store::XML_PATH_PRICE_SCOPE); $time_elapsed_secs = microtime(true) - $start; echo "function: getConfig() took me: " . $time_elapsed_secs . " sec<br />"; die; 私の出力は： function: getConfig() took me: 1.1326711177826 sec 出力とランタイムを確認できたらうれしいです。

12 magento-1.9  core  getmodel 

メッセージブロックのphtmlファイルを変更しようとしています。基本テーマで見つけて、template/core/messages.phtmlそれを自分のテーマにコピーして、変更を加えました。私の変更は表示されなかったため、ベースファイルのソースを変更しようとしましたが、変更はまだ適用されませんでした。 このテンプレートファイルはどこにありますか、またはどのように上書きできますか？

12 magento-1.7  template  magento-enterprise  core 

ロックされています。この質問とトピックへの回答はロックされています。質問はトピックから外れていますが、歴史的に重要です。現在、新しい回答や相互作用を受け入れていません。 Magentoのコアで使用されている非常に明白なパターンがいくつかあります。 シングルトン レジストリ イベント/オブザーバー 工場 モデル/ビュー/コントローラー しかし、アクター、デコレーター、ストラテジーパターンなど、私が知らないMagentoで使用されているものもあります。 Magentoのすべてのパターンタイプの使用法のリファレンスリスト、またはMagentoの組み込み機能を不必要にレプリケートしないサードパーティのモジュールに実装する方法はありますか？

10 programming  core 

カスタムテーマのvendor / magento / magento2-base / lib / web / css / source / lib / _navigation.lessファイルを上書きするにはどうすればよいですか？

9 magento2  theme  overrides  core  less-css 

構成可能な物理製品を販売するショップがあります。私たちはカスタムの支払いプロバイダー（独自の拡張機能）を使用しており、ストアはヨーロッパにあります。 厄介な副作用なしに無効にできるコア拡張機能は何ですか？ 魔法使い Mage_Authorizenet Mage_Downloadable Mage_Authorizenet Mage_GiftMessage Mage_GoogleCheckout 魔道士ペイゲイト 魔道士 魔法使い 魔道士_ウィー フェニックス_マネーブッカーズ ありがとう!!

9 admin  core 

Magentoの速度を最適化することを考えるとき、サイトを高速化するためのキャッシング（PHP、データベース、さらには全ページキャッシュ）のようないくつかの可能性があります。 別の可能性は、実行される処理の量を減らすことです。つまり、ショップで実行されているモジュールの数を減らすことです。 最近、私はMage_Reportsモジュールを非アクティブ化することが可能/安全かどうか疑問に思っています。 これは、ファイルにあるapp/etc/modules/Mage_All.xmlよう <Mage_Reports> <active>true</active> <codePool>core</codePool> <depends> <Mage_Customer/> <Mage_Catalog/> <Mage_Sales/> <Mage_Cms/> </depends> </Mage_Reports> したがって、コアにバンドルされており、他のいくつかのモジュールに依存しています。 しかし、Mage_Reportsが依存関係にある他のモジュールが表示されません。 テストストアで無効にしたところ、すべて正常に動作しているようです。 質問=>確かに、レポートデータが失われるだけでなく、このモジュールがなくてもストアは正常に実行できますか？ または、このモジュールがアクティブ化されていないときにストアが壊れるポイントはありますか？

7 performance  core  reports