Commerce Plugin - interest?

I’ve found that the #1 reason I have to choose Wordpress over Kirby these days is when my client needs an e-commerce solution. So let’s change that, let’s make a commerce plugin for Kirby! And obviously it has to be named Kirby Kommerce.

I’ve had extensive experience with developing ecommerce systems in the past. Before I used Wordpress, I was actually developing them from scratch. Now about half the sites I do are built on WooCommerce. I know where the common pitfalls are, the user complaints, and how to organize it into something reusable (and extendable).

The basic, obvious features will include:

  • Default blueprints for products
  • Shopping cart templates
  • Payment gateway API
  • Customer login / registration
  • Order management (for admin & customer)

The non-required features that are important to me:

  • Event hooks to modify display and behavior
  • Login/registration not necessary to purchase
  • Product variations & options
  • Add-ons and coupons
  • Downloadable products

Technologically, there are many directions it could go. Purchases and customer data could be stored in a database, but I really prefer Kirby’s NoDB approach, so I’m going to try to avoid using MySQL. Security will be top priority, so I won’t even give the option of “manual processing” credit cards - you’ll need to use a gateway like Stripe. Additionally, it may be smarter to split the project into multiple plugins that accomplish different functions, rather than a big all-in-one solution. Lastly, I’m not going after Magento. This will not be a solution for companies that have 1000’s of products, this would be a Kirby-based alternative to Wordpress/Woocommerce - the websites that sell a few dozen items, maybe in the low hundreds.

Is there anyone else interested in testing or contributing? Once it hits a stable release, I’ll likely license it similar to Kirby because I really like Kirby’s model. Source would be available on GitHub, but you’ll have to pay per site to license it. Testers and contributors obviously would get free licensing.

What would you like to see in a Kirby e-commerce plugin? What’s most important to you (or your clients)?


I’d be interested in contributing as I worked on two e-commerce projects with WordPress last year and with both switched around WooCommerce, self-created things… just was a mess. So I’d really be happy to see something for Kirby coming up and helping to realize this.

I’d also vote for trying to break it down into a core plugin and various addon plugins as in this way, people who only need something very basic don’t need to bloat their minimal Kirby up too much. Like different payment gateways could be each an addon, coupons, offers…

Edit: Oh, and from next month on, I’d also be thesis-free, so with some time :wink:
Edit 2: Admittedly, I am not the greatest developer, but I think I could still contribute especially in regard to things like templates, default blueprint and maybe just in general conceptualizing the whole framework

1 Like

I myself thought quite a bit about a shop plugin for kirby. Unfortunately I’m not capable of developing it by myself.
But I would love to contribute in another way (like making a concept for a kirby-like API, usability testing, and so on)

Important for me would be:

  • product options with different prices/pictures/sizes/…
  • great search (let’s be honest: search is the most important thing if you have more than a dozen products)
  • filtering options like colors/size/price range/…
1 Like

Great idea, I’m not a developer but could help out with testing, documentation or something along those lines …

1 Like

The more I think about it, the more I think this is the best way to develop it. Much like Kirby can be broken up into three plugins currently (Core, Toolkit, Panel), the Kommerce plugin itself should also be split up. At this point, I’m thinking: Products, Cart & Checkout, Customers, Orders. All would interact with each other, but none strictly necessary. For the minor features and payment gateways, those drop-in as separate plugins as well - interacting with the core through event hooks.

Also I already want to change the name to Kirby Kart - because I thought of an awesome logo.

1 Like

About the Name: With Kirby Kart we are just one K away from the Klu Klux Klan :smiley:
No, seriously: Kirby Kart has a nice ring to it :smile:

But…Kid with racing goggles driving a shopping cart!

Ok obviously I need to hire a designer.


Oh my gosh, I actually laughed out loud :smiley: I see the resemblance to your profile pic :wink:
Representing the streamlined development of a NoDB shop? :slight_smile:

PS: I would have gone with KirbyShop and a minimalistic lying S in a blue hexagon :wink:

1 Like

Yeah that probably makes the most sense.

But less fun!
And you would have to worry about @bastianallgeier suing you :smiley:

I just have to say that I love the idea/visual of that kid in a speeding shopping cart. So I’d be all up for Kirby Kart <3

  • multinational VAT support
  • multinational shipping APIs…

are both annoying but important.


I’d also say that hooks within the panel would be kind of a requirement from the Kirby side for such a plugin framework.

Just thinking: If we split up functionalities into plugins/addons, we’d need a way to extend blueprints e.g. when product offers are added as an addon.

Or, well, then again that could also be realized through a subpage of the product with a product-offer-blueprint that only is available when the product offer addon is installed…

Which brings me to a (kinda general) question: Is there a way to include blueprints from within the plugin folder? The problem with bigger Kirby Plugins, that I see at the moment, is that you have to tell the user not only to copy a folder to the plugins directory, but also to copy the blueprints and maybe templates and css and js. It would be pretty crucial to minimize that installation. Ideally, for the core and all addons just: copy this folder to your plugins directory.

How about a special shop/kart folder in the main directory? Like the panel folder?

And in that folder config/templates/snippets/blueprints/customers & core

I’ve been thinking about this too. The solution I’ve come up with is that the appropriate plugin actually creates the necessary blueprint files during some kind of one-time setup/install process.

I like this idea, but if Kirby 2.1 will indeed have panel hooks, I’d rather just wait for that.

It’s not about a different uri. I would love to manage the shop from within the panel.
It’s more about usability for the web developer:
Would he rather once have a complicated install process with coping files in different folders or would he rather switch folders while editing blueprints and templates?

How about an installation wizard that copies all the files into the right directory?

1 Like

I definitely think this is going to be necessary.

I was about to post a request for opinions on a new question, your comment about web developer usability kind of already started the discussion. So here it goes…

When it comes to plugin structure (assuming it’s just a standard plugin in the plugins folder, not a separate panel, which is still an option), what would be better: [1] one plugin where we drop all the core & 3rd party submodules into, (the plugin’s index could auto-load the modules) or [2] multiple plugins in Kirby’s plugin folder (so there would be a Cart plugin, a Checkout plugin, an Orders plugin, all completely independent of each other)?

The problem with installation wizards is mainly deinstallation. Plus, an installation wizard would be pretty un-Kirby-ly. Not that I’d have a solution ready, but I’d try to avoid that if we can.


It would be an one-click installation. Much like the first panel account.
And deinstalling: Well you would need to delete a couple of folders… not that big of a deal in my opinion, since most wouldn’t even deinstall it.

If we can make it that smooth, I’ll love it.
Just what I see with a lot of the bigger WordPress plugins that have installation wizards. Installing is easy, but beware of trying to remove it once and it either leaves too much behind or removes too much :smiley: