Introducing the Kirby CLI

1

I already wrote briefly about it this weekend, but here’s the official introduction: We now have a command line interface for Kirby \o/

The Kirby CLI is supposed to make general administrative tasks easier for you. It will help you to install and update Kirby, as well as creating all sorts of components, like templates, snippets, controllers, etc.

It’s also an important step towards easier plugin management.

So just make sure to give it a try and let me know what you think. Any suggestions or issues can be reported in the Github repo: https://github.com/getkirby/cli/issues

You will find installation instructions in the readme: https://github.com/getkirby/cli

I really hope you like it as much as I do :slight_smile:

19 Likes
3

Wow, this is greeeeeeeeeeeeeeeeeeeat!!! Thank you, @bastianallgeier!

Suggestion: perhaps get rid of the dependency on Composer at a later date? - maybe the cli could just update itself?..

1 Like
4

The dependency on Composer could easily be removed I guessed. The idea with the auto-update is really cool. I have to check out how this could work.

5

Hmm, there are always several options for self-updating. I guess the first couple that come to mind are:

  1. if you wanted to keep using Composer’s built-in features (like dependency checking, sub-project downloading, etc.), then you might be able to package the composer.phar file itself as part of the CLI package. Then, internally issue your updates commands to it. That way you still get all the benefits without having to ask the user to download and instal Composer. This could be neat and powerful, but it does create a dependency on Composer - which you’d have to keep updated in your own CLI package.

  2. the CLI package could simply download the latest master directly from the GitHub account, and replace the necessary files - even using wget or curl if necessary. The biggest advantage of this is that it is a simpler solution, with basically no dependencies. The main disadvantage of doing this, is that unlike Composer, dependency checking would have to be done manually.

There may be dozens of other ways to do this, which may be even more efficient, but getting a self-updating system up-and-running quickly should not be too troublesome.

6

If it’s not too much work I vote for dependency free Kirby CLI, but I don’t want delay Kirby and the Panel for it.

What I think is important in this case is; if we need Composer or not, make sure that the Kirby CLI syntax stays the same. Then we as an end user don’t need to care that much what engine that drives it, because we can still do the same thing, the same way.

7

Just noticed that Composer also has dependencies of its own, and that Git is also required for downloading and installing the CLI. This means that on MacOS X, users are asked whether they want to instal the developer tools. This will unfortunately scare away inexperienced users who might otherwise have been willing to try out - and benefit from - a CLI tool…

8

Not sure if dependency free is really what you want here. The CLI is probably for pro users anyway, they should be able to handle Git and Composer. In addition, @mzur has definitely some valid points here. I would prefer a more standardized plugin system that solely uses composer packages and not another proprietary re-invention of the wheel here.

2 Likes
9

@luxlogica Just wondering: What dependencies do you mean? As far as I know you only have to download and execute the composer.phar file to be able to use Composer. You don’t even have to install it globally.

10

@mzur Composer itself will use other tools - such as svn and git - to download and maintain your packages. The Kirby CLI, for instance, uses git, so in order to instal it (as per given instructions) you will download and run Composer, and Composer will try to use git. If you try to do this on a Mac system that does not have git - or Apple’s developer tools - installed, it will actually ask you to instal it.

As a ‘pro user’ myself, I do not mind the dependencies, and am quite adept at keeping things updated and current. But I do know that dependencies will hurt the adoption rate. Compare this with the CLI tool provided by Grav, for instance.

It is indeed possible to have both: you can use Composer and git, if you wish, and not require users to need to download them and maintain them individually. This, however, would require you to package these tools along with yours - which would require you to configure them to work within your own binary. It is a more complex solution, but allows you to keep track of your own dependencies, rather than passing it onto the users. Perhaps something to consider for a future version.

11

I think it’s great to have Kirby CLI install plugins and not Composer. The reason is that we are not dependent of Composer for example. If they change their name or shut down Composer, Kirby CLI could simple use another tool or no dependecies at all. We don’t need to learn another syntax and can still use Kirby CLI. Even if Kirby CLI now use Composer I don’t see that we are dependent of it, not as an end user.

I’ve heard that Composer is “standard” nowdays and should be used. Yes? But what about tomorrow? Or the day after that. Things change quickly in this digital world. WordPress is the “standard” CMS nowdays, why don’t we use that. :wink:

As a summery, I don’t care that much if Kirby CLI is dependent on Composer (I’m on a PC) but I like Kirby CLI and don’t want Composer instead.

1 Like
12

Hello all,

I finally got time to try the CLI and I’m loving it!
I actually had a script in mind that did more or less the same but was way more complex.

Anyway, there was one feature that I’m intrigued at regarding the panel:
when using either kirby install or kirby install:panel could this steps (in the image) be bypassed or auto-executed?

Thanks

13

Of course this is a great step to automation and perhaps to make our own StarterKits (with patterns ;-)). I’m getting the point that the CLI is more an enabler than a new shiny UI. I’m using Kirby since version 1 and I’m really thrilled how the little CMS is growing since then. May I tell you a little story of myself? :slight_smile:

Me and Kirby
I’m using and developing with Kirby in my free time. I’ve learned how to code with Kirby. I’ve learned about PHP and the broad horizon of web development. And Kirby was a door-opener for me, because it has a really low starting point.

