How I Built a WooCommerce Plugin That Works With Every Page Builder

Kushang Tailor — Mon, 27 Apr 2026 13:14:47 +0000

The Problem I Noticed

When I was working on WooCommerce stores for my clients, I kept
running into the same frustrating issue — there was no good way
to create a fully customizable WooCommerce product category page
that worked across all editors.

Every solution I found was locked to a specific page builder.
Elementor users had one option. Gutenberg users had another.
SiteOrigin users were mostly out of luck. And if your client
used no editor at all — just plain shortcodes — forget it.

I thought: why should the editor choice limit what you can
build?

So I built the Product Category plugin — and published it
on WordPress.org.

What the Plugin Does

In simple terms, it lets you create a fully customizable
WooCommerce product category listing page — and it doesn't
matter which editor you or your client prefers.

It works with:

✅ Elementor — via a dedicated Widget with live preview
✅ Gutenberg / Block Editor — via its own custom React Block
✅ SiteOrigin — via a Widget
✅ WP Bakery / JS Composer — via Shortcode
✅ No editor / Classic editor — via Shortcode

One plugin. Every editor. No compromises.

Key Features

Here's what you can control right inside the plugin settings:

Set a custom title for your category listing
Show or hide specific product categories via dropdown
Choose from multiple category display styles
Set rows and columns for the layout grid
Sort categories by Name or Slug (ASC / DESC order)
Show or hide category descriptions
Show or hide pagination
Show or hide category thumbnail images
Add proper Alt tags to category images (for SEO & accessibility)

And the best part — with Elementor and Gutenberg, all of this
is live preview. You see changes in real time as you design.

The Challenge: Supporting Multiple Editors

The hardest part wasn't building the features — it was
architecting the plugin so that the same core logic could power
four completely different integration points.

Each editor has its own way of registering and rendering
components:

Elementor uses a Widget class that extends \Elementor\Widget_Base
Gutenberg uses register_block_type() with a block.json definition
SiteOrigin uses SiteOrigin_Widget
Shortcode uses WordPress's add_shortcode() function

The key decision I made was to keep the rendering logic
centralized in one function, and have each editor integration
simply call that function with its own set of parameters. This
way, a bug fix or a new feature only needs to be written once —
and all four editor integrations benefit immediately.

What I Learned

Building this plugin taught me a lot about how different
WordPress ecosystems actually work under the hood. Each page
builder has its own lifecycle, its own way of passing data, and
its own rendering context.

It also taught me the importance of backward compatibility.
The plugin has been live since 2019 and I've maintained it
through multiple WordPress versions — all the way up to WP 6.9.
Every update had to ensure existing users weren't broken.

And perhaps most importantly — it taught me to listen to
users. Features like pagination, Alt tag support, and the
Gutenberg block were all added based on real feedback from people
using the plugin in production.

The Result

The plugin currently has 200+ active installations on
WordPress.org, a 5-star rating, and has been stable through
7 years of WordPress updates.

👉 Check it out on WordPress.org

If you're a WooCommerce developer who's ever struggled with
editor compatibility, I hope this gives you some ideas. And if
you use the plugin, I'd love to hear your feedback!

Feel free to connect — I'm always happy to talk WordPress,
WooCommerce, or plugin architecture. 🙌