Kirby Pro Plugins

Why Sell Plugins for Kirby CMS?

All my plugins for the Kirby CMS are open source and free. Until now. I was so happy with my last one, the Kirby Content Translator, which enables DeepL-based translation of blocks and other fields directly in the Kirby panel, that I thought about developing commercial pro plugins. The user experience of the translation helper felt top-notch, and the utility factor could justify a purchase. It would also be a way to indirectly get donations for my open source work that wouldn’t otherwise reach me.

There are already a number of fantastic Kirby plugins out there. What is there to build that hasn’t already been built? Maybe I can use my Vue know-how for plugins that mainly take place in the Kirby Panel, i.e. in the browser, and focus on a good “editor experience” – as a counterpart to the developer experience.

Offering commercial plugins for the Kirby CMS – is it even worth it? I will find out this year. It’s not only selling plugins that is new territory for me. It’s also my debut in selling digital products in general.

The Beginning: Kirby Copilot

Last year, I wrote an alternative UI for ChatGPT. So I already had experience with different libraries to interact with models like OpenAI’s GPT. So it was natural for me to build a bridge between AI and Kirby. It’s only a matter of time before someone tries their hand at it, I thought. This spurred me on to be the first to try writing an AI plugin. My experience with AI libraries and the structure of the Kirby Panel provided a good basis for implementing the idea.

The Kirby Copilot primarily provides an area in the Kirby Panel where an editor can write a prompt in a text field. If the AI provider is preconfigured, text is generated based on the prompt. This is nice, but also a bit of a gimmick. Without context, an AI is of little use. Unless an editor has access to the content of the page, text completion is of little use. Therefore, the prompt can be fed with context by referencing field names from the blueprint of the page in double curly brackets: {{ title }} or {{ date }} for example.

In addition to the prompt input field, it is also possible to enrich the prompt with images (provided the GPT Vision model is enabled) and/or PDF files. When PDF files are added, the pages are read out and the entire content is appended to the prompt. To ensure that the AI understands from which line the extracted text begins, the following instruction is prepended:

Additional context from the following PDF documents has been processed and made available to you. Include the information from these documents as applicable. [Hier folgt der Inhalt.]

What Should the Documentation Look Like?

As a buyer of a plugin, I have different expectations of the documentation than when I read the README of an open source project. I want to live up to my own expectations of my products. That’s why I made it a point to create my own website for the Copilot documentation. It was just the right project to try out Nuxt UI after having done all the documentation for the previous plugins with VitePress. In addition to the documentation, the website should also be a presentation of all features – individual pages are easy to implement with Nuxt as a meta-framework.

In addition to the website, I wanted to create a playground where people could experience the plugin. So that not only videos, screenshots and sample code prove the functionality, but potential buyers can test the scope themselves. So I created a playground – a Kirby instance that redirects to the Kirby Panel when called up, automatically logs the user in and thus presents the plugin in the application context of the panel without any detours. The user can try out all functions and is only prevented from saving his local changes by restricted rights. This construction kit could be reused for the following plugins.

Writing and designing the website and testing environment took as long as developing the plugin itself. It just had to be neat and pretty.

Second Plugin: Kirby SEO Audit

One of the best-known and probably most widely used plugins for WordPress is Yoast SEO. It offers several tools to optimize pages for optimal search engine rankings. The Kirby community provides some great SEO plugins for the Kirby CMS. However, most of them are only visible to developers. The most common question I have heard from customers during the migration from WordPress to Kirby was whether there is “something like Yoast” for Kirby.

The customers are referring to the Yoast SEO report. This can score individual pages according to numerous SEO and readability criteria. This analysis works in the browser and does not rely on server-side code. In principle, it can therefore be ported to the Kirby Panel. This was also possible because the logic for evaluating HTML text is fortunately open source on GitHub. With a few adjustments and detours, I was also able to get the library to work for the Kirby CMS: The SEO Audit plugin was born.

In my opinion, the Kirby Copilot is too niche to be widely used. Perhaps it will take some getting used to and practice to integrate AI into editorial processes in a meaningful way. The SEO Audit, on the other hand, could be the product that adds value to many business websites. It is currently the best-selling plugin with 20 sales (as of Q1, 2024).

Support and Service

Unlike open source plugins, commercial products should... Well, work. That means answering developer questions and, of course, fixing bugs. Although I offer a 30-day money-back guarantee, my biggest concern when releasing both plugins was that they would not live up to expectations despite the test environment. I am glad that my fears were not confirmed.

On the contrary. There was a warm exchange between the developers and me. Some bugs were fixed quickly and feature requests were considered. This allowed both plugins to grow with feedback from the user’s perspective. If nobody is so dissatisfied that they want their money back, then the plugins can’t be completely broken.

Third Plugin: Kirby Live Preview

One of the top ten most requested features for Kirby is a preview embedded in the Panel, so that an editor can see their unsaved changes in a page preview right in the Panel while editing content. This feature works mainly in the Panel, compared to most of the other requests. A real find for me. So I picked up the idea. Only this time I wasn’t sure if I would be able to implement it.

The road was indeed a bit rocky. A live preview walks a fine line between usefulness and gimmickry; editorial empowerment and work blockage. Did I succeed? I think so. Try it out for yourself.

Fair Pricing Model

I don’t expect the development effort for the plugins to pay off. It does not have to. The implementation of the ideas was a success in itself. At the same time, it is an exciting experience to sell digital products with all their dependencies, from the provider to the tax.

It was important to me that the value of the plugin is reflected in the price without being overpriced. That’s why I decided on a pricing model that allows to use the purchased plugin for multiple projects as long as the developer remains the owner of the project, i.e. the code base. In the sense of buy once, use forever.

Installing Using Composer

So that the plugins cannot be installed by anyone using Composer, they cannot be found on Packagist. For the first sales, it was too much work for me to make the commercial plugins available via a private repository. For one thing, I didn’t know how to do it. For another, I didn’t know if the effort would be worth it for a few sales. I didn’t want to invest the time. That’s why the installation was only possible with a ZIP file. After the first few sales, there were already requests for version management via Composer. Understandable, because downloading and unpacking the ZIP file is a hassle. Especially since the effort is the same for every project and every version upgrade.

A tip from the community led me to Satis, a simple generator for a static Composer repository. With a little magic from a Cloudflare worker, the private repository for my plugins is accessible, but the plugin build files can only be downloaded after authentication. This requires license management to create a separate license for each order, which can be used to authenticate to the repository.

Using the Kirby Tools Hub, a small Nuxt app, you can log in with the email address used to purchase and the corresponding order number. The authentication instructions can be found there. Once the repository has been successfully linked to the project, one or all of my plugins can be installed and updated with a single command.

So the feature request turned into three web pages:

• The private repository itself (satis.kirby.tools, password-protected)
• Proxy (worker) to the private repository (repo.kirby.tools)
• License management (hub.kirby.tools)

Open Questions

Since selling the first plugin, my overall concept has remained the same. I’m pretty happy with how the project has evolved overall. Any development and sales process is in flux and I may adjust some things. For example, I’m not sure if I’ll stick with Lemon Squeezy as a payment provider, as it’s more designed for the US market and has disadvantages for me as an overseas seller (e.g. +2.5% fee for payouts to locations outside the US).

I would like to list here, in no particular order, all the points about which I am not yet sure:

• Invite buyers to a private repository on GitHub so that they can see the code?
• Switch to Paddle and leave Lemon Squeezy behind?