彼は予見可能な世界で最高の店であると主張しておらず、この目的のためにすべての専用エンジンに必ず負けますが、Revoの店のニッチではまさに3番目になります。
VisionCartとShopkeeperの後。
ここに私のminiShopがあります。 デモサイトでは、外部と管理部分の両方のすべてを見ることができます（ ログインとパスワード-demo ）。
拡張機能は完全にオープンソースであり、無料です。 誰が気にかける-habrakatの下の詳細。
設置
リポジトリから数回クリックするだけで、パッケージマネージャーを介して実行されます 。 そこから、更新も受信されます（ストアは緊密に開発されています）。
インストール後、カテゴリと製品の2つのテンプレートを作成し、設定でそれらを指定する必要があります。
カテゴリーと製品
すべての製品とカテゴリはリソースツリーにあります。 一部を他と区別するには、異なるテンプレートを使用します。 また、カテゴリはコンテナでなければなりません。
それらのテンプレートは、コンポーネントのシステム設定で指定する必要があります（ネームスペースをミニショップに切り替えます）。
そこで、新しい注文のステータス番号を変更する必要があります（デフォルトでは1、インストール済み）
店舗を開発する前に、自分のテーブルまたはリソースに商品を保管する最適な方法に関する調査を実施しました。 そして、ほとんどのテーブルに投票しましたが、議論の過程で、私はリソースですべてを行うことに気付きました。
理由は次のとおりです。
1. TV設定を使用できます。
2.コンテキストを使用できます。
3.すべての標準スニペットを使用できます。
4.リソースグループと権限を使用できます。
5.キャッシングはすぐに使用できます。
6.各アイテムのわかりやすいURL。
自分で続けることができます。
欠点はありません。速度はかなりのレベルです（デモサイトで15,000の製品が採点されています）。 すべての製品は、コンポーネントから直接作成および変更されます。 これには、リソースツリーに登る必要はありません。
このコンポーネントには、製品のカテゴリ、名前、および記事番号による便利なフィルタリングがあり、数百/数千のポジションで何も失われません。
倉庫
コンポーネントは無制限の数の倉庫をサポートします。
それぞれ個別に構成されたパラメーター。 配達、住所、注文メッセージを受け取るための郵便など
この機会を使用することはできませんが、作業用に少なくとも1つの倉庫が必要です（デフォルトで作成されます）。
これまでのところ、商品には4つの主要なプロパティがあります：記事、画像、価格、バランス。 4つのプロパティはすべて、倉庫財の比率に関連付けられています。 また、さまざまなニーズに合わせて3つのプロパティを追加しました。 2つのvarchar（255）と1つのテキスト。
つまり、すべての倉庫にすべての商品が同時にあるかのように、どこでも異なるプロパティ（または同じ）を持つことができます。 これにより、豊富な管理機能が提供されます。
現在の倉庫の残高を使用して、サイトで商品を表示します。 残高が0の場合、商品を表示しないか、注文を出しません。
マルチカテゴリー
これはチップですが、それだけではありません！私は自分の店を書く必要がありました。
各製品には独自のメインカテゴリ（製品が配置されているコンテナ）があり、追加のカテゴリがある場合があります。設定で設定します。 制限はありません。
msGetResourcesスニペットを介して製品が表示されると、すべての製品がカテゴリに従って取得されます。 リソースと製品の両方のすべてのプロパティによるソートもあります。
このスニペットはバンドルされており、変更されたgetResourcesです（そのクラスも使用されます）。
したがって、1つの製品が異なるカテゴリに表示されます。
ステータス
注文のステータスを好きなだけ作成し、任意の順序で切り替えることができます。 各ステータスは、バイヤーとマネージャーのメールへの通知で構成できます（レター本文の異なるヘッダー）。
インストール中、ステータスは通知が有効な「新規」です。
マネージャへの通知は倉庫メールに送られます（カンマで区切って複数指定できます）。
コンポーネントで注文ステータスを切り替えると、このアクションは注文変更履歴に保存され、このステータスの設定に従って通知が送信されます（または送信されません）。
サイト上のカタログ
バスケットを使用したすべての操作、商品の追加/削除、注文の発行はAjaxを通じて行われます。
必須のjquery 1.7以降、jquery.form 2.8以降、およびわかりやすいURL。
一般に、私の意見では、フロントエンドはまだ弱いですが、人々が何を望んでいるかは明らかではありません。
注文、ユーザーの登録などの要件は誰もが持っています。 だから、$ _SESSION ['minishop']を見て、スニペットを書いてください。
注文の私のバージョンでは、データベースにない場合、ユーザーは電子メールで識別され、ランダムなパスワードで登録されます（その後、リセットして自分のものに変更できます-ここでは登録=です）。 注文と配送先住所はこのユーザーに関連付けられています。 アドレスは、注文プロパティの管理領域で変更できます。 そこにある商品の数量は変更できます。
メインクラスでは、注文時にこれらのアドレスから選択するための基本がありますが、これまでのところすべてがコメントアウトされています-不安定なためです。
注文後、ユーザーセッションはクリアされます。
バスケットで作業する場合、json文字列がステータス、メッセージ、商品数、バスケットの量とともに返されます。
個人アカウント
このパンは文字通り今日リリースされます。 承認が必要です（ログイン、またはLoginzaスニペット）。
キャビネットはExtJSとMODX管理パネルで作成され、マネージャーからのすべてのスクリプトがキャビネットに読み込まれ、デザインスタイルはCDN Senchaから取得されます。
一方では難しいですが、他方では、非常にクールなオフィスを作ることができます。 商品とステータス変更の履歴を含むすべての注文のリストが表示されている間、荷物の運命を追跡できます。 無制限のステータスを考えると、少なくとも「管理者Petyaが製品をパッケージに包んだ」管理パネルからここに公開できます。
私のサイトでアカウントを使用するには、注文する前にログインを使用してログインし、何かを注文する必要があります。 後でLoginzaスニペットを完成させて、アカウントのユーザープロパティ（名前、住所など）を変更できるようにします。 そして、サービスはそのような情報を提供せず、買い手は注文で代用するために必要なデータを入力したいと考えています。
おわりに
パッケージには、シンプルなストアを作成するために必要なすべてのスニペットとチャンクが含まれています。
このプロジェクトはまだかなり若く、少しはできますが、時間が経つにつれて成長すると思います。 私は積極的に開発しており、やめるつもりはありません。
参照資料
プロジェクトホームページ+ドキュメント+デモ（管理パネルを含む）
Githubソースコード
MODXリポジトリのパッケージ
速度のデモンストレーション
PS
厳しく批判しないでください。 これは、MODX Revolutionエンジンの拡張機能であり、個別のプロジェクトではないことに注意してください。
また、 Githubトラッカーでエラーを示してください。