I couldn’t find any post related to my problem which is in every deploy I performed, always the plugins installed directly in the production websites are removed even only deploying simple CSS changes of my template.
You will ask about why I installed my plugins directly in the production site and it’s because not all the plugins are available to install via composer so if there are not listed to install via composer then I need to install them directly in my production site.
That implies remove the folder from .gitignore. I think most people have that issue about not all the plugins are listed in the packagist to use with composer so, how you deal with the plugins when are not available to download via composer?
If I’m including either a private plugin that I’ve developed, or a premium plugin that isn’t available via composer from the developer I use the following:
I keep the plugin in a private GitHub repository with its own composer.json formatted like this:
Based on comments above this may be the wrong way to do it, but it’s working for me and keeps things organized and easy to read. It also makes the few premium plugins I keep this way easy to use in multiple projects.
This is a better way to do it. Committing plugins to the project also works, and really depends on what you’re doing. Like you said, if it’s a premium plugin, especially one you will use across multiple projects, then keeping it in it’s own repo is a good idea, then you just need to add it to your Composer file. If it’s specific to your project and won’t ever be used elsewhere, then you might as well add it to the project repo.
I find that keeping even singe-use plugins in their own repo (especially now with unlimited private repos at GitHub) means I have to remember fewer finicky .gitignore entries per project. Everything’s just the same. I’m lazy.
lol. I thought committing the plugin to the project was lazy. Putting it in it’s own repo does keep it separate, which can have benefits. But you need to run composer update on the Bedrock install and commit the lock file every time you want to deploy if you’ve made updates to any of those plugins.
Eh, I’m gonna run composer update if I update a non-custom plugin so in my mind it still keeps everything nicely categorized. Updating a plugin involves the same steps no matter the developer.