yesterday, @jenstornell introduced his great plugin-repository. I really like the idea of a centralized list of plugins. While playing around with the panel this morning, I thought it might be nice to have a list of all installed plugins, their version and description. So I started to build a simple widget.
The list of installed plugins was easy to get, the other information isn’t. As far as I see, there is no standard way to set meta-information to a plugin (like title, description, version, author, repo-url, author-url). Please correct me, if I’m wrong.
But this information might be very helpful. Even for security reasons (I then can easily see, if there is an update).
Wouldn’t it be nice to provide this information with each plugin? This could be done by using a PHP-Comment or by adding a version-file, including this information.
In combination with a central repo like the one @jenstornell set up, including the version-information etc. we would now be able to check for updates easily. There could be a list of plugins and update information in a Widget or a plugin-area of the panel.
Even without the panel part or the central repo, it would be nice to have place to get version and contact information for plugins etc. What do you think?
Just started thinking about it, so these comments are rather random:
On the one hand, it would be great to have the information, especially version number (or also repo url, if such a widget would like to check if its up to date via e.g. the github api), not just as a comment but actually as part of the code, so that it could be accessed easily via code. For bigger plugins, this could be easily done in some form of class properties we could agree upon.
But then there are also these smaller plugins that just are PHP function wrapped in a file. Or custom form field plugins. How would we deal with them?
But totally agree that this is a great idea and we should get there somehow!
You’re right, the structure of a plugin can be very different from one to another. Maybe this is a point for a separate version-file, like the package.json used by npm etc.
I don’t like the WordPress plugin style here which is having a PHP comment with version info. For me, a comment is a comment and I think that functions should not depend on a comment.
Use a file
My vote goes to use a complete separate file. It can be yaml or something similar, the best format for the job.
The problem of Kirby in this case is like you said that the files can be very scattered. A field is not a plugin in Kirby, it’s a field.
I suggest this:
If the plugin/field/whatever has a subfolder where you put the content, support version file. For example it would work on plugins and fields. It would not work on snippets and templates.
The downside of it is that large plugins both have a plugin folder and a fields folder. It would include a version for both the plugin and the field. Maybe it’s a good thing, I don’t know.
The old Kirby 1 “extensions” had package.json files. Back then to be machine-readable for kpm, my Kirby package manager that never got finished (also because all plugins are different and can’t really be installed automatically).
But I agree that some standard to define meta data would be great. However I don’t think that the Panel will be able to display the information because of the, well, different ways plugins are currently installed. Also see this and this topic.
I just thought of this and think it’s worth a new try for Kirby 2. Just started with the basics to see how far we can push the limits. Could help to get the Kirby plugin community on a better level, establishing some common standards.
Definitely, I think that it would be awesome. But from my experience with kpm, it would probably make sense to implement some kind of plugin bundles (plugins that can register fields, templates, controllers, models, snippets etc.) and base the package manager on that instead of putting that complexity into the package manager.
I think we could actually implement bundles. Shouldn’t be too complex: A site/bundles directory and a loader that loads the main bundle file (like with plugins) and registers the subdirectories of the bundles as search directories for the other components:
site/bundles/
mybundle/
mybundle.php # Main bundle file
snippets/
...
Yea, I like the approach. Just not sure if it makes sense to throw another pull request at @bastianallgeier right now. Already quite a few open, haha. Should we go with bundles or rather packages. The latter is more common, though bundles is more descriptive of what it does in comparison to plugins, fields, widgets etc. - then I’d start a bundle manager
So far it only lists all Plugins, Fields and Widgets and tries to get the name from a package.json with fallback to the file/folder name. Should not be seen as a ready widget but more as a work in progress to see what functions, ideas, other ways to do it we can think of. So any contributions (if code, if comments…) are more than welcome and appreciated!
I’d prefer staying with the plugins folder to adding an additional folder just for “bundles” or “packages”. After all, they are also plugins, just bundled together with other stuff.
But this discussion could also lead to a completely new one – when we have the abbility to either register a field in a bundle or stick with the current method and place the files in site/files, shouldn’t there be one “default” or officially recommended way?
As I’m writing, I have two other ideas for the bundle/package/… name: modules or extensions. Especially the latter is self-explaining and does not exclude any possible extensions (fields, widgets, snippets, plugins, …)
I agree that the plugin folder would be best if Kirby was built today. In real life it would probably be hard to use the same folder, because the collision with the structure of how the plugins work now.
On the other hand if we have the bundle/package-thing built and people starting to use it for their plugins… What is a plugin in the future? When a bundle includes fields, widgets and plugins then I feel that plugins is not a correct word for it anymore because the bundle is the plugin.
I think the main difference is that a bundle/package/extension/module/… is a self-contained piece of functionality extension from a third-party while a plugin can be as simple as a single file defining a helper function for the specific site. That’s why I think plugins still make sense.
(Yes, a bundle with a single file basically has the same functionality as a plugin but a bundle has more rules like a package.json and you absolutely need to make sure that the subdirectories are named correctly. A plugin can be structured however you want, which is way less complex and confusing for simple plugins).
YAML is great, but I think we should follow the convention of other platforms. package.json is more or less a standard. But yes, why not? Maybe it even makes sense to do it in a different way to make clear that it works differently.
Sounds good. But on the other hand, this will create an if-rule that makes it all more complex to debug. Let’s say someone creates a bundle and the snippets are not loaded. Turns out he/she forgot the definition file.
)