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 ablock.jsondefinition -
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. 🙌