Packages Manager

Thought I’ll open a new topic to not make the other topic too confusing…

Started building a packages manager widget/plugin. Name still open to change and so all the rest of it. Mainly a little project to play around and explore how plugins/extensions/bundles/modules of all kind for Kirby could look like in the future.

To push common standards as maybe the package.json.

You can find an early alpha here:

Already with version checks, but way too slow with every reload. Need to implement some caching here :wink:

I would love to hear feedback, comments, contributions (code and conceptual). Would love to make this a community project.


Latest or not

Would be nice to have it compare the plugin versions to the repository on Github. Mark green on having latest and red/orange if the plugin is outdated. Do nothing if the plugin does not use Github.

That requires caching as well.

External link

Link to the site for the plugin could be nice as well.


I think using package.json would make sense considering a lot of people already use Node modules as development dependancies in their plugins.

You could probably time the package version checks by caching the timestamp of the last version check and checking for a specific interval of time between the current timestamp and the previous timestamp on load. I think this is how Wordpress’ virtual cron works.

Would be much less heavy than polling every packages’ package.json.

1 Like

Already does that. Not bug free yet though. And I’m working on caching to make it actually usable.

Yea, my current thought is to locally cache the remote/GitHub package.json and throw them away every x hours/days.

Added version caching. First load is still brutal. Would probably be great to delay that through JS.


  • black: no remote repository known from the package.json
  • green: local version is not smaller than repository
  • red: local version is smaller than repository
  • grey: remote repository known but no remote version available

What would you say is a good caching timespan, @jenstornell and @PaulMorel?

I’d say once a day.

By the way: Instead of using your own cache, you could use the Kirby one. It even supports automatic expiration.

Haha, yea I know, I thought about it. But then I couldn’t remember from my head how to set it up and went with a quick custom cache instead. But will switch to the toolkit soon.

Personally I think 1 day is a good compromise between performance and update frequency. For example when plugins are released, you often see hotfixes being pushed the subsequent days.

If you could stagger the version checks by a minute between each package, I think it could speed up the process.

1 Like

Moved everything to using the toolkit cache. Standard cache lifespan is a day +/- 15 minutes (randomly chosen).

Any ideas for a good way of staggering the checks for the first load ever (or any other load where no cache exists anymore and a lot of packages need to be checked)?

EDIT: Another screenshot to show the warning color if an update is available


Have you thought about using a composer.json instead of a package.json? Kirby is a PHP and not a Node project after all. For those people using it, Composer could then install and update the plugins, too (if the plugins support it, but we could encourage this).

1 Like

The +/- 15 minutes idea is fantastic! Regarding the initial check: How long does it take for a few plugins? If it is less than a few seconds, that’s probably alright.

Otherwise you could maybe limit the checks per widget call to a specific number (like 3 or 5). Every time the page loads, 3 plugins would be checked at max.

1 Like

Great idea! There is already a Kirby plugin installer for Composer, so that could be used instead of building yet another package manager.

What Kirby could do is to add information about how to use it (both for plugin devs and users) to the documentation once the plugin bundles are implemented.

I’m very open to all these suggestions. I fact, I’d like to see some consensus among the active developer community and then just implement it. Just started with package.json. I know, that at least a few people would prefer YAML. And given its use in Kirby, I also see that point.

@lukasbestle: At the moment I’m doing a lousy URL reqrite to the raw package.json file on GitHub and load it with f::read. GitHub drags quite a bit. So with 8-10 plugins, this actually can take double digit seconds. I also thought of that max-limit per page load, think it’s a good way to go.

Yeah, that’s quite much.
If we used Composer, we could let Composer handle the version checking instead of manually grabbing the data from GitHub. So your widget could even update the plugins automatically without much extra work.

I have done way too little with composer (let’s say none) to have a real opinion about this. But isn’t composer more about installing/updating things… would it also work as a place to store more information maybe then the version number?

And: Does a standard Apache server run composer out of the box?

I don’t think it does. IIRC Composer is a PHP module and not an Apache module.

This is a Rly Cool Idea :smiley: !!!, it looks like a widget who i can see my Newest Plugin Version’s

The composer.json schema supports some other meta data as well. And I think it should be able to be extended.

It’s neither. It’s just a PHP application bundled as a Phar archive.

Hmm, I’m a bit sceptical if it fits for the general Kirby community?

1 Like

Packages Manager feedback

Great work! I did not think you would have time for funny projects like this. :wink:

  • 24 hours as a default. c::set('packages.manager.interval') for time interval (minutes)? Even disable it by false?
  • Hard to differ the green from the gray. Bold the numbers? Or invert it as a message bubble?
  • Last check date. Could be nice to see when it was last checked against repo.
  • When having 3 things or more it could be better organized with a table layout.
  • Like @lukasbestle said, check maximum 3 at once.
  • Use ajax for the update if not already.

Don’t use composer.json or package.json

The more I read about it the less I like it. Me and some other suggested YAML instead.

Here is why:

Kirby uses PHP and YAML, not JSON

JSON is great, but in Kirby YAML is the language for almost everything that is not PHP in Kirby. Why introduce another language, another complexity, another abstraction?

YAML is easier to read and write

There is a reason Kirby don’t use JSON for content. It’s hard to read and hard to write. YAML is easier to read and write and that makes it easier to understand for new people as well.

Kirby tries to not rely on third-party software. Why start now?

A good thing with Kirby is that it does make itself dependent on other software. The JSON file itself will not make it dependent on for example Composer but all the docs and so on would push the plugin creators that way.

Kirby don’t usually force a single technique

Like the case with Twig. Kirby did not choose Twig and not any other template engine because it don’t want to be dependent on anything. Instead of forcing a way doing a task, it encourages us to do how we like. Don’t force us to use Composer.

What if Composer changes?

Composer is there now. Is it there in 10 years? Is it free in 10 years? Is it still named Composer? Does it have the same syntax?

Everything can change. That would force Kirby to change as well. We can’t call it composer.json if Composer changed name.

Don’t rely on third-party software.



1 Like