Tracking Private WordPress Plugins – Your Digital Toolbox

It’s probably the 5th or 6th time I have rewritten the solution to tracking private wordpress plugins. I have never been absolutely happy with the result, but I am finally pleased with the result. Let me show you what I figured out.

But First, Let me explain the problem: Just want the solution? TLDR;

I Use Trellis To Deploy Bedrock WordPress Sites.

If you are an agency or business looking to take control of your wordpress deployments and have not heard of Trellis, check it out. Roots Trellis. They have done an excellent job making the Development / Deployment process as enjoyable as possible. Under the hood trellis is a set of Ansible playbooks that can install all of the software required to run a website properly. One of the most important improvements to the traditional wordpress process is using Roots Bedrock. Bedrock is WordPress boilerplate with Composer.

This shift allows us to use Composer to manage wordpress as a composer package and wordpress themes and plugins, too!

What is Composer? Well Composer is a package manager for PHP. That simply means that we can specify all the versions of different packages we want to be installed in a composer.json file, and Composer will handle putting the packages in the right place for us.

So, just like any composer project we list out all of the packages <read wordpress core, themes, plugins, etc> in our composer.json file and allow Composer to install those to the right locations in our wordpress app. When we want to update we can easily run:

				
					composer update

Composer will check for any updates that are available and then create a composer.lock file that can be used to install all of the same files for Development, Testing, Staging, and Production Pairity.

All of that sounds AWESOME! Where's the problem?

Paid Plugins are the problem.

When looking for free plugins, we can simply use WordPress Packagist: The site mirrors the WordPress plugin and theme directories as a Composer repository. This allows us to use any public package super easily.

Enter SatisPress: It Facilitates modern best practices for managing WordPress websites by automating Composer support for private plugins and themes. This works wonderfully, But there’s one drawback. I am tracking around 150 paid plugins I have purchased or need for various sites I manage. Keeping all of those in a single dedicated Satispress Website is incredibly SLOW.

I hear you: Why not just have more than one SatisPress site?

Well, That’s fine, but for every SatisPress site you have, we need to tell Composer where to look for plugin packages & updates. We also need to manage all the credentials to connect to SatisPress for each site on every website we develop. If credentials ever need to change, then that represents a significant amount of work to update it everywhere.

composer.json

							
					{
    "name": "roots/bedrock",
  ... Other Info  ...
    "repositories": [
        {
            "type": "composer",
            "url": "https://wpackagist.org",
            "only": [
                "wpackagist-plugin/*",
                "wpackagist-theme/*"
            ]
        },
        {
            "type": "composer",
            "url": "https://AA.satispress-example.com/"
        },
        {
            "type": "composer",
            "url": "https://BB.satispress-example.com/"
        }
        {
            "type": "composer",
            "url": "https://CC.satispress-example.com/"
        }
    ],
    ... More Info ...
}
				
			
		

Here's My Solution: Multiple SatisPress Installs
Mirror Everything in a GitHub Org.

Multiple SatisPress installs can handle any number of plugins without getting too slow.
Plugins are unzipped, and the code is tracked in individual Private GitHub Repos.
Plugin Versions are tracked via GitHub Tags.
A single org-wide Composer packages.json file is automatically generated when any plugin has a new version.
A single set of GitHub credentials (oauth2/token) is required to access the private packages.
Actions happen automatically via GitHub Actions / Workflows.

Unfortunately, you won’t be able to view all the plugins stored in the org, as they are all private. However, you can examine how the org works and access the workflows that tick everything. You could even clone it and follow the instructions to set it up for your organization.

You can view all of the plugins and versions that I am tracking here: packages.json

I Use Trellis To Deploy Bedrock WordPress Sites.

All of that sounds AWESOME! Where's the problem?

I hear you: Why not just have more than one SatisPress site?

Here's My Solution: Multiple SatisPress Installs Mirror Everything in a GitHub Org.

Did you have the same problem? Let us know how you solved it in the comments below!

Related Articles

Here's My Solution: Multiple SatisPress Installs
Mirror Everything in a GitHub Org.

Did you have the same problem?
Let us know how you solved it in the comments below!