Best Practice: Adding Gravity Forms (and other plugins)

Hey guys,
I’ve found a couple different methods for adding private repos or paid plugins to composer. I thought I’d ask your guys’ preferred method before doing anything.

Here’s the method I’m planning on trying first. It involves creating a repository on your own server.

It may seem a little more complicated than it needs to be. That’s why I thought I’d see if anyone has any better ideas.

Thanks guys!

1 Like

I’m using this method for ACF Pro: http://support.advancedcustomfields.com/forums/topic/composer-support/
It’s not ideal since you have to manually change the version number, but works for now.

2 Likes

@Twansparant Cool! That’s helpful, but I’m not sure what I’d replace “http://connect.advancedcustomfields.com/index.php?p=pro&a=download&k=” with.

I’m gonna shoot Gravity Forms an email and see if they can help with that.

Try this url:

http://s3.amazonaws.com/gravityforms/releases/gravityforms_1.9.14.25.zip?AWSAccessKeyId=ACCESSKEY&Expires=EXPIREDATE&Signature=SIGNATURE

And replace ACCESSKEY, EXPIREDATE & SIGNATURE for your actual credentials (which you can find here: https://www.gravityhelp.com/downloads/ when logged in)

2 Likes

@Twansparant thanks man!

I marked that as the solution. I opened another topic I want to resolve before trying this. But I’ll come back to it if it doesn’t work. Seems like it should. Thanks again for coming up with the url. I have no idea how you located it. :relaxed:

I just tested it and it works!
You can normally find these download url’s by logging in to these premium plugin accounts and look for the download page. There you normally have download links to the latest version of the plugin.

So adding this to your composer.json lets you install two very popular premium plugins using composer:

  "repositories": [
    {
      "type": "composer",
      "url": "http://wpackagist.org"
    },
    {
      "type": "package",
      "package": {
        "name": "advanced-custom-fields/advanced-custom-fields-pro",
        "version": "5.3.2.2",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "http://connect.advancedcustomfields.com/index.php?p=pro&a=download&k=LICENSEKEY"
        }
      }
    },
    {
      "type": "package",
      "package": {
        "name": "gravityforms/gravityforms",
        "version": "1.9.14.25",
        "type": "wordpress-plugin",
        "dist": {
          "type": "zip",
          "url": "http://s3.amazonaws.com/gravityforms/releases/gravityforms_1.9.14.25.zip?AWSAccessKeyId=ACCESSKEY&Expires=EXPIREDATE&Signature=SIGNATURE"
        }
      }
    }
  ],
  "require": {
    "php": ">=5.5",
    "composer/installers": "~1.0.12",
    "vlucas/phpdotenv": "^2.1",
    "johnpbloch/wordpress": "4.3.1",
    "roots/soil": "^3.6",
    "advanced-custom-fields/advanced-custom-fields-pro": "5.3.2.2",
    "gravityforms/gravityforms": "1.9.14.25"
  },

After adding this, just run composer update!

4 Likes

Ah I see! The download generates a personal URL when logged in. That’s cool, I still don’t think I’d have been able to decipher it at first glance.

This is definitely the cleanest/easiest method I’ve seen on this forum or Roots docs. Your rock! :facepunch::pray:

Hey all,

I’ve ended up using more than one or two commercial plugins that don’t have accessible/stable download links, so ended up with the following.

  1. Create a new private repo (commercial-plugins-example for this example)
  2. Add each plugin folder to the repo, 1 commit for each plugin
  3. Add that private repo to composer.json (as per docs)

WordPress won’t recognise any plugins that are not in the root of the /plugins folder. You could maintain a loader in the commercial plugins repo, but I experimented with little bit of composer magic instead.

  1. Add the following scripts to composer.json, after require
  "scripts": {
    "post-install-cmd": [
      "./scripts/copy_commercial_plugins"
    ],
    "post-update-cmd": [
      "./scripts/copy_commercial_plugins"
    ]
  },

The scripts/copy_commercial_plugins file will look something like this (make your own changes as required):

