I'll answer my own question. There's an ongoing discussion as how an OctoberCMS projet should be deployed so it's a bit difficult to know what the best practices are.
Dependencies in Plugin definition
The core dev solution seems to add dependencies in your plugin as an Array :
/**
* @var array Plugin dependencies
*/
public $require = ['RainLab.Blog', 'RainLab.User', 'RainLab.Pages', 'Manogi.Mediathumb'];```
In my case though dependencies are not installed automatically and while I get a warning, my plugin is still loaded with errors.
Using composer
I realised that plugins from RainLab have a composer.json file with october-plugin
as type (See RainLab.User plugin for example).
So you could simply require a plugin as any composer package, and they'll install in your plugin/
directory :
composer require rainlab/user-plugin
Not every plugin has this convention though, like the Manogi.Mediathumb plugin. I haven't tried to require it but I'm guessing it'll be installed in the vendor/
directory.
Example composer.json
requirements :
"require": {
"php": ">=5.5.9",
"october/rain": "~1.0",
"october/system": "~1.0",
"october/backend": "~1.0",
"october/cms": "~1.0",
"laravel/framework": "5.1.*",
"wikimedia/composer-merge-plugin": "dev-master",
"vojtasvoboda/oc-twigextensions-plugin": "dev-master",
"rainlab/blog-plugin": "dev-master",
"rainlab/pages-plugin": "dev-master",
"rainlab/user-plugin": "dev-master",
}
Ignore plugin folders in git
As for ignoring vendor plugins, you could add rules in your .gitignore
file that ignores every plugin except for your namespace :
plugins/*
!plugins
!plugins/mynamespace/
Disable update feature in CMS
Last step is to change the disableCoreUpdates
variable in config/cms.php
:
'disableCoreUpdates' => true,
As stated in a comment section in this file :
If using composer or git to download updates to the core files, set this value to 'true' to prevent the update gateway from trying to download these files again as part of the application update process. Plugins and themes will still be downloaded.
Update with composer
Now if you want to update the core packages and plugins, run
composer update
Create a project on October website
Suggested here. I'm not a fan on depending on a service for this kind of stuff though.
Conclusion
I guess the two first approaches are valid and depend on whether you'd like to update in CLI or directly in the CMS (also whether you'd like your client to be able to update I guess).
I'll test the first one again and see if I can make the CMS download the plugins automatically. If I succeed I'll go with this solution since I can update from the CMS and from the command line with php artisan october:update
. Best of both worlds.