タグ付けされた質問 「best-practice」

最近、無料の商用拡張機能で多くの問題が発生したため、この質問をして、拡張機能を作成するときに通常実行する手順で回答することにしました。回答を編集するか、新しい回答を追加してください。 拡張機能またはテーマをインストールするほとんどの場合、必要なすべての環境で機能させるために数時間（場合によってはそれ以上、場合によってはそれ以下）を費やす必要があります。 dev：通常localhost、プロジェクトはサブフォルダーにあります preprod＆live これは大きくても、拡張プロバイダからの拡張機能（それは私が本当に怒る少なくともまでは無名のまま、ここに自分の名前を追加する必要があります）で起こっている ので、品質を確保するための拡張を書くとき、私は検討すべき段階is..what主な質問技術および非技術者がコードを使用し、技術者がコードを変更するのを容易にしますか？

143 module  magento-1  extensions  best-practice  development 

それでは、昨日、Magentoコミュニティの他の人たちとinクラス/テンプレートの直接的な使用ObjectManagerに関して大きな話をしました。 Alan Kentを引用して、ObjectManagerを直接使用しない理由をすでに知っています。 いくつかの理由があります。コードは機能しますが、ObjectManagerクラスを直接参照しないことがベストプラクティスです。 そう言うから！;-)（一貫性のあるコードは良いコードとして表現される方が良い） コードは、将来、異なる依存性注入フレームワークで使用される可能性があります テストが簡単になります。モックObjectManagerを提供することなく、必要なクラスのモック引数を渡すことができます。 依存関係をより明確に保ちます -コードの途中で依存関係を非表示にするのではなく、コンストラクターリストを介してコードが依存するものが明らかです カプセル化やモジュール化などの概念をプログラマーがよりよく考えるように促します -コンストラクターが大きくなった場合、コードがリファクタリングを必要とする兆候かもしれません StackExchangeで私が見たものから、多くの人々は、たとえば次のような簡単/短い/推奨されない解決策を求める傾向があります。 <?php //Get Object Manager Instance $objectManager = \Magento\Framework\App\ObjectManager::getInstance(); //Load product by product id $product = $objectManager->create('Magento\Catalog\Model\Product')->load($id); 痛みを伴うが推奨されるプロセスを経る代わりに： モジュールを作成する 設定の宣言 依存関係を注入する パブリックメソッドを宣言する ただし、ジレンマが発生します。Magento2コアファイルは、多くの場合ObjectManagerを直接呼び出します。ここに簡単な例があります：https : //github.com/magento/magento2/blob/develop/app/code/Magento/GoogleOptimizer/Block/Adminhtml/Form.php#L57 だからここに私の質問があります： なぜMagentoは私たちにしないことを勧めているのですか？それは、ObjectManager直接使用する必要がある場合があることを意味しますか？もしそうなら、それらのケースは何ですか？ ObjectManagerを直接使用した結果はどうなりますか？

134 magento2  best-practice  object-manager 

Magento 2でいくつかのチュートリアルを行ったところ、少し混乱しました。基本的に、ビジネスエンティティを読み書きできる方法は2つあります。 データを取得する 工場アプローチの使用 $object = $this->myFactory->create(); $object->load($myId); リポジトリアプローチの使用 $repo = $this->myRepository(); $object = $repo->getById($myId); データを保存する 工場アプローチの使用 $object = $this->myFactory->create(); $object->load($myId); $object->setData('something', 'somethingDifferent')->save(); リポジトリアプローチの使用 $repo = $this->myRepository(); $object = $repo->getById($myId); $object->setData('something', 'somethingDifferent'); $repo->save($object); 依存関係注入を使用して、リポジトリとファクトリクラスの両方を注入できることもわかります。これは少なくとも私にとって混乱を招きます。 リポジトリアプローチとファクトリアプローチはいつ使用する必要がありますか？従う必要があるベストプラクティスは何ですか？

75 magento2  best-practice  factory  repository 

Magento Development（CE 1.6）を初めて使用しますが、ワークフローを定義しようとしています。現在、Netbeans 7.3を搭載したMac OSX 10.8で開発していますが、Netbeansが遅く、フリーズすることがわかりました。Sublime Text 2に切り替えてファイルをすばやく表示/編集する傾向があります。または、便宜上Vimをプルアップすることもあります。 私の質問： 「最新のMagento 1.Xワークフローはどのようなものですか？」 「Magento開発に最適なツール/構成/プラグインはどれですか？」 これは主観的なものであり、「すべてを支配する1つのワークフロー」になることはありませんが、認定/経験のある開発者全員に共通の選択肢があると思います。少なくとも、私はいくつかの戦いでテストされた知識を期待しています。 入力/フィードバック/提案をいただければ幸いです。 ありがとうございました！

