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.
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.
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.
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).
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.
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?
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.
!!!, it looks like a widget who i can see my Newest Plugin Version’s