Using Bedrock / Composer with "premium" plugins w/ no repo or source

brett · January 4, 2015, 11:26pm

I’m attempting to use Bedrock for a new site I’m building. The site uses Gravity Forms, which is unavailable both on WPackagist and GitHub.

The /app/plugins/ directory is .gitignored, so when I do a push to deploy the stuff to the server, none of the plugins are being deployed with it (though the theme is, which makes sense).

That’s all well and good, as I then SSH to the server and run composer install, but of course since GravityForms isn’t on composer it is not installed. At this point my options are either to:

Modify .gitignore to specifically allow this plugin to be uploaded and tracked in git.
Manually upload the files for this plugin.

Surely there’s a better way? I’ve read a couple guides about turning the plugin into a composer package, but at that point wouldn’t I still have to upload it to a repo or something so Composer will be able to download it?

Is there any way to tell composer “this thing is a plugin, it’s a package but it doesn’t have a remote source. the source exists locally in this location. take it from there and install it to the regular folder with the rest of the plugins”.

Sorry if any of this is vague, and thanks in advance!

swalkinshaw · January 5, 2015, 12:33am

No, you can’t do what you want unfortunately. There’s no such thing as a local folder source for a Composer package. Composer can use a local git repo as a package source though but that would mean having a nested git repo in another and… just do that.

The best choice is to turn it into a Composer package but as you said that’s also the most work. Least work is just including it and whitelist the folder in your .gitignore.

austin · January 6, 2015, 7:08pm

Yeah most of the time I end up just checking it into git. When things start getting out of hand I usually just upload the zip to my s3 and reference it this way: https://getcomposer.org/doc/05-repositories.md#package-2

This gets tedious pretty quick though.

etc · January 8, 2015, 1:24am

We manage all of our premium and third party plugins with a Toran server. We were using a custom Packagist server originally, since dist packages of private repos were only available through the BB and Github APIs, so we needed the packages to be proxied by Toran.

If you’re investing in Bedrock as a primary stack, I highly recommend spending a weekend and setting up a similar system yourself. We now have about 180 items in our Toran server. Because of the manual labor involved in the creation of the repos as well as updating of the plugins (most of which require a license, or are done separately) we wrote a local command line tool that automates the process, and created a super wp instance whose sole job is to update plugins in the repos. So now, for about 90% of the plugins, we always have access to the newest version.

Let me know if you’re interested, and I can guide you through portions of that process.

etc · January 8, 2015, 1:25am

Touching upon what Austin suggested, you should be able to create a local web instance (such as with MAMP or something similar) and just keep the zips in there.

Idealien · January 10, 2015, 10:35pm

I’d be interested to see / learn more about the setup you describe.

If you have local git repos (for private plugins) did you look at Satis at all before going to Toran?

emaildano · January 13, 2015, 3:51pm

The official composer site lists using packages with VCS’s here:

https://getcomposer.org/doc/05-repositories.md#vcs

I do use premium plugins with Composer / Bedrock but I don’t go that route as these plugins aren’t ones I contribute to and don’t have a need to track them with Git, etc…

My preferred setup for using premium plugins with Composer is as follows:

Each premium plugin a composer.json file with the appropriate info. I’ll include an example below.
The plugin then gets zipped, without including __MACOSX (if you’re on a mac). The way to do that is with the following command in terminal zip -r -X plugin_name_1.0.0.zip plugin_folder. If you notice I included the plugin version. That will help with managing versions.
Upload zipped plugin to a server, CDN, etc. I use Amazon S3. It’s great and currently costs nothing.
Declare your plugin in your Bedrock composer.json file. I’ll include an example below.
Try it out!

@brett: Re: #3 and your original question. I don’t see any reason why this wouldn’t work locally as-well. With a path such as ~/plugins/plugin.zip.

Composer file zipped with plugin.

{
  "name": "company-name/plugin-name",
  "description": "I usually pull this right from the plugin description.",
  "keywords": ["wordpress", "plugin", "etc", "etc"],
  "homepage": "https://example.com",
  "license": "Match plugins original lisence",
  "authors": [
    {
      "name": "Original Author",
      "email": "original@author-email.com",
      "homepage": "http://www.original-author-website.com/"
    }
  ],
  "type": "wordpress-plugin",
  "require": {
    "composer/installers": "v1.0.6"
  }
}

