Hello team,

First of all, thank you for your continued great work on MarketKing.
I am both a developer customizing MarketKing and an owner actively operating it, and from these two perspectives I’d like to humbly propose a small improvement based on real usage.

Background

MarketKing already provides excellent extension points. As highlighted in the official documentation, plugin developers often use marketking_extend_menu to add custom items or components into the vendor dashboard. This is a powerful way to integrate additional functionality without changing core code.

However, current feature-availability checks rely only on static metadata (user_meta / group_meta). This makes it difficult to handle time-dependent or dynamic conditions without costly metadata syncing across many staff accounts.

Example (Coupons):
In some marketplaces, Coupons should only be accessible while a vendor’s subscription is active and paid. If a payment fails, the Coupons menu and its endpoints should disappear immediately.
Currently, this requires updating metadata for every staff account, which is inefficient and error-prone at scale. Simply hiding the menu via extend_menu is not enough, since vendor_has_panel() may still return true, allowing direct URL access.

Proposed improvement

To address this in a minimal and fully backward-compatible way, I propose adding a single filter at the start of vendor_has_panel($panel_slug, $vendor_id = 'currentuser'):

// does not apply if marketking pro not enabled
if (!defined('MARKETKINGPRO_DIR')){
    return true;
}
/**
 * Short-circuit with safe fallback:
 * - If a handler returns true/false, use it.
 * - If null (no handler or explicit null), continue with the original logic.
 */
$custom = apply_filters('vendor_has_panel_custom', null, $panel_slug, $vendor_id);
if ($custom !== null) {
    return (bool) $custom;
}
// (continue with the existing logic here)

Why this design works well:

• Only one filter (vendor_has_panel_custom) to implement.

• If unused (returns null), the current logic runs as-is → full backward compatibility.

• If implemented, developers can return true/false for real-time, dynamic control, ensuring UI and server-side logic stay consistent.

Example usage

A very simple use case would be restricting Coupons access based on subscription status:

add_filter('vendor_has_panel_custom', function($val, $slug, $vendor_id){
    if ($slug !== 'coupons') return null; // fall back to original logic for other panels
    $status = my_subs_status($vendor_id); // 'active' | 'past_due' | 'canceled'
    return $status === 'active';
}, 10, 3);

This way, Coupons is automatically available only when the vendor’s subscription is active, without needing to sync metadata across staff accounts.

How this contributes to extensibility

Together with the already documented marketking_extend_menu, this filter would give developers two complementary extension points:

1. UI insertion (extend_menu)

2. Server-side visibility control (vendor_has_panel_custom)

This opens up more integration opportunities, such as:

• Subscription-based access to Coupons (as shown above)

• License/seat-based limits for features like Products

• Usage quotas, e.g., hiding Coupons once a monthly cap is reached

• Staged rollouts / A/B tests (e.g., enabling a new Orders 2.0 view only for selected vendors)

Summary

• A minimal change, just a few lines in core.

• Zero impact on existing sites unless the filter is used.

• Greatly increases MarketKing’s flexibility and attractiveness as an integration platform.

• Builds on the extensibility approach already described in your documentation (marketking_extend_menu).

Thank you very much for considering this proposal. I believe it would make MarketKing even stronger and more appealing to integration developers and partners. I’d be glad to help with a small PR or test implementation if useful.

Best regards,
Naoki