# Copy all commercial plugins into plugins folder
rsync -av web/app/plugins/commercial-plugins-example/* web/app/plugins/ --exclude composer.json

You could move instead of copy to ensure the commercial plugin repo is removed, but I’m okay leaving it where it is (it’s in a handy spot for local updates).

When a plugin requires an update:

  1. Download the update directly from developer, or update the plugin via /wp-admin
  2. Copy updated plugin folder into commercial plugins repo, commit with version in message
  3. Push new commit to remote
  4. Run composer update

Pros:

  • A little more robust – won’t break build/deploy steps if a download link becomes invalid or expires for whatever reason
  • Learn a bit about composer! Running scripts on update/install is super powerful :slight_smile:

Cons:

  • Keeping the commercial plugin repo up-to-date is a bit of a chore, especially with plugins that are updated frequently
  • Haven’t had to rollback a plugin yet, but that could be a little messy

Would love any feedback on this!

3 Likes

Since I often have several sites using a paid plugin like gravity forms, I create a git repo with the source of the plugin and a composer.json file, so that I can add it as a source control repository and it is easy for me to update many sites at once. I just update my gravityforms repository, then composer update each site.

"gravityforms": {
  "type": "vcs",
  "url": "https://github.com/fahrenheit-marketing/gravityforms"
}

Some of those plugins are GPL like gravityforms, so I just put it on a public github repo. Sometimes it is a custom proprietary plugin that I use on multiple sites, in which case I use a private repo.

3 Likes

Be sure to change any s3.amazonaws.com links to HTTPS.

I follow jwilliams approach. If there’s a better way, I’m all for it. But I’ve gotten used to this. I create a private repo on bitbucket usually. In my main project, I’ll add a line like this for each private repo used in that project.

"repositories": [{
     "type": "git",
      "url": "git@bitbucket.org:myusername/gravityforms.git"
   },{

The plugin requires a composer.json file like this:

 {
"name": "myusername/gravityforms",
"type": "wordpress-plugin",
    "repositories": [{
    	"type": "vcs",
        "url": "git@bitbucket.org:myusername/gravityforms.git"
    	}]
   }

When I checkin the plugin to it’s private repo, I attach a tag that is the version number of the plugin update. Everytime there is a plugin update, I unzip the file on top of the package, check it in, and add a tag for that version. That allows me to install any version of the private paid plugin that I want.

"myusername/gravityforms": "1.9.19",

Gravity Forms’ support just directed me to this post showing how to install w/ WP-CLI.

If you’re using Trellis, you can drop these simple tasks somewhere in your playbook:

- name: install gravityforms cli & activate
  become: True
  become_user: web
  shell: wp plugin install gravityformscli --activate chdir=/srv/www/<site_name>/current/web/

- name: install gravityforms & activate
  become: True
  become_user: web
  shell: wp gf install --key=xxxxxx --activate chdir=/srv/www/<site_name>/current/web/
5 Likes

What are you using here for Username and Password? I’m not having much joy.

I’ve tweaked how to install GravityForms - just sharing for reference.

Using the deploy_build_after hook (see here for reference), I added the following after the Install Composer dependencies command:

- name: Activate Gravityformscli
  command: wp plugin install gravityformscli --activate
  args:
    chdir: "{{ deploy_helper.new_release_path }}"
  register: gravityformscli_installed

- name: Install Gravity Forms with WP CLI
  command: wp gf install --key=xxxxx --activate
  args:
      chdir: "{{ deploy_helper.new_release_path }}"
  when: gravityformscli_installed | success
  register: gravityforms_installed

- name: Verify Gravity Forms checksums
  command: wp gf tool verify-checksums
  args:
      chdir: "{{ deploy_helper.new_release_path }}"
  when: gravityforms_installed | success

Works like a charm!

Edit: tweaked to also install the plugin - note that this will not work on an initial remote deploy, as by default the WP site hasn’t been configured so WP-CLI cannot perform any plugin actions.

12 Likes

Did you find out what username and password to use? I am also having trouble with that part, using the https://s3.amazonaws.com option.

Thanks for sharing @runofthemill, this has been helpful. I would assume if you put in a default database for Trellis to fire up on initial provisioning and deployment this would be resolved.

Presumably that’d work, since the db import happens during the wordpress_setup role, but I haven’t tried so I can’t confirm :stuck_out_tongue:

The URL with the downloads changed. This is the new URL:
https://www.gravityforms.com/my-account/downloads/ (login required)

For anyone looking into this, using https://s3.amazonaws.com URLs does not work very well since the expiredate and signature parameters are reset very often.

Thankfully, Gravity Forms provides an API to get a fresh URL - they use it themselves in the CLI addon for installing the package.

I created a composer install helper that works similarly to “private-composer-installer”, but is more specific to Gravity Forms since it needs to do an API call to retrieve the correct URL.

Here it is: https://github.com/gtap-dev/gravityforms-composer-installer

3 Likes

Cool thanks! Does it also work for installing add-ons?
I was trying something like this as url:
http://www.gravityhelp.com/wp-content/plugins/gravitymanager/api.php?op=get_addon&slug=activecampaign&key={%WP_PLUGIN_GF_KEY}

but that doesn’t work unfortunately…

EDIT:
This url does seem to display some valid information with a valid download_url:
http://www.gravityhelp.com/wp-content/plugins/gravitymanager/api.php?op=get_plugin&slug=gravityformsactivecampaign&key={%WP_PLUGIN_GF_KEY}
but it’s not downloading anything