As I started to use Kirby, I was thrilled because it doesn’t needs the dependency of a MySQL database. Just change your data by changing text files. Changing the structure by simply rearranging your folders. Without any dependency Kirby enables me to just use my code I’ve already written in a different project. Just copy and paste code snippets and they immediately start to work.

While using the fast-evolving Kirby, it doesn’t took too long when I’ve started to learn about Git, Repositories, Submodules and so on. I’m a GUI-guy, so I’ve managed everything with Tower. Then I’ve learned to split my snippet library into patterns and learned that the pattern I’m coding also has a user interface that should be easy to use. And I also wanted to make my project even more modular - and I learned to use GULP.

But I’ve made a monster without knowing it. With every single dependency, tool or even CLI I’m using, team-working on a site with new team members is getting really dangerous and difficult.

One day, my colleagues asked me to show the actual code of the website to them. They wanted to dig a bit deeper into web development and after I’ve told them that Kirby is a really cool starting point, they wanted to work with me on the company’s website. Cool, huh? I thought Kirby was some kind of a good starting point to collaborate and learn together.

But then the problems has started. It was a bit complicated to tell them what Git is and why I’m using it but it was okay. Also SCSS was not easy, but not impossible to understand. Then I had to explain GULP - and even when you don’t remember how hard it is to learn about GULP without learning Node.js - it’s really hard!

Long story short
I’ve learned that the point where I am is far away from the beginner’s starting point. And with every dependency, with every additional tool, my project is getting more and more complex - and complicated. It’s getting hard and partly impossible to work in a team with someone who’s new in the project team.

With CLI, the whole project will be even more complex. I assume that’s far away from being intuitive or “natural” and therefore not easy to learn for beginners.

Today I’ve cloned the GetKirby StarterKit to make my own starter kit with patterns. Then I’ve read this in the changes:

Removed submodules
With the new CLI it’s becoming easier to update individual components and the git submodules can finally be removed. They introduced too many problems anyway.

I don’t know whether this is the right way for the Kirby CMS. But I think this is a point where it’s getting really hard for beginners. Please don’t forget that.

2 Likes
14

@servicethinker: You have some really good points there.

On the other hand, and maybe that is the most important, you can still use Kirby without all those tools and dependencies. You don’t need Git, nor Gulp nor the CLI nor the patterns plugin, not even SASS. It is up to you.

You can still just download Kirby as a .zip folder and unzip into your web root like in the old Kirby 1 days.

You can decide to use Git and add Kirby and the Panel as submodules yourself.

You can still use vanilla CSS.

You still don’t need the panel if you love to edit text files.

And that is what I like so much: The basic way of using Kirby has not changed a lot. All the other bells and whistles are optional, we can use them if we see an advantage. But we can also stay away from that. And I hope, THAT is not going to change. I would deeply regret if Kirby became a monster like Wordpress and the like.

2 Likes
15

@servicethinker I agree with @texnixe. I was just thinking the same thing. The tools are there to help you work more efficient.

When I read your text I feel like you think:

Oh no, Bastian and crew has released something new. I can’t stop myself. I have to install it and use it.

You don’t have to do that. About the submodules thing, I have no opinion.

I can agree on that there has been more of the tools around rather than Kirby itself, like Patterns and CLI.

As much as I love those things, I hope to see more focus on Kirby + Toolkit + Panel.

16

Yeah, you’re right. It was just a feeling that we’re leaving the track…

@jenstornell That wasn’t the exact feeling I had. Sorry when it sounds to you (and potentially to others) like this. It was much more:

When the starterkit uses the Kirby CLI instead of the standardized Git-way, what’s happening with Kirby itself?

For me, the starterkit is a good starting point for newbies. Of course they can ignore the Kirby CLI enhancement (like I did with Git repositories). But everyone will get to the point where he or she asks how the beloved CMS could be updated more efficient.

Maybe I’m thinking too much about the ideal pedagogic way how people can learn to use Kirby. Sorry to start such a meta topic…

17

I think it is good to have that sort of discussion, that’s what this community is good for.

As regards the “the ideal pedagogic way”, maybe there is none. Because one Kirby beginner is quite unlike another Kirby beginner.

There are people who have never done any web development and try to start out with Kirby right away without any knowledge of HTML/CSS, let alone PHP.

And there are people who have developed/worked with other CMS like Wordpress or Typo 3 on an advanced level (not just installed a theme and added some content) for ages.

Both types, while Kirby beginners, have very different needs. Some might be used to workflows with tools like Gulp, SASS, Git or a CLI, and they expect to be able to continue using them when working with Kirby.

For others, all that is “Neuland” and they will have a hard time to learn all these new tools. But they can start low level and leave all that aside until they have enough knowledge to venture out on that journey.

1 Like
18

Hey :slight_smile:

Can you show me how you implemented your script? I would like to write a script that automatically creates blueprints, snippets, templates and more -> all in one

Best regards

19

I’m sorry, it was 4 years ago and I don’t remember!
I do remember thought that whatever I was thinking I didn’t move forward with it as Kirby CLI was good enough.

20

Okay
Thanks anyway! :smile: