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.
@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:
- perhaps adding it as a listing in the plugins directory - not sure whether itās appropriate, as itās not really a āpluginā
- 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
- 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 like JeffreyWayās generators for Laravel https://github.com/laracasts/Laravel-5-Generators-Extended
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.
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).
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 packagist.org 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!
@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 getkirby.com / getkirby-plugins.com / 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ā¦
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.
http://forum.getkirby.com/t/plugins-combine-fields-widgets-methods/358/3?u=luke
Has work on this project stopped?
That would be a tremendous shame!..