Adapter Architecture

The plugin talks to marketplaces through a small adapter layer so the rest of the code never references Dokan, WCFM or WC Vendors directly. There are three pieces: an abstract base adapter, one concrete adapter per marketplace, and a manager that detects and fronts the active one.

The pieces

File	Class	Role
`core/adapters/class-mv-adapter.php`	`PeepSo_MV_Adapter` (abstract)	The contract every adapter implements.
`core/adapters/class-mv-adapter-dokan.php`	`PeepSo_MV_Adapter_Dokan`	Dokan (Lite/Pro).
`core/adapters/class-mv-adapter-wcfm.php`	`PeepSo_MV_Adapter_WCFM`	WCFM Marketplace.
`core/adapters/class-mv-adapter-wc-vendors.php`	`PeepSo_MV_Adapter_WC_Vendors`	WC Vendors.
`core/class-mv-manager.php`	`PeepSo_MV_Manager`	Loads adapters, detects the active one, fronts it.

The manager

PeepSo_MV_Manager is a singleton (PeepSo_MV_Manager::get_instance()). On construction it builds the adapter list, filterable via peepso_mv_adapters, instantiates each class that exists, and marks the first one whose is_active() returns true as the active adapter.

Key methods:

get_active_adapter(), the active PeepSo_MV_Adapter, or null.
has_active_adapter(), whether any supported marketplace is active.
get_adapter( $id ), a specific adapter by id.
__call( $method, $args ), a uniform facade: any vendor-API method called on the manager is forwarded to the active adapter, returning null when no marketplace is active. This is why callers can do PeepSo_MV_Manager::get_instance()->get_vendor_store_url( $id ) without knowing the marketplace.

The marketplace-agnostic helper functions (peepso_mv_is_vendor, peepso_mv_store_url, peepso_mv_active_is) are thin wrappers over the manager.

The adapter contract

PeepSo_MV_Adapter declares these abstract methods every adapter must implement:

Method	Returns
`get_id()`	Unique adapter id, e.g. `'dokan'`, `'wcfm'`, `'wc-vendors'`.
`get_name()`	Human-readable marketplace name.
`is_active()`	Whether this marketplace plugin (plus WooCommerce) is present.
`is_vendor( $user_id )`	Whether the user is an enabled vendor.
`get_vendor_dashboard_url( $user_id )`	The vendor dashboard URL.
`get_vendor_store_url( $user_id )`	The vendor’s public store URL.
`get_vendor_store_info( $user_id )`	`[ name, url, logo, banner, rating ]`.
`get_vendor_products( $user_id, $args = array() )`	Array of product IDs.
`get_vendor_product_count( $user_id )`	Published product count.
`get_vendor_registration_form()`	Signup form markup/shortcode output.

And these overridable methods with base defaults:

Method	Default	Purpose
`get_vendor_orders( $user_id )`	`array()`	Vendor orders (Dokan overrides).
`renders_own_dashboard()`	`false`	Legacy hint (WCFM/WC Vendors override to `true`). See the note below.
`render_native_dashboard( $tab = '' )`	no-op	Legacy: echo the marketplace’s native dashboard. Not called by the showcase.
`enqueue_dashboard_assets()`	no-op	Legacy: force-load the marketplace’s dashboard assets. Not called by the showcase.

Note: the native-dashboard methods are legacy holdovers. Before 2.0.0 the My Products tab embedded WCFM’s / WC Vendors’ native dashboard, and these three methods drove that embed. In the 2.0.0 showcase, My Products renders one uniform product grid on every marketplace (WooCommerce’s [products] shortcode scoped to the vendor), so these methods are no longer called by the profile surfaces even though the WCFM and WC Vendors adapters still override renders_own_dashboard() to return true. They remain on the contract for backward compatibility and for any custom adapter that still wants them; a new adapter should leave them at their defaults.

Adding a new marketplace

Create a class that extends PeepSo_MV_Adapter and implements every abstract method. Return a unique get_id(), and gate is_active() on your marketplace’s class/functions plus WooCommerce. Implement get_vendor_store_url() and get_vendor_products(); the showcase drives My Products from the product query, so you generally do not need to touch the legacy native-dashboard methods.

add_filter( 'peepso_mv_adapters', function ( $classes ) {
    $classes[] = 'My_Marketplace_MV_Adapter';
    return $classes;
} );

That is the only wiring needed: the manager, helpers, profile surfaces and settings all route through the contract, so no other file changes. Order matters only for detection: the first active adapter in the list wins, so keep one marketplace active at a time.

Scope note

The adapter contract is deliberately the shared, marketplace-neutral surface: the vendor check, store/dashboard URLs, store info, and the vendor’s products. Marketplace-specific screens (for example WC Vendors’ ratings/coupons/store-settings tabs, or any commission/reports/order-received view) are not re-implemented as PeepSo tabs; those live inside the marketplace’s own dashboard, reached via the Store / Visit Store links. See The profile showcase.