Plugin Developers: Convention for installation via Composer

Kirby 2 Solutions 🎉
1

Recently I was made aware of a flaw in the Composer installation instructions of my Uniform plugin. With the require 'vendor/autoload.php' in the root index.php the plugin was only available in the frontend and not in the Panel. I’ve now come up with a new way to load plugins that have been installed via Composer: A file site/plugins/autoload.php with the content:

<?php

require kirby()->roots()->index().DS.'vendor'.DS.'autoload.php';

This file is loaded like an ordinary plugin and makes the Composer autoloader available both in the frontend and Panel. As this file would work for all plugins that were installed via Composer I’d like to ask you fellow plugin developers for your opinion. Maybe we can recommend this as a convention for all Kirby plugins that support Composer, what do you think?

In the long run we might even be able to convince the Kirby developers to support Composer “natively”, maybe like this on every Kirby startup:

try {
   include_once 'vendor'.DS.'autoload.php';
} catch (ErrorException $e) {
   // never mind
}
2

Probably great, but I think “Solutions” would be a better category for this?

3

Yeah, you’re right. I wasn’t sure to which category I should put this. If I’ve got you on board with this idea we might have covered 50% of the Kirby plugins already, great! :smiley:

2 Likes
4

LOL. :smiley:

Recently I deleted a bunch of plugins that was not good enough. Now I have only made 11% of all the Kirby plugins that we know about.

5

I would totally love to see Kirby embracing the latest enhancements to the PHP world like Composer, PSR-4, better use of namespace… to name a few. But that would probably require a major refactor.

Your solution is very clever and would work great. My only concern is that it would limit the plugin reach considering Kirby’s user base. From the questions I see on the forum and a few legacy projects I took over to fix something, it seems that a large number of projects are still maintained the “old” way (I might be wrong on this). Since Composer required command line knowledge, wouldn’t it limit the plugin’s use and require more of our time in helping people troubleshoot issues? I’d love to hear other’s view on this…

I’m all for using modern PHP features and tools. I look forward to seeing this being integrated into Kirby.

For my plugin that requires a Composer package I have required the autoload.php on the plugin and committed the vendor folder to the plugin repo. Far from ideal but the only way I found to allow the plugin to be installed using Kirby’s CLI.

6

I’m not a Composer person, have never tried it. Would this mean that Composer would be required to install a Kirby plugin? or would it mean only that it would be easier to install with Composer?

I don’t think it’s a good idea to force Composer to install things. Some use CLI, some FTP, some Composer and some Git submodule. I would like it to stay that way. The trends will change and then it’s good that Kirby + plugins will still work.

7

I’ve actually done the same with one of my plugins. As you say, not ideal, but if we don’t want to force people to use composer, which is also not ideal, then I don’t see any other way.

8

@pedroborges I’ve done the same with Uniform. If the plugin is installed with the CLI or the “traditional” way the plugin’s vendor directory is used. If the plugin was installed with Composer the directory is ignored.

@jenstornell My proposal targets use cases where developers know how to use Composer and want to install plugins that way. It would make their life easier but won’t change anything for everybody else.

I’m a big fan of Composer and the way projects like Laravel are built using it. I know that Kirby is intended to be approachable by non-experts but I wonder how large that portion of Kirby users is compared to the “professionals” who know their way around the command line. This might be important to know for future decisions where Kirby development should be heading. Generally I’d like the idea of “Kirby polls” where the community is asked for their opinion on (important) design decisions.

1 Like
9

I’m also a big fan of how you can require a Composer package in Laravel projects, register its service provider and be good to go.

Agreed :ok_hand:

10

@mzur

I wonder how large that portion of Kirby users is compared to the “professionals” who know their way around the command line.

You think that the command line is a measurement for a professional developer? I don’t think it’s that simple. We are good at different things. For example I like to use Github with an UI, not the command line, because I like to see things visually. So I guess I’m a newbie in here. :slight_smile:

Generally I’d like the idea of “Kirby polls”

I agree and I’ve thought about it myself. :slight_smile: But be aware that the people answering it will probably be the most dedicated Kirby users, probably not that many new ones. If I was a new user I would probably not start with filling out polls.

11

I tested to create an open Google+ group which supports polls. I also added a poll. Try it out if you want. :slight_smile:

12

I’m not saying you can’t be a professional when you don’t use the command line. You can build and publish websites just fine without. But knowing the command line is essential for building webapplications because that’s the way servers and the applications themselves are managed. And this ist the area where Composer is heavily used in PHP land.

Right that may be a problem. You can only publicise the poll as much as possible (e.g. mention it in the newsletter) and hope that most users participate. You can’t listen to users who don’t say anything.

Wouldn’t Google Forms be a better option as it does not require a Google+ account?

13

And this ist the area where Composer is heavily used in PHP land.

Probably yes. I still like how Kirby try to be trend independent. Maybe you don’t see Composer as a trend but it could be. For example, a while ago I felt like everyone was using Grunt as a task manager, but when Gulp came many just switched to that and now I don’t hear anyone talk about Grunt anymore. In conclusion I hope that Kirby will be as indepenent as possible.

Wouldn’t Google Forms be a better option as it does not require a Google+ account?

If you have a Google account then I think that’s enough (untested)? Google Forms also require a Google account? I think that Google Forms looks a bit more complicated.

Maybe there is a completely other solution to this problem? For only yes/no answers we could use Github issues where thumb up/thumb down could be used as votes, but it might not be the best solution for more precise answers.

14

It does not require an account to fill out and submit the forms, only to create and manage them. Try this in a private tab without Google login.

15

Alright, that looks quite nice. I have filled it in. But it does not show the stats?

16

The stats are always visible for the creator of the form. They can be enabled and published for everybody who filled out the form, too, but IMO this should be done only when the poll finished.

17

Personally I like to see how other people voted and how many that voted during the vote, but I understand why there could be a reason for hiding it, the bandwagon effect.

18

Very interesting discussion. Just a few comments:

A bit of history: When Bastian rewrote Kirby 1 to a never released 1.5 version (that eventually became Kirby 2), it had a lot of those “modern enhancements” like namespaces and PSR-4. It meant that users would have to load in all those namespaces in their template files and also generated a lot of nested but otherwise empty namespace directories in the Kirby source (you often see this in PHP libraries).
We tried aliasing the important classes so that they could be used without namespaces, but it’s not only a huge performance and elegance issue but also misses the point of namespaces.

So: In the end we actually refactored Kirby 1.5 to become Kirby 2 by removing those enhancements. It just doesn’t really make sense for a CMS to introduce this complexity.

To be honest I don’t think it’s about “expert vs. non-expert”. It’s more about “introducing complexity vs. keeping it simple”. I know that introducing this complexity can be well worth it, but Kirby has always been a CMS that is deliberately simple. We want our users to be able to throw it on a server somewhere and get started. Even I as an expert like that very much when starting a new project.

That is very true. I don’t see Composer as a trend (the idea behind it is really good and that won’t change if it’s replaced by some other tool at some point), but PSR is just a bit opinionated. It introduces external complexity where it is not always required.

Did you know that Discourse supports polls?

  • Yes, I knew that.
  • No, I didn’t.
0 voters

:wink:

4 Likes
19

@lukasbestle Thanks for chiming in. First of all my original proposal in this thread is not to make a Kirby installation depend on Composer but to make Kirby more compatible with the way Composer installs plugins or other packages. The first step is the plugins/autoload.php convention that would enable all plugins (and packages) to be installable via Composer. This is trivial to set up and could be made an “official” recommendation for everyone who wants to use Kirby with Composer. The next step might be “native” support for Composer packages. 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.

Now to the other points that popped up in this thread (maybe we can split the discussion).

Polls
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.

Namespaces/PSR-4

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.

You have a point but I wouldn’t call it introducing complexity because that implies some degree of chaos. Instead Composer (with PSR-4) enforces a common structure to projects that can be easily understood by developers. Also, this kind of “complicatedness” in the development toolchain does not necessarily imply that Kirby is more complicated to use. What’s more, you are already using Composer for the Toolkit, Panel and Kirby core. 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.

Please don’t misinterpret the tone of my post. I’m not saying “this is wrong and you should change it”. I’m just defending my point of view so we can have a constructive discussion about this :wink:

Just to try out the polls:

  • Let’s continue the discussion.
  • Bugger off with your Composer gibberish.
0 voters
1 Like
20

So i like command line since i run my on server and we use build tools from npm.

I like composer and i like kirby-cli.

I am also not the greatest php developer, mainly because ive simply not been doing it for that long compared to javascript (and node for that matter).

So i can safely say that whole javaesque verbose approach to classes and namespaces can be confusing for newcomers. Ofcourse this is me being lazy to actually pick up a book, learn it and be done with it. Often times i just revert to javascript style of more functional approach while writing php just piling functions on functions.

But the question realy is - does kirby need the complexity?

Lately ive been going through some of the kirby sourcecode and most of the time its very simple. I really like the codebase. Its very to the point and its not over engineered. Its few classes of very sensible things and clear methods. Its actually quite boring and thats a good thing.

Contrasting this with something like Grav (which approach i think you would like) - there is abstraction for everything. Lot of things done in ways “its supposed to be done”. For example - “straight php is evil! You must use twig for safety” Well thats some gained knowledge php devs believe in. The thing is Twig is made to show stuff already prepared from db, in filebased cms you are getting data mainly from traversing pages. So their approach is to basicaly extend Gravs twig more and more for functions that allow traversing the pages basicaly recreating php.

Sidestory:

This happens a lot for example with the whole bootstrap approach - you need few buttons and form and instead of writing few lines of css you include 100kb library and more importantly you have to learn big amount of classes - the whole thing is completely artificial and abstracted. To allow more customisation bootstrap adds more and more classes so in the end it can become class=“col-sm-6 col-md-5 offset-md-2 col-lg-6 offset-lg-0” just to do columns (this is from docs). Not mention you have to add more 10 classes for type and clearing etc… and in the end you still add your class “article” because in the end you still need to add some specific css…

Then they realize the website is becoming quite slow because of 30 js/css libraries used so create complicated build process that tries to find unused css and deletes it from your css file for which you need to use webpack and you have to walk every single page - so the build time takes 10 seconds. Webpack is then used for tree shaking of your js files. So you learn webpack and next year webpack is replaced by rollup…
End of sidestory:

I guess you get my point.

This is why i like Kirby - its boring. Its small. Please leave it at that.

Everybody in the startup world laughs at deploying with ftp (although we deploy with git). Yet when you get to the real world is about what works.

@mzur 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.

3 Likes