Best Practice: Adding Gravity Forms (and other plugins)

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

I ended up using this installer instead: https://github.com/junaidbhura/composer-wp-pro-plugins
which also supports installing Gravity Forms Add-ons!

https://packagist.org/packages/gotoandplay/gravityforms-composer-installer

1 Like

Folks, I’ve been experimenting with satispress https://github.com/cedaro/satispress
It turns an ordinary WordPress installation into a composer repository specifically for plugins and themes.
Nicely protected so you need an auth.json file for credentials. But is working great for me.
I manage my satispress installation in wpmanage as an ordinary WordPress site. So I use that to update almost 50 premium plugins and themes used in various projects.
It does mean using a site license for many of them so they’ll update, but if you don’t need the license for actually running the plugin in a project (or you have multi site licenses), then that’s fine.
Recommended.

3 Likes

This looks really useful, thanks…

@mikelittle I’m looking at setting this up right now. So it seems like for this to work the plugins have to be updated via the WordPress plugin update process? How are you handling authentication for things like CI/CD?

Yes. You can use whatever normal means to update the plugins. I happen to use ManageWP to remotely update a ton of sites I host. So the Satispress site is just part of the routine. But I am really considering just running a shell script to just update them every few hours.

Then the projects that use the commercial plugins can pull them in as and when I update them via composer update

As for authentication, I have set up a different account on the SatisPress site for each project. Then for each account I have generated different API keys (e.g. one for production, one for my local development, one for a remote designer, etc) Those credentials go into auth.json in each checked out copy of the project. The auth.json is git-ignored so the credentials don’t go in the repo. You can also add authentication to you CI/CD stack too. I’m not currently using this on any project with CI/CD set up.
Splitting the auth this way means I can for example revoke the api key from the remote designer when she stops working on the project.

Hope that helps.

Stay safe and healthy

Mike

This is still the best GF installation method for me, but an error has occurred on multiple websites lately, something like:
gf is not a recognised command

I solved this by using the deploy_finalize_after hooks instead, e.g.:

deploy_finalize_after:
  - "{{ playbook_dir }}/roles/deploy/hooks/finalize-after.yml"
  - "{{ playbook_dir }}/deploy-hooks/sites/{{ site }}-finalize-after.yml"

Create the file deploy-hooks/sites/mysite.com-finalize-after.yml and add the same hooks provided by runofthemill

This method works great!
I was just wondering how you guys handle the installations in your development environment, since you don’t have any deployments there?