However, there are very few plugins available through wpackagist. In my current project, I managed to find 2 plugins out of 7 that I’m using.
Consequently, I’m installing plugins manually, directly though WP dashboard - both locally and on staging.
Unfortunately, these plugins are gone after each deploy to the remote server. Then I’m forced to install these manually-managed plugins time after time after deploying my codebase.
What would be the best way to manage plugin dependencies with Bedrock, plugins that are not available though http://wpackagist.org/ ?
I considered two ways to go:
Making a git sub-tree or sub-module with plugins only (this however is not too good since, it’d be cumbersome to perform plugin updates and also necessitates keeping whole plugins’ code in the repo)
Modifying the “deploy” task so that it preserves the plugins folder on each subsequent deploy
The easiest thing is to add any premium plugins (ones not available via wpackagist or Github) to your project’s version control. Yes you’re adding third party code to your project, but in this instance at least you’re not reinstalling plugins every deploy. That sounds horrible.
Your other options are to set up each plugin in it’s own Git repository, you could do this on Github or Bitbucket, and add a valid composer.json to each plugin, that would allow you to pull in those plugins to multiple projects. But then you’re stuck updating them manually via Git after every update.
You can also look into creating your own Packagist service with Satis (free) or Toran (paid service). This would give the most Packagist like experience.
How are you searching WPackagist? I’ve noticed that searching by plugin name doesn’t yield that many results. When you search for the plugin’s package name, which is how the zipped file is called in the WordPress plugin directory, I’m able to find most, if not all, plugins.
So you might want to try “my-wordpress-plugin” instead of “My WordPress Plugin”.
I have worked on sites where we have a Toran server and we garden the paid plugins in their own gitlab repos and such. I have also worked on sites where we just check the paid plugins into git. Both methods work great.
Thanks guys, theses are all great solutions. However, in my case the problem was the way I was searching for plugins… this is definitely wpackagist’s shortcoming…