We read 330 WooCommerce plugin readmes. Here's what a frontend dashboard has to support

A frontend dashboard has a problem nobody puts on the feature list. It replaces the WordPress admin screens, and the WordPress admin screens are where every other plugin puts its settings.

Install a min/max quantity plugin and it adds two fields to the product edit screen in wp-admin. Install a checkout field editor and the extra fields show up on the wp-admin order screen. Install a payment gateway and its refund and capture buttons live there too. Move your shop manager to a frontend dashboard and, unless the dashboard knows about those plugins, those fields simply aren’t there anymore.

So the honest question for any frontend dashboard - StoreSuite included - isn’t “what features does it have”. It’s “which of the plugins I already run will still work from it”. We wanted a real answer to that, so we went and counted.

How we measured it

We looked at two places WooCommerce stores get their plugins.

WordPress.org. We pulled every plugin returned for the “woocommerce” search and the woocommerce tag - 13,749 plugins in total - and kept everything with 10,000 or more active installs. That’s 348 plugins. We dropped WooCommerce itself and 16 that only mention WooCommerce in passing, which left 330.

For each of those 330 we read the readme.txt from the stable release, in full - description, features, FAQ, screenshot captions. Then a second, independent pass re-read every readme and tried to disprove the first verdict. They disagreed on 18 plugins; a third read settled those.

WooCommerce.com Marketplace. We ranked the 1,238 paid extensions in the official marketplace by the Active installs figure shown on each product page, to see which paid extensions stores actually run.

The question asked of every plugin was the same: does a shop manager do recurring, day-to-day work with this plugin on a wp-admin screen that a frontend dashboard replaces - the product form, variations, coupons, orders, order statuses - or in a list of the plugin’s own records? If the answer is “you set it up once in a settings page”, it doesn’t need a dashboard integration. Settings pages can stay in wp-admin with whoever installs plugins.

The headline numbers

Verdict	Plugins	Share
Needs a dashboard integration	110	33%
Needs passive compatibility only	28	8%
Already supported or in progress in StoreSuite	8	2%
Covered by something StoreSuite already does	12	4%
Doesn’t need a dashboard at all	172	52%

The most useful number is the last one. Over half of the most popular WooCommerce plugins never need a frontend dashboard to know they exist.

Half of them don’t care about your dashboard

The 172 “doesn’t need it” plugins fall into a handful of groups, and once you see them the pattern is obvious:

• Checkout and storefront behaviour - side carts, quick view, wishlists, product filters, search, swatches on the shop page, buy-now buttons. They change what customers see.
• Shipping-rate calculators - table rates, weight-based rates, free-shipping rules. Configured once per zone.
• Marketing sync and tracking - Mailchimp, Klaviyo, pixels, conversion tracking. They push data out; nobody edits them per order.
• Email designers, page builders, security, caching and backups - site-level tools.
• Multivendor marketplaces - a different product, with its own vendor dashboards.

None of that is a dashboard problem. A store manager processing orders on a Tuesday afternoon never touches any of it.

The ones that matter all touch the same five places

The 110 plugins that do need an integration aren’t spread evenly across WooCommerce. They pile up in five places:

1. The order details page - payment gateway cards (WooPayments and PayPal Payments, 800,000+ installs each), shipping label and tracking cards, custom checkout field values.
2. The product form - SEO fields (All in One SEO, 2M+), quantity limits, prices per currency or country, custom product tabs, feed identifiers like GTIN and MPN.
3. Attributes and variations - colour and image swatches on attribute terms, extra images per variation.
4. The coupon form - BOGO rules, auto-apply conditions, “show this coupon on Google”.
5. The order list and statuses - custom order numbers, custom statuses, delivery dates as a column.

That’s a much shorter list than “110 integrations”, and it changes how you’d build them.

One screen, many plugins

Look at the plugins that need the same screen and a lot of them need exactly the same thing from it:

What the dashboard needs	Plugins it serves
A payment card on order details with capture, void and refund through the gateway	WooPayments 800K+, PayPal Payments 800K+, Payment Plugins for Stripe 100K+, Payment Plugins for PayPal 80K+, plus Amazon Pay, Braintree, Klarna, Afterpay, Authorize.net and Yoco
A “checkout fields” card on order details	Checkout Field Editor 400K+, Flexible Checkout Fields 80K+, Checkout Field Manager 80K+, Brazilian Market 60K+, and four more
A swatch type on attributes, with colour or image on each term	Five separate variation-swatch plugins between them past 600K installs
A gallery picker on each variation row	Five variation-gallery plugins, 10K-30K each
A place to add fields on the coupon form	Google for WooCommerce 800K+ and four coupon plugins

Five variation-swatch plugins store their data differently, but they all need the dashboard to offer a swatch type when you edit an attribute and a colour or image when you edit a term. Build that once against WooCommerce’s own attribute types and most of them work. Build five bespoke integrations and you maintain five forever.

That’s the main conclusion we took away: build the shared surfaces, then connect plugins to them, rather than chasing plugins one at a time.

Passive compatibility: cheap, and covers a lot of stores

28 plugins don’t need any new screen. They just need the dashboard not to break them, or to show data it already has:

• Translations. Polylang (900K+) and TranslatePress (400K+) keep translated products linked to each other. A product save that ignores that link can quietly break a translation.
• Order numbers and statuses. Sequential and custom order number plugins change the number customers see. If the dashboard searches by internal ID only, a shop manager can’t find order “INV-2041”. Custom status plugins add statuses that need to appear in filters, badges and bulk actions.
• Product add-on choices. Extra Product Options, PPOM and YITH Add-Ons store the customer’s choices on the order line. The order screen has to keep showing them.
• Calendars. Persian WooCommerce and Parsi Date (100K+ each) mean date pickers have to accept a Jalali date.

These are small fixes with very large install bases, which makes them the best value on the list.

The paid marketplace tells the same story

The WooCommerce.com Marketplace ranking points the same way. The top three paid extensions by active installs are WooCommerce Subscriptions (100K+), Product Add-Ons (100K+) and Product Bundles (60K+) - all three live on the product form, and two of them add a new product type. Next come Shipment Tracking (50K+) and Min/Max Quantities (40K+), again an order card and two product fields.

And the same “half don’t need it” pattern holds. Of the top 80 paid extensions, 37 are things like carrier rate calculators (USPS, UPS, FedEx, Canada Post, Australia Post), tax tools, checkout tweaks and automation - set up once, never touched from a dashboard.

What StoreSuite already supports

Some of this is already in the plugin today:

• PDF Invoices & Packing Slips (WP Overnight, 300K+) and WebToffee PDF Invoices (50K+) - invoice and packing slip actions on the order list and order details.
• Advanced Custom Fields - field groups assigned to products appear on the frontend product form, saved through ACF.
• Advanced Shipment Tracking (70K+) - a tracking card on the order, a tracking column and an “Add tracking” action on the order list.
• Yoast SEO - product SEO fields are in progress.

What we’re building next

Based on this research, the integration work is being ordered by how many stores each piece helps, not by which plugin asked loudest:

1. Passive compatibility first - translation safety, searching by custom order numbers, custom statuses everywhere, add-on choices on orders.
2. A payment card on order details with gateway refunds and captures.
3. A checkout fields card for the checkout field editors.
4. Attribute swatch types and a variation gallery for the swatch and gallery plugins.
5. A coupon-form extension point for coupon and channel plugins.
6. Product form cards for SEO, quantity limits, multi-currency prices, tabs and feed identifiers.

If you’re evaluating any frontend dashboard

This research changed the questions we’d ask about any dashboard, ours included. Before you move a shop manager off wp-admin:

• List the plugins that add fields to your product and order screens. Not every plugin you run - just those. For most stores it’s three to six.
• Open one product and one order in the dashboard and check those fields are there. If they aren’t, decide whether the manager needs them weekly or never.
• Check your order numbers and statuses. Search for an order by the number your customers quote, and filter by any custom status.
• Edit a translated product, if you run a multilingual store, and check the translation is still linked afterwards.
• Try a refund on an order paid through your real gateway, in a staging copy.

Twenty minutes of that tells you more than any feature comparison.

And if a plugin your store depends on isn’t on our list, tell us in the support forum. Install counts are a good proxy for what most stores run. They’re a poor proxy for what your store runs.