Plugins removed on every deploy to production

Hi!

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.

Kind regards!

1 Like

The only real way around that afaik is to include the plugins in your repo.

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?

The only real way around that afaik is to include the plugins in your repo.

1 Like

You can put your plugins in repositories of their own.

Then you’ll need to add the following to your composer.json.

In the repositories section:

{
  "type": "package",
  "package": {
    "name": "name/plugin-name",
    "version": "dev-master",
    "type": "wordpress-plugin",
    "source": {
      "url": "git@insert-repository-link",
      "type": "git",
      "reference": "1.0.4" // branch or tag reference
    }
  }
}

You can then reference it in the require section like this:

"name/plugin-name": "dev-master"

And finally I think you need to add these two lines just before the line “extra” (on the same level)

"minimum-stability": "dev",
"prefer-stable": true,
1 Like

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:

{
  "name": "mwdelaney/reponame",
  "description": "",
  "keywords": ["wordpress", "plugin",],
  "homepage": "https://github.com/mwdelaney/reponame",
  "license": "MIT",
  "authors": [
    {
      "name": "Michael W. Delaney",
      "email": "mwdelaney@mydomain.com",
      "homepage": ""
    }
  ],
  "type": "wordpress-plugin",
  "require": {
    "php": ">=5.3.2"
  }
}

Add this to my project’s composer.json in repositories

    {
      "type": "vcs",
      "url": "git@github.com:mwdelaney/reponame.git"
    },

And then add this to composer.json in require

    "mwdelaney/reponame": "dev-master"

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.

4 Likes

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.

1 Like

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.

1 Like

Nicely done,

I imagine this would work the same with Bitbucket repositories as well correct?

Thanks