53 magento-1  best-practice 

Magento 2をヘッドレスEコマースソリューションとして使用するためのベストプラクティスがあるかどうかを知りたい。 2017年の典型的なEコマースは、以下を含むオムニチャネルソリューションを持つことです。 Eコマース CMS マルチプラットフォーム 階層システム統合（ERP、...） この種のソリューションにMagento 2 APIがどのように関与するかを知りたいです。 私のアプローチ： デスクトップ/モバイルWebアプリとモバイルアプリに別のフロントエンドフレームワーク（角度など）を使用する Eコマースのデータ/アクションを取得または操作するには、Magento 2 APIのみを使用してください CMSデータを取得するには、CMS APIのみを使用してください。 プロ： APIのみ、オムニチャネル 短所：パフォーマンス/機能/フォーマットの制限 このアプローチに関するいくつかの質問： 価格などのデータのフォーマットを担当するのは誰ですか。Magento APIとフロントエンドフレームワーク？ 製品画像のサイズ変更とキャッシュを担当するのは誰ですか？ネイティブMagento 2 APIには、サイズ変更またはキャッシュシステムがないためです。 将来のアップグレードのために、新しいカスタム分離APIを作成するか、ネイティブを拡張する必要がありますか？ CMSとMagento APIを組み合わせるために追加のレイヤーを使用することをお勧めしますか？ 経験を積んでいただければ幸いです。 さらに、このアプローチを見つけました：http : //fbrnc.net/blog/2015/10/super-scaling-magento 便利なリンク： https://blogi.lamia.fi/verkkokaupat/headless-ecommerce/ http://www.magetitans.it/headless-new-buzzword-magento-2-sander-mangel/ https://www.youtube.com/watch?v=6OuzAtqtWRE https://pantheon.io/blog/headless-websites-whats-big-deal-decoupled-architecture http://buytaert.net/the-future-of-decoupled-drupal https://creately.com/diagram/example-v2/ihbyjjkf/Example%20Headless%20Architecture https://www.lullabot.com/articles/should-you-decouple https://alankent.me/2016/12/14/headless-magento-and-extensions/ 編集： Magento 2 APIの独自のキャッシュロジックを作成するための優れたブートストラップを見つけました：https : //github.com/magespecialist/m2-MSP_APIEnhancer 編集： Magento …

48 magento2  api  best-practice 

次のすべての方法がMagentoコアで使用されていますが、どの方法が好ましい（または最新の「ベストプラクティス」）方法でしょうか。 Mage::throwException('Some Message')- 732の用途 throw new Exception('Some Message')- 419の用途 throw Mage::exception('Vendor_Module', 'Some Message')- 94の用途 （作成する必要Vendor_Module_Exceptionクラス）

45 error  best-practice  exception 

IDのみを指定して製品のURLを取得する最も効率的な方法は何ですか？コードのいくつかの場所にMage::getModel('catalog/product')->load($id)->getProductUrl()は、製品のURLを取得するため、製品に関連するイベントの量などを考えると、これはかなり無駄に思えますが、もっと簡単な方法はありますか？カテゴリIDも指定できると便利です。 さらに、名前などの製品の単一の属性に対して同じことを行うための効率的な方法はありますか？

27 product  magento-1  url  performance  best-practice 

インターネットとサードパーティのモジュールで矛盾する情報がいくつかあります- $thisオブザーバーメソッドの最後に戻ることは要件ですか、それともベストプラクティスですか？ 例えば： MyCompany_Module_Model_Observer.php public function salesOrderSaveAfter($observer){ //do stuff return $this; }

27 programming  event-observer  best-practice 

Magentoのヘルパーとは何ですか？ どのような場合にヘルパーを使用する必要がありますか？

22 helper  best-practice  mvc 

Varien_Object（M1）およびDataObject（M2）のマジックゲッターは一般的な方法ですが、Magento 2では使用するのが間違っているように感じます。 良い： 読み書きが簡単 悪い キーに数字を使用すると問題が発生します（Magento 2：コレクションのフィールドを取得する別の方法、またはラクダケースを使用してカスタム製品属性を取得するを参照）。 コード分​​析ツールが存在しないメソッドについて文句を言う 質問 Magento 2には、2つの新しいメソッドがあります。 getDataByKey($key) getDataByPath($path) まだ使用する正当な理由getData($key)や魔法のゲッターはありますか？ 編集： @Vinaiありがとう。@method私のアプローチはかなり異なっていたので、私は方法に言及しませんでした。 IDEに役立つだけで、他のものには影響しません。 いくつかのmergedf PRがあります。これは、ループの(int)代わりにキャストしintval()たり、ループの外に配列サイズを取得したり（小さな配列であっても）するような「マイクロ最適化」です。 一方、 マリウスが説明したように、いくつかの「オーバーヘッド」を持つ魔法のゲッター.... strtolower(trim(preg_replace('/([A-Z]|[0-9]+)/', "_$1", $name), '_')); getData($key) mehtodsも2-3の追加チェックが必要です... if ('' === $key) { if (strpos($key, '/')) { if ($index !== null) { 独自のコードの場合、実際のメソッドを好むことに完全に同意しますが、同じケースではおそらくそうではありません...たとえば、カスタムイベントを作成しました... $value = $observer->getVar_1(); $value = $observer->getData('var_1'); $value = …

21 magento2  best-practice  coding-standards  code-analysis  magic-getter 

たとえば、Magento 2拡張機能を構築しているとしましょう。それは非常に素晴らしいものを行うとしましょう。 しかし、他の開発者が拡張できるように、これが適切な標準を使用してビルドされることを確認したいと思います。 インターフェイスと組み合わせてDIを使用する必要がある場合と使用しない場合 ここでそれを明確にするのがコア例です。 クラスにMagento\Core\Helper\Dataは、次のようなコンストラクターがあります。 public function __construct( \Magento\Framework\App\Helper\Context $context, \Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig, \Magento\Store\Model\StoreManagerInterface $storeManager, \Magento\Framework\App\State $appState, PriceCurrencyInterface $priceCurrency, $dbCompatibleMode = true ) { parent::__construct($context); $this->_scopeConfig = $scopeConfig; $this->_storeManager = $storeManager; $this->_appState = $appState; $this->_dbCompatibleMode = $dbCompatibleMode; $this->_priceCurrency = $priceCurrency; } 私の質問はvarに焦点を合わせています\Magento\Framework\App\Config\ScopeConfigInterface $scopeConfig（同じコンストラクターに他のものがあることは知っていますが、私が考えるすべてのケースに1つの説明が当てはまります）。 di.xmlコアモジュールによると、varは次のインスタンスになりますMagento\Framework\App\Config。 <preference for="Magento\Framework\App\Config\ScopeConfigInterface" type="Magento\Framework\App\Config" /> 必要に応じて簡単に変更できます。 コードでそのようなインターフェイスを使用する必要があるのはいつですか？ …

19 configuration  magento2  best-practice  dependency-injection 

Magento 2のクライアントプロジェクトの作業中に、サードパーティの拡張機能を読み込んで追跡する方法を数多く発見しました。 インテグレーターのインストール方法（作曲家！）を使用していると仮定して、これに進むと、サードパーティの拡張機能を管理するためのベストプラクティスは何ですか？ これまで、私が購入またはダウンロードしたすべての拡張機能には、独自のcomposer.jsonファイルがあり、拡張機能の作成者が拡張機能のインストールを推奨する少なくとも3つの異なる方法を知っています。 これらのファイルをアプリ/コードにコピーします このzipをフォルダーにコピーし、アーティファクトリポジトリとして追加し、それを必要とします このオンラインリポジトリ（認証あり/なし）を追加し、必要とします これまでのところ、私は1と2に出くわし、＃3が存在するのではないかと疑っています。しかし、その後、＃1を示唆したものが「パス」リポジトリを持つことができることに気付きました-私の拡張機能をアプリ/コードからこれらのアーティファクトを置くことにした同じフォルダに移動し、それを必要としました。 このプロセスでは、リポジトリの構成は次のようになります。 "repositories": { "0": { "type": "composer", "url": "https://repo.magento.com/" }, "artifacts": { "type": "artifact", "url": "artifacts" }, "third-party": { "type": "path", "url": "artifacts/*/*" }, }, あなたへの私の質問は-ここでのベストプラクティスは何ですか？サードパーティの拡張機能をどのように管理しますか？ これまでのところ、私がやっている方法が最良の方法だと信じています-composer.jsonが読み込まれ、依存関係の競合（またはPHPバージョンの制約）が明らかになるからです-しかし、それは十分に決定的ではないと思います。

16 magento2  composer  best-practice 

ではMagento 1、私たちは、これらのディレクトリに私たちのクラスを配置するために使用されました ブロック ヘルパー モデル 資源 また、名前の中央に大文字を含まない単純なクラス名を使用します。 いくつかのケースを見てみると Magento 2 Core ヘルパー 場所： - \Foo\Bar\Helper 名前： - *.php 例： - \Magento\ImportExport\Helper\Report -\Magento\Cms\Helper\Wysiwyg\Images オブザーバー 場所： - \Foo\Bar\Observer 名前： - *.php - *Observer.php 例： - \Magento\CustomerCustomAttributes\Observer\SalesOrderAddressAfterLoad -\Magento\CustomerBalance\Observer\ProcessBeforeOrderPlaceObserver プラグイン 場所： - \Foo\Bar\Plugin 名前： - *.php - *Plugin.php 例： - \Magento\Catalog\Plugin\Block\Topmenu - \Magento\PageCache\Model\App\FrontController\BuiltinPlugin 出典：http://devdocs.magento.com/guides/v2.0/extension-dev-guide/plugins.html#declaring-a-plugin …

15 magento2  extensions  best-practice  architecture  naming-convention 

正しい方法を見つけることは私にとって困難だったので、以下であなたが私が作ったベストプラクティスを見つけることができました。楽しんで、必要に応じて英語を修正し、私が間違っていると言ってください。:) 編集： ...そして、私はいくつかの面で間違っていたことがわかりました。だから、ラファエルの答えが私をもっと理解するのを助けてから、元の投稿を更新しました。彼に感謝！ 以下で使用される概念： これらの概念に慣れていれば、以下のコードと説明を理解しやすくなります。 インジェクションの依存関係（$this->variableコード内のすべての変数がインジェクトされるため） サービス契約とリポジトリ 工場 コンテキスト： より多くのコンテキストを持つために、モジュールが正しく構築されていると想像してください： 方法を含むブロッククラスCustomBlock getCustomModel($id)、 このメソッドは、paramで渡されたIDに基づいてCustomModelオブジェクトを返します。 CustomModelタイプは、モデルに対応します \Vendor\Module\Model\CustomModel このモデルには、そのリソースモデル（\Vendor\Module\Model\ResourceModel\CustomModel）が付属しています およびそのリポジトリ（\Vendor\Module\Model\CustomModelRepository）を使用します。 質問： すべてがCustomModelオブジェクトをロードできるようにするベストプラクティスは何ですか？ load()このメソッドは廃止されているため、CustomModelオブジェクトからを使用することはできません。 良い習慣は、CustomModelサービス契約を使用する必要があることです。サービスコントラクトは、データインターフェイス（CustomModelInterfaceなど）とサービスインターフェイス（CustomModelRepositoryInterfaceなど）です。だから私のブロックは次のようになります： / ** @var SlideRepositoryInterface * / 保護された$ slideRepository; / ** * CustomBlockコンストラクター * ... * @param CustomModelRepositoryInterface $ customModelRepository * ... * / パブリック関数__construct（ ... CustomModelRepositoryInterface $ customModelRepository ... …

15 magento2  magento-2.1  model  best-practice  crud 

私はコアを見渡して、モデル間の多対多の関係のいくつかの例を見てきましたが、これに関する明確な答えを見ることができません。 例として、新しいモデルを作成し、既存の製品テーブルと多対多の関係を持ちたいとします。 新しいモデル-Stockistがあり、2つのテーブルを作成します。1つはStockist名を格納し、もう1つは製品との多対多の関係を格納します。 セットアップクラスの短縮バージョン： $table = $setup->getConnection() ->newTable($installer->getTable('stockist')) ->addColumn('stockist_id', \Magento\Framework\DB\Ddl\Table::TYPE_INTEGER, null, ['identity' => true, 'unsigned' => true, 'nullable' => false, 'primary' => true], 'Stockist Id') ->addColumn('name', \Magento\Framework\DB\Ddl\Table::TYPE_TEXT, null, ['nullable' => false], 'Stockist Name'); $table = $installer->getConnection() ->newTable($installer->getTable('stockist_product')) ->addColumn( 'entity_id', \Magento\Framework\DB\Ddl\Table::TYPE_INTEGER, null, ['identity' => true, 'nullable' => false, 'primary' => true], …

15 magento2  database  model  resource-model  best-practice