Martfury WooCommerce Marketplace WordPress Theme：マルチベンダーECの内部アーキテクチャと実装設計を深掘り
Introduction
Martfuryは、単純なWooCommerceショップ向けテーマではなく、WooCommerceを商品・注文・決済の基盤として利用し、その上にマルチベンダーMarketplaceのUIと販売導線を構築するためのフロントエンドテーマとして設計されています。
重要なのは、Martfury自体がMarketplaceエンジンになるわけではない点です。
基本的なシステム構成は次のように考えることができます。
WordPress
│
├── Martfury Theme
│ ├── Header / Navigation
│ ├── Shop UI
│ ├── Product Templates
│ ├── Search / Filter UI
│ ├── AJAX Interaction
│ └── Marketplace Presentation Layer
│
├── WooCommerce
│ ├── Products
│ ├── Orders
│ ├── Cart
│ ├── Checkout
│ ├── Payment
│ └── Customer Accounts
│
└── Multivendor Plugin
├── Vendors
├── Vendor Products
├── Commissions
├── Vendor Dashboard
└── Vendor Store
この分離構造によって、商品データや注文処理をテーマ側に閉じ込めず、WooCommerceを中心とした標準的なWordPress EC構造を維持できます。
1. Martfuryの設計思想
Martfuryを技術的に評価する場合、最初に見るべきなのは「Marketplace機能をどこに実装しているか」です。
Marketplaceサイトでは少なくとも以下のレイヤーが必要になります。
Presentation Layer
↓
Product / Vendor Query Layer
↓
WooCommerce
↓
WordPress Database
↓
MySQL
Martfuryは主にPresentation Layerを担当します。
一方、以下のような処理はWooCommerceやマルチベンダープラグイン側が担当します。
- 商品登録
- 商品価格
- 在庫
- カート
- 注文
- 決済
- ベンダー
- 手数料
- 売上
- 配送
- 顧客情報
このアーキテクチャは、テーマ変更によってECデータが失われるリスクを抑えるうえで重要です。
テーマが商品データそのものを独自システムとして保持する設計ではなく、WooCommerceの商品モデルを利用するためです。
2. WooCommerceを中心にしたデータモデル
MartfuryのEC処理を理解するには、WordPressの通常のページ構造ではなくWooCommerceの商品モデルを見る必要があります。
代表的な関係は次のようになります。
wp_posts
│
├── product
│ │
│ ├── product_cat
│ ├── product_tag
│ ├── product_brand
│ └── product_type
│
├── shop_order
│
└── attachment
商品情報はWordPressの投稿モデルをベースにしながら、価格、SKU、在庫、販売条件などをWooCommerceのメタデータと関連テーブルによって管理します。
そのためMartfuryのテンプレートは、WooCommerceの商品オブジェクトから必要な情報を取得して表示する構造になります。
例えば商品一覧では、
Product Query
↓
WooCommerce Product Object
↓
Price
SKU
Thumbnail
Rating
Stock
Attributes
↓
Martfury Product Card
という流れになります。
この設計のメリットは、商品数が増えてもテーマ側で独自の商品データベースを構築する必要がないことです。
3. マルチベンダーMarketplaceの内部構造
Martfuryの重要なポイントは、Dokan、WC Vendors、MultiVendorX、WCFM Marketplaceなどのマルチベンダー環境を想定していることです。
Marketplaceでは、通常のWooCommerceとはデータ関係が一段複雑になります。
Customer
│
▼
Order
│
├── Product A ── Vendor A
│
├── Product B ── Vendor B
│
└── Product C ── Vendor A
つまり1つのカートに複数ベンダーの商品が存在する可能性があります。
この場合、テーマだけでVendor管理を実装するのではなく、MarketplaceプラグインがVendorと商品との関係を管理します。
Martfuryはその情報をフロントエンドに反映します。
例えば、
Product
│
├── Product Information
├── Vendor Information
├── Vendor Store
├── Vendor Rating
└── Vendor Products
という構造をUIとして表現できます。
これはMarketplaceテーマとして重要な設計です。
4. Vendor Storeと通常のShop Archiveの違い
通常のWooCommerceショップでは、
/shop/
から商品一覧を取得します。
一方Marketplaceでは、
/shop/
↓
All Vendors
/vendor/vendor-a/
↓
Vendor A Products
/vendor/vendor-b/
↓
Vendor B Products
という2階層以上のカタログ構造になります。
したがってテーマ側では、単純なProduct Archiveだけではなく、Vendor Archiveとの共存を考える必要があります。
この設計では、商品カードにVendor情報を表示したり、Vendor Storeへの導線を追加したりすることが重要になります。
5. 商品検索のアーキテクチャ
MartfuryはECサイト向けにライブ検索、SKU検索、カテゴリ・属性などによる絞り込みを組み合わせる構成を採用しています。
検索処理を概念化すると、
Search Input
│
▼
AJAX Request
│
├── Keyword
├── Category
├── SKU
├── Attribute
├── Brand
└── Price
│
▼
WooCommerce Query
│
▼
Filtered Product Result
│
▼
HTML / JSON Response
│
▼
Frontend DOM Update
となります。
この構造ではページ全体を再読み込みする必要がないため、ユーザーが検索ボックスに入力している途中でも結果を更新できます。
ただし、Ajax検索は便利な一方で、商品数が多いサイトではバックエンド負荷を考慮する必要があります。
6. Ajaxフィルターが大規模ECで重要な理由
例えば10万商品を持つMarketplaceで、すべての商品をブラウザへ送信してJavaScriptだけでフィルタリングする設計は現実的ではありません。
したがって、
Browser
↓
Filter Parameters
↓
Server
↓
Database Query
↓
Matching Products
↓
Browser
というServer-side Filteringが基本になります。
特に、
- Category
- Brand
- Attribute
- Price
- Product Type
- Stock
- Vendor
などを組み合わせると、SQLクエリのコストが大きくなります。
そのためMartfuryを大規模Marketplaceで利用する場合、テーマそのものだけではなく、WooCommerceの商品クエリ、インデックス、キャッシュ、検索プラグインまで一体として設計する必要があります。
7. 商品カードのレンダリング
MarketplaceではProduct Cardが非常に重要です。
1商品につき表示される情報は、
Thumbnail
Product Name
Price
Sale Price
Rating
Wishlist
Compare
Quick View
Add to Cart
Vendor
Badge
など多数あります。
単純なループでも、
while ( $products->have_posts() ) {
$products->the_post();
wc_get_template_part(
'content',
'product'
);
}
のようなWooCommerceテンプレート構造を中心に考えることができます。
Martfury側では、この標準的な商品レンダリングにデザインと追加UIを組み合わせることになります。
そのためテーマをカスタマイズする場合、直接テーマファイルを書き換えるより、WooCommerceのTemplate OverrideやHooksを理解したほうが安全です。
8. 商品詳細ページのレンダリング
Product Detailはさらに複雑です。
概念的には、
Single Product
│
├── Gallery
├── Product Title
├── Price
├── Rating
├── SKU
├── Attributes
├── Variations
├── Add to Cart
├── Wishlist
├── Compare
├── Description
├── Reviews
├── Related Products
└── Frequently Bought Together
という構造になります。
特にVariable Productでは、
Color
Size
Storage
Material
などのAttributeからVariationを決定する必要があります。
そのため単純なHTMLフォームではなく、WooCommerceのVariationデータとJavaScriptを連携させる必要があります。
9. Variable ProductとJavaScript
Variable Productでは、ユーザーが属性を変更すると価格、SKU、画像、在庫状態などが変化する場合があります。
概念的には、
User selects:
Color = Black
Size = XL
↓
JavaScript
↓
Variation Matching
↓
Variation ID
↓
Price / Image / Stock Update
という処理になります。
ここで重要なのは、テーマ側がVariationロジックそのものを独自実装しないことです。
WooCommerceのVariationシステムを利用しながら、Martfury側ではUIとイベント処理を担当するほうが保守性が高くなります。
10. Ajax Add to Cartの処理
MartfuryではAjax Add to Cartも重要なEC機能です。
通常のAdd to Cartでは、
Product Page
↓
POST
↓
Server
↓
Cart Update
↓
Page Reload
となります。
Ajax方式では、
Click Add to Cart
↓
JavaScript Event
↓
AJAX Request
↓
WooCommerce Cart
↓
Fragments / Response
↓
Mini Cart Update
となります。
ユーザーはページを再読み込みすることなくカート状態を確認できます。
ただし、Mini CartやCart Fragmentを多用すると、キャッシュ戦略が難しくなる場合があります。
11. WooCommerce Cart Fragmentsとキャッシュ
ECサイトで特に注意したいのが、
Page Cache
+
Dynamic Cart Data
の組み合わせです。
例えばトップページを完全なHTMLキャッシュにすると、ユーザーごとに異なるカート情報をそのままキャッシュしてしまう可能性があります。
そのため、
Static Content
↓
Page Cache
Dynamic Cart
↓
AJAX / Client-side Update
という分離が重要になります。
Martfuryを高速化する場合、単純に「すべてをキャッシュする」のではなく、静的コンテンツと動的ECデータを分離する設計が必要です。
12. Product DealsとCountdownの実装
Marketplaceではセールや限定価格も重要です。
Product Deal UIは、
Deal Product
│
├── Regular Price
├── Sale Price
├── Start Time
└── End Time
というデータをフロントエンドに渡し、
Server Time
↓
Expiration Timestamp
↓
JavaScript Countdown
↓
DOM Update
という処理で表示できます。
ここでJavaScriptだけを信用して価格判定を行うのは危険です。
価格・販売可否などの重要ロジックはサーバー側で検証し、JavaScriptは表示だけを担当させる必要があります。
13. Mega Menuの内部設計
Marketplaceではカテゴリ数が多くなるため、Mega Menuが単なるデザイン要素ではありません。
例えば、
Electronics
├── Computers
│ ├── Laptops
│ ├── Desktops
│ └── Accessories
├── Mobile
│ ├── Smartphones
│ └── Tablets
└── Cameras
のようなWordPress Taxonomy構造を、ナビゲーションUIへ変換します。
WordPressではメニュー情報と商品カテゴリは別のデータ構造なので、
WP Navigation
+
Product Taxonomy
↓
Mega Menu UI
という変換レイヤーが必要になります。
大規模サイトでは、メニューに大量のカテゴリを直接ロードするとHTMLサイズとデータ取得量が増えるため、カテゴリ階層と表示数を制御することが重要です。
14. 商品FilterとTaxonomy Query
商品フィルターではWordPressのTaxonomy Queryが中心になります。
例えば、
'tax_query' => [
[
'taxonomy' => 'product_cat',
'field' => 'slug',
'terms' => 'electronics',
]
]
のような条件を組み合わせます。
さらに属性を追加すると、
Category
+
Brand
+
Color
+
Size
+
Price
という複合条件になります。
条件が増えるほどSQL側の処理量も増えるため、大規模Marketplaceでは、
- キャッシュ
- 適切なページネーション
- 検索インデックス
- 不要なMeta Queryの削減
- 商品数の取得回数削減
が重要になります。
15. Meta Queryがパフォーマンスに与える影響
WooCommerceサイトで注意すべき処理の一つがMeta Queryです。
例えば、
Price
SKU
Custom Attribute
Custom Flag
Vendor Data
などをWordPress postmetaから大量に検索すると、商品数の増加に伴ってクエリコストが上昇する可能性があります。
特に、
Meta Query
+
Taxonomy Query
+
Order By Price
+
Pagination
を同時に実行すると、データベースへの負荷が高くなります。
したがってMartfuryを大規模ECで利用する場合、テーマの見た目だけを高速化するのではなく、商品検索のSQLレベルまで確認する必要があります。
16. Elementorとページ構築
MartfuryはElementorとの互換性を持つため、フロントページやコンテンツページの構築ではWidgetベースの設計を利用できます。
概念的には、
Elementor
│
├── Section
├── Container
├── Widget
└── Dynamic Content
│
▼
WordPress
│
▼
Frontend
という構造です。
ただし、ECサイトではElementorですべてを作る必要はありません。
例えば、
Homepage
→ Elementor
Product Archive
→ WooCommerce + Theme
Single Product
→ WooCommerce + Theme
Checkout
→ WooCommerce
という役割分担のほうが合理的です。
17. WPBakeryとの共存を考える
MartfuryではWPBakeryを利用する構成も重要です。
ElementorとWPBakeryを同時に大量利用すると、ページビルダー固有のCSS・JavaScript・DOM構造が増える可能性があります。
したがって本番サイトでは、
Legacy Pages
↓
WPBakery
New Landing Pages
↓
Elementor
のように役割を整理したほうが管理しやすくなります。
特に長期運用では、ページビルダーを増やすほど依存関係が複雑になります。
18. Child Themeによるカスタマイズ
MartfuryのカスタマイズではChild Themeを利用する設計が基本です。
例えば、
Parent Theme
│
├── Templates
├── CSS
├── Functions
└── JS
│
▼
Child Theme
├── Override Templates
├── Custom Hooks
├── Custom CSS
└── Custom JS
という構造にします。
親テーマを直接編集すると、アップデート時に変更内容が失われる可能性があります。
一方Child Themeを利用すれば、テーマ本体のアップデートと独自コードを分離できます。
19. Hookベースの拡張
Martfuryを本格的に拡張する場合、Template OverrideだけでなくWordPress/WooCommerce Hookを利用する方法が重要です。
例えば、
add_action(
'woocommerce_single_product_summary',
'custom_product_message',
25
);
のようなHookを使えば、商品ページの特定位置へ独自UIを追加できます。
この方式ではテーマ本体のPHPファイルを変更せずに、
WooCommerce Hook
↓
Custom Function
↓
Frontend Output
という拡張が可能です。
20. Product SearchとSKU検索
SKU検索はMarketplaceにおいて特に重要です。
一般消費者は商品名で検索しますが、B2BユーザーやリピーターはSKUを直接入力するケースがあります。
そのため、
Keyword Search
+
SKU Search
+
Category Filter
+
Attribute Filter
を統合すると、商品検索の精度を高められます。
ただしSKUは通常の商品タイトルとは異なる検索フィールドになるため、検索エンジンやクエリ設計を考慮する必要があります。
21. WishlistとCompareのデータフロー
WishlistやCompareはWooCommerce標準機能ではないため、外部拡張との連携が重要になります。
概念的には、
User
│
├── Wishlist
│ └── Product IDs
│
└── Compare
└── Product IDs
という構造になります。
ログインユーザーの場合はユーザー単位で保存し、未ログインユーザーではCookieやブラウザストレージなどを利用する設計が一般的です。
そのため、キャッシュされた商品一覧とユーザー固有のWishlist状態を混在させないことが重要です。
22. 商品レビューシステム
WooCommerceの商品レビューでは、
Product
↓
Customer Review
↓
Rating
↓
Average Rating
↓
Product Card / Product Page
というデータフローになります。
MarketplaceではさらにVendorとの関係が加わるため、
Product Rating
≠
Vendor Rating
として扱う必要があります。
この区別を曖昧にすると、商品の品質評価と販売者評価が混ざってしまいます。
23. Order Trackingの実装思想
注文追跡では、ユーザーに注文ステータスを表示する必要があります。
基本的には、
Order Created
↓
Processing
↓
Completed / Shipped
↓
Delivered
という状態機械として考えられます。
Marketplaceでは、
One Order
├── Vendor A
├── Vendor B
└── Vendor C
のように複数Vendorの商品が含まれる可能性があるため、注文表示とVendor単位の処理を分離する必要があります。
24. WooCommerceとマルチベンダーの責務分離
Martfuryを運用する上で最も重要なのが責務分離です。
| レイヤー | 主な責務 |
|---|---|
| WordPress | CMS・ユーザー・基本データ |
| Martfury | UI・テーマ・EC表示 |
| WooCommerce | 商品・カート・注文・決済 |
| Multivendor Plugin | Vendor・Commission・Vendor Dashboard |
| Page Builder | ページレイアウト |
| Search Plugin | 高度な検索 |
| Cache Layer | HTML・Object・Static Cache |
この分離を理解していないと、テーマ側に過剰なカスタムコードを追加してしまいます。
25. キャッシュ戦略
Marketplaceではキャッシュが非常に重要です。
理想的な構造は、
CDN
│
├── CSS
├── JS
├── Images
├── Fonts
└── Static Assets
│
▼
Web Server
│
├── Page Cache
├── Object Cache
└── PHP
│
▼
Database
です。
一方、以下は完全なページキャッシュに向いていません。
Cart
Checkout
My Account
Vendor Dashboard
Wishlist
Personalized Data
これらは動的データとして扱う必要があります。
26. Object Cacheの役割
WooCommerceでは同じ商品・カテゴリ・設定情報が何度も参照されることがあります。
そのためObject Cacheを導入すると、
PHP
↓
Object Cache
↓
Cache Hit
でDBアクセスを減らせる可能性があります。
特にMarketplaceでは、
- Product
- Category
- Brand
- Vendor
- Store Settings
などの参照回数が増えやすいため、ページキャッシュだけでは不十分な場合があります。
27. 画像処理とLazy Load
ECサイトでは画像が最大の転送量になるケースが多くあります。
Martfuryのような商品中心のテーマでは、
Product Image
↓
Thumbnail
↓
Lazy Loading
↓
Browser
という設計が重要です。
さらに本番環境では、
Original
↓
WebP / AVIF
↓
Responsive Sizes
↓
CDN
のように画像を最適化すると、商品一覧ページの転送量を抑えられます。
ただし商品画像を過剰に高解像度化すると、Lazy Loadを利用してもスクロール時のネットワーク負荷が増えるため、画像サイズそのものの最適化も必要です。
28. Mobile Rendering
Marketplaceではモバイルアクセスが非常に重要です。
デスクトップでは、
Mega Menu
Sidebar
Product Grid
Large Search
を表示できますが、スマートフォンでは、
Compact Header
Search
Category
Product Grid
Sticky Actions
へ変換する必要があります。
レスポンシブ対応は単純なCSS Media Queryだけではなく、
Desktop DOM
+
Mobile CSS
+
Mobile Interaction
まで考慮する必要があります。
29. Header設計と動的UI
ECサイトのHeaderには多くの動的要素があります。
Logo
Search
Account
Wishlist
Compare
Cart
Category Menu
特にCartとAccountはユーザーごとに異なるため、キャッシュ戦略と密接に関係します。
そのため、
Static Header
+
Dynamic Components
という考え方が重要です。
30. SEOとHTML構造
ECサイトのSEOでは、単純にMeta Titleを設定するだけでは不十分です。
重要なのは、
Category
↓
Subcategory
↓
Product
という内部リンク構造です。
Martfuryを使ったMarketplaceでは、カテゴリ・ブランド・Vendor Store・商品ページが大量に生成されるため、Index管理が重要になります。
特にフィルターURLが大量生成される場合、
/category/electronics/
?color=black
?brand=xxx
?price=100-500
?size=large
のようなURLが検索エンジンに大量認識される可能性があります。
したがってSEOでは、
- Canonical
- Noindex
- Pagination
- Faceted Navigation
- Internal Links
- XML Sitemap
を一体として設計する必要があります。
31. 大規模Marketplaceで発生するボトルネック
Martfuryを大規模Marketplaceで利用する場合、ボトルネックはテーマのCSSだけとは限りません。
典型的には、
1. Database Query
↓
2. Product Filter
↓
3. PHP Processing
↓
4. HTML Generation
↓
5. JavaScript
↓
6. Image Loading
の各段階に存在します。
特に商品数が増えると、
WP_Query
+
Meta Query
+
Tax Query
+
Sorting
+
Pagination
が複雑になり、Database Query Timeが増加します。
そのため、大規模サイトではテーマ変更だけで問題を解決するのは難しくなります。
32. セキュリティ設計
Marketplaceでは一般的なWordPressサイトより攻撃面が広くなります。
理由は、
Admin
+
Customer
+
Vendor
+
Payment
+
Product Submission
+
File Upload
という複数の権限レイヤーが存在するからです。
特にVendor登録を許可する場合、
Vendor
↓
Product Upload
↓
Image Upload
↓
Product Data
↓
Admin Approval
という入力経路を適切に制御する必要があります。
テーマ側では、
- Nonce
- Capability Check
- Escaping
- Sanitization
- Permission Validation
などを意識する必要があります。
33. Child Themeで安全に拡張する実践構造
Martfuryを長期運用するなら、次のような構造が扱いやすくなります。
martfury-child/
│
├── style.css
├── functions.php
│
├── inc/
│ ├── hooks.php
│ ├── filters.php
│ └── marketplace.php
│
├── woocommerce/
│ ├── single-product/
│ └── archive-product.php
│
└── assets/
├── css/
└── js/
さらに大きなMarketplaceでは、独自機能をテーマのfunctions.phpへ集中させるより、独自プラグインへ分離したほうが保守性は高くなります。
Martfury
│
└── Presentation
Custom Plugin
│
├── Business Logic
├── Marketplace Rules
├── Custom API
└── Custom Hooks
という構造です。
34. REST API / Headless構成への発展
Martfuryは通常のWordPressレンダリングを前提としたテーマですが、WooCommerceの商品データはAPIベースのアーキテクチャへ発展させることもできます。
例えば、
Frontend
│
▼
Next.js / React
│
▼
API
│
▼
WordPress
│
└── WooCommerce
という構成です。
ただし、この場合MartfuryのテーマUIをそのままHeadless Frontendへ移植するわけではありません。
テーマはWordPressのServer-rendered UIを担当し、Headless化するとFrontendを別途再構築する必要があります。
35. 開発者視点で見たMartfuryの適性
Martfuryは特に次のようなシステムとの相性が良い設計です。
Marketplace
├── Electronics
├── Fashion
├── Furniture
├── Accessories
└── General Products
さらに、
WooCommerce
+
Multivendor Plugin
+
Search / Filter
+
Cache
+
CDN
という構成を組むことで、一般的なMarketplaceアーキテクチャを構築できます。
逆に、商品点数が少ない単純な企業サイトや、商品販売を必要としないコンテンツサイトでは、Martfuryの機能群を十分に活用できない可能性があります。
36. Production環境での推奨アーキテクチャ
本番環境でMartfuryを利用するなら、次のような構成が現実的です。
CDN
│
┌─────────┴─────────┐
│ │
Static Dynamic
Assets Pages
│ │
Browser Web Server
│
┌──────┴──────┐
│ │
Page Cache PHP-FPM
│
WordPress
│
┌────────────────┼──────────────┐
│ │ │
Martfury WooCommerce Marketplace
│ │ │
└────────────────┼──────────────┘
│
Object Cache
│
Database
この構成では、テーマはPresentation Layerとして機能し、ECロジックをWooCommerceへ、Marketplaceロジックを専用プラグインへ分離できます。
37. Martfuryをカスタマイズする際の優先順位
開発者がMartfuryを拡張する場合、次の順序で検討すると保守性を維持しやすくなります。
1. Existing Theme Option
↓
2. WooCommerce Hook
↓
3. WordPress Filter
↓
4. Child Theme
↓
5. Template Override
↓
6. Custom Plugin
↓
7. Core Modification
最後のCore Modificationはできるだけ避けるべきです。
テーマやWooCommerce本体のファイルを直接編集すると、アップデートとの衝突が発生しやすくなるためです。
38. 総合技術評価
Martfuryの技術的な価値は、単に「Marketplace向けのデザインが多い」という点にはありません。
本質的には、
WooCommerce
+
Theme Presentation
+
Multivendor Integration
+
AJAX Commerce UI
+
Product Discovery
+
Responsive Marketplace UX
を一つのFrontend Layerとしてまとめている点にあります。
特に重要なのは、Martfury自身がすべてのECロジックを抱え込まず、WooCommerceを商品・注文・カートの基盤として利用し、DokanやWCFMなどのMarketplaceシステムと連携する構造です。
この分離によって、
Theme
≠
Commerce Engine
≠
Marketplace Engine
という責務分離が成立します。
これはWordPress Marketplaceを長期間運用するうえで非常に重要な設計思想です。
Conclusion
Martfuryは、WooCommerceを単純なオンラインショップとして利用するよりも、商品数が多く、複数Vendorが参加し、検索・フィルター・商品比較・Wishlist・DealsなどのEC UIを大量に必要とするMarketplace環境で特に能力を発揮するテーマです。
技術的には、
WordPress
↓
Martfury
↓
WooCommerce
↓
Multivendor Layer
↓
Search / Filter
↓
Cache / CDN
↓
Database
という多層構造で考えると理解しやすくなります。
また、実運用ではテーマそのものよりも、WooCommerceの商品クエリ、Ajax処理、Taxonomy/Meta Query、Object Cache、画像配信、動的Cart、Vendorデータ、Facet URLなどがパフォーマンスを左右します。
したがってMartfuryを本格的なMarketplaceへ発展させる場合、重要なのはデザイン設定の数ではなく、テーマ・WooCommerce・Marketplaceプラグイン・検索システム・キャッシュ層の責務を明確に分離することです。
この設計を守れば、Martfuryは単なるECテーマではなく、WordPress上で大規模なマルチベンダー販売フロントエンドを構築するためのPresentation Layerとして利用できます。