The following is included with in the Bedrock composer.json file.
Define your package between "repositories": [...]

    {
      "type": "package",
      "package": {
        "name": "company-name/plugin-name",
        "version": "1.0.0",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "http://example.com/plugin.zip"
        },
        "require" : {
          "fancyguy/webroot-installer": "1.1.0"
        }
      }
    }

Declare your package in "require": {...}

"company-name/plugin-name": "1.0.0"

Few tips:

If you make a few mistakes while testing this out, try clearing Composers cache. It’ll ensure you are pulling in the latest version of your plugin. rm -rf ~/.composer/cache
The path to your local zip file goes in "url":, just in case you don’t already know that.

Good luck!

brett · February 19, 2015, 9:20am

Just wanted to thank you all for the replies and let you know that I have read them. I ended up just including the plugin directory manually and then setting an exclusion in .gitignore so it would be added to the repo. I figured if I can’t use composer to version it, I might as well be able to use git to do so. I probably should have set it up as a submodule / subtree, but eh, didn’t have time for that project unfortunately. Next time I run into the issue I’ll probably implement one of the great suggestions here.

Actually, emaildano’s solution sounds pretty ideal for my needs, so I may try to implement that retroactively.

etc · February 25, 2015, 11:32pm

Sorry - I didn’t get notified of this reply.

I don’t use Satis because I need something more dynamic. Both Packagist and Toran will allow for hooked reindexing. As well, Toran proxies the package so we don’t have to worry about Github access, only access to the Toran server itself, which can be locked down by ip or http auth.

jajouka · July 9, 2015, 7:55pm

i am trying to set up toran proxy for this purpose (premium plugins) and also for custom plugins, however following their instructions and using a simple composer json file results in the error:

[Seld\JsonLint\ParsingException]
“http://toran.local/app.php/repo/packagist/packages.json” does not contain valid JSON
Parse error on line 1:

Warning</b
^
Expected one of: ‘STRING’, ‘NUMBER’, ‘NULL’, ‘TRUE’, ‘FALSE’, ‘{’, ‘[’

I am almost ready to ditch toran proxy for satis

here is my composer json file

  {
    "repositories": [ 
    {
      "type": "composer",
      "url": "http://wpackagist.org"
    },
    {
      "type": "composer", 
      "url": "http://toran.local/app.php/repo/private/"
    },
    {
      "type": "composer", 
      "url": "http://toran.local/app.php/repo/packagist/"
    },
    {
      "packagist": false
    }
  ],
  "minimum-stability": "dev",
  "prefer-stable": true,
  "require": {
    "php": ">=5.4",
    "composer/installers": "~1.0.12",
    "wpplex/wp-options": "*"
  }
}

jajouka · July 9, 2015, 7:59pm

i have two packages in my toran packagist repo

wp-api/wp-api
wp-cli/wp-cli

anthonyscolaro · December 8, 2015, 6:55pm

I’ve been working towards a way to do this and would like to understand how you’re managing this. I’m super interested in seeing how you did this.

anthonyscolaro · December 22, 2015, 5:38am

Hi etc! Not sure if you saw my reply. Would love to learn more. I have some time over the holidays and would love to focus on streamline WordPress core/plugin management across our client websites. Thanks!

trainoasis · June 13, 2019, 1:53pm

Is perhaps Release Belt useful? Check https://wpahead.com/premium-plugins-composer/ as well.

bzx · October 17, 2019, 9:43pm

@trainoasis tried Release Belt - but I ran into errors when deploying with capistrano, and I didn’t want to deal with this. Setting a private repo (on GH, BB, or your own server) with the plugin files seems to be working just fine, see: https://roots.io/guides/private-or-commercial-wordpress-plugins-as-composer-dependencies/ … no problems with deployment either.

trainoasis · November 27, 2019, 8:40am

I myself am using private git repos too yeah. cheers