Kirby CLI Installer

It’s starting to remind me of Drush, the Drupal shell, probably the first thing people install along with Drupal.

If you have ideas what else could be useful for Kirby when you have experience with drush, I’m all ears. :heart:

@cilice Lovin’ this! Thanks!

@cilice Looking forward to the --kit and clear cache commands. To weigh in, I think I’d make use of custom kits so I have customized versions of the kits. As an example, I could see doing something like this…

Custom Kit

$ kirby new kirbystrap --kit=starterkit
# add bootstrap and customize starter ui
$ kirby save --kit
$ kirby new mysite --kit=kirbystrap

And maybe saves custom kits to ~/.kirbykits.

Think something like that would work?

This project deserves more visibility - it’s awesome. A couple of suggestions:

  1. perhaps adding it as a listing in the plugins directory - not sure whether it’s appropriate, as it’s not really a ‘plugin’
  2. perhaps add it to the installation/upgrade docs, as a ‘command-line’ way of performing a Kirby instal - again, probably not totally appropriate, as it does more,than simply instal
  3. add a section (page) to the ‘advanced’ section of the docs, listing all the functionality available to command-line users - probably the most appropriate option.

Please, keep up the good work!

I wholeheartedly agree! It’s already on my todo list to mention it on various places on the site.

Some boilerplate generation functionality would be pretty killer and a HUGE time saver too :smirk: like JeffreyWay’s generators for Laravel

1 Like

Will there be support for unofficial plugins down the road, such as Color Picker, Detect, etc?

The problem is, the format there is just a collection of links. Ideally, every plugin would be a kind of an archive, or a git repo. @bastianallgeier, we slowly could use a centralized plugin repository similar to wordpress. :smile:

I already mentioned it to @bastianallgeier, I am about to blow this stuff up. I’m creating a complete CLI tool for Kirby, it’s probably going to be donationware or commercial use paid license.

A preview of what is coming:

@JimmyRittenborg - yes, I decided to make it like this, so you can just enter kirby make:blueprint article --schema="foo:bar:baz"


Would love this with the possibility for a plugin not only to install itself in the plugin directory, but also add/update asset files for example (and display a message to the user then to add the required lines in the header.php).

1 Like

A central place for plugins sounds like a great plan. My first thought was a dedicated Github organisation: “getkirby-plugins” and then a repository for each plugin. That would also make it a lot easier to download plugins and submit pull requests. Each plugin developer could be invited to the org. Any thoughts on that? Better ideas?

@DieserJonas should most definitely be involved here!

The only problem with that that I see is that you need to invite people to the organization by hand or via api. Can you separate the repositories within the organization still limited to the right access? For example if the CLI ever lands there, will @distantnative be able to commit to it?
I don’t have that much experience with github organizations.

Another idea is to build something in Kirby and make an App, where you register a namespace and just can submit a repo. Somehow like or the old npm.

Github Orgs can have multiple teams, which can have different permissions for different repos. That’s quite handy. At the moment I’m afraid I won’t be able to pull off the work for a custom registry. That would of course be most awesome, but also most work intensive.

So basically we could have a team for each plugin and a general team. I wouldn’t mind to add people manually. We could also set a team of admins for the plugins org. I’m very open to that kind of stuff.

BTW: I really love the new syntax!!

This is getting super sexy! :ok_hand:t2::heart_eyes:

@bastianallgeier I thought about ways to unify the installation process of plugins multiple times, too.

The problem I’m seeing is that a lot of plugins don’t stay within their site/plugins/plugin-name directory because they’re adding widgets, panel fields, snippets, assets, … as well.

However, I like the idea of having a getkirby-plugins organisation with a few admins. Each user can request access (through / / a special repo) and will be assigned a reposity within that organisation, that only he (and the admins) have access to.

The question that’s floating around in my mind is though: Do we only allow “existing” plugins that people started developing within their own accounts repositories to be added or do we allow to register “blank” plugin names/repositories, too? I guess there might be a few dead/empty repos popping up in this case. We somehow have to keep this kind of clean, don’t you think?

@cilice, @bastianallgeier Maybe a file, similar to other package managers files (composer.json, bower.json), within each plugins repository, that includes information about the author, the version, what kind of files the plugin includes (assets, fields, plugins, widgets, snippets, etc.) would be a good starting point to automate installing more complex plugins.

As plugins evolve from simple functions in Kirby v1 to such complex creations like nowadays, I think an overthought plugin installation process would be great. You could even implement something like a plugin installation dashboard within the panel.

As @DieserJonas says, we need a common and one true way to register widgets, deliver assets, and what else there is. It also includes panel extensions.

So many ideas…

1 Like

I demonstrated the ability to add widgets via the plugin folder itself in the past. If a plugin followed a similar directory structure as the actual site folder, and automatically integrated anything it finds based on which directory it was in, then there wouldn’t be need to control where everything is installed. It’d always be in plugins/pluginname/… This would make coordinating random plugins easier. As long as it followed the rules.

1 Like

Has work on this project stopped?
That would be a tremendous shame!..