Closed s3ththompson closed 1 year ago
Thanks for the suggestion! So the kirby-cms-path
is no longer needed?
I'm not sure yet if this change is required for this plugin, as it has no index.php
that uses Kirby::plugin
. It should work fine in a regular Composer installation. Or are there any other benefits to the new recommended pattern?
It may be a different matter for Uniform, as this plugin actually uses Kirby::plugin
. But it needs to "hard code" kirby-flash and kirby-form in order to support the ZIP method of plugin installation. I don't see how this could be done any differently if all the required methods for plugin installation should still be supported. Any thoughts?
Hi @mzur!
The benefit of this change (even though this plugin doesn't use Kirby::plugin
) is that it allows kirby-form
to follow the expected convention of other Kirby plugins which are all installed in the site/plugins/
directory of a user's app. Without this change, kirby-form
is installed in the vendor
directory which is unexpected—and may break other parts of user's setup (e.g. it broke my editor's PHP typing).
This tutorial has a recommendation for supporting both composer and ZIP install methods (for Uniform). I think the gist is that they recommend checking in just the PHP code from vendored dependencies in the gitignore
.
(Addendum: my understanding from the plugin docs and doing some digging around other plugins is that the recommendation for composer.json
setup changed sometime in 2019 when the Pluginkit examples were published.)
The Kirby plugin docs now recommend using
getkirby/composer-installer
andtype: kirby-plugin
to ensure the plugin is set up in the expected Kirby path.(Prior to this change,
kirby-form
was not installed in the Kirby plugins directory, which broke my editor's PHP typing for it.)(Note: this issue also affects mzur/kirby-uniform, but I saw you were vendoring dependencies and wasn't sure if you wanted to move to composer-required dependencies...)