Plugin Developers: Convention for installation via Composer

[lukasbestle]

@mzur

Kirby could automatically look for packages installed via Composer and load them. This would change nothing ecxept that users don’t have to create a plugins/autoload.php file.

I agree with that. Seems like something that is quite easy to do actually. We could load the Composer autoloader when loading plugins if the file exists. Could you please open an issue in the Kirby repo?

@mzur

Would you as member of the Kirby developer team say that community polls make sense for design decisions? At the very least this could be used for prioritization of the different features.

Having feedback from the community is always useful. But of course there might be situations where we still want to implement something differently. So polls can only be a point of reference for us. We will start polls when we think that it’s useful for us.

@mzur

I’d say this is a feature since it is a symptom for logic in the template that rather belongs to a controller. Declaring all the namespaces in a template is cumbersome and looks ugly because you shouldn’t do it.

That’s true!
Back then we didn’t have controllers at all. But even now it sometimes doesn’t make sense to use a controller, for example if you need to call a simple Toolkit method like a::get() etc. Creating a controller just for that would make it all unnecessarily complicated for beginners. Don’t forget that controllers are an advanced feature!

@mzur

So it should actually reduce complexity to utilize only a single autoloading mechanism (Composer) instead of a mix of a custom autoloader, Composer and regular requires.

Definitely. I think we need to find a better way to utilize Composer though, the current way of committing the dependencies to the repo isn’t really optimal either.

[mzur]

@krisa

maybe if you could what would be achieved while requiring composer? I don’t have problem with it but i don’t see many real advantages either. If something - it will make it way harder for newcomers.

@krisa My main point is that Composer with PSR-4 enforces a certain structure for a codebase that lots of PHP devs are familiar with. Say there is an instance of a Page class. Where do I find it’s source? With PSR-4 I just have to follow the namespace to find the correct file. Enforcing an object oriented approach is also a plus IMO. Object oriented code can be mocked and extended which is great for testing. Note that all this doesn’t have to change the way how Kirby can be installed and used.

@lukasbestle

We could load the Composer autoloader when loading plugins if the file exists. Could you please open an issue in the Kirby repo?

Done.

@lukasbestle

I think we need to find a better way to utilize Composer though, the current way of committing the dependencies to the repo isn’t really optimal either.

Agreed, this is how the whole story started for me. I had to include all dependencies of the Uniform plugin in the repository to be compatible with the “traditional” method of installing plugins (and the CLI) and I’m not happy with that at all.

[fvsch]

@mzur To answer your initial question, the way I’m managing Composer now is by telling users of my plugins to require vendor/autoload.php from their site.php script:
See: Installing StaticBuilder with Composer.

On the other hand, in Kirby Twig’s installation doc I’m offering less detailed steps, most importantly I’m leaving out the part about requiring vendor/autoload.php, or where to call composer require kirby-twig from, since I expect Composer users to know what to do, but that’s a big assumption.

I also made an experimental boilerplate for a fully composerified Kirby install, which incidentally solves the Panel issue you’re mentioning. But the “load just before plugins” solutions proposed here are less invasive.

Finally, you’re talking about a convention for loading Composer’s vendor/autoload.php, but not for the “right” way to instantiate the plugin. Do we have any opinions about that, folks?

Instantiating a plugin often consists of:

• setting a few things in the Kirby Registry
• perhaps declaring a few helper functions

For instance, in Kirby Uniform the composer.json references the plugin’s index.php which is:

mzur/kirby-uniform/blob/master/index.php

And it also references src/helpers.php. Both files will be loaded when requiring vendor/autoload.php, whether that’s the one in the plugin’s directory as downloaded by kirby-cli or manually, or one at the root of the project when installing with Composer.

That looks alright but it requires sanity checks in case Kirby is not running (e.g. a different script tried to include vendor/autoload.php).

In my plugins I did things a bit differently, by creating a static method that does the registry stuff and the “let’s include a helpers script” stuff. You have to call it explicitly, which can happen in your site/config/config.php or in a site/plugins/whatever.php.

<?php
Kirby\Twig\Plugin::register();

It requires one more action from the plugin’s user, but it also gives some control back.
Any thoughts?