Skip to main content

Set Up a Private Package

For any dependency that's not available on WPackagist or Packagist (e.g. a premium plugin), we have to manage it ourselves.

This means creating and maintaining a private repo in the stellarwp GitHub organization, per the following steps.

Creating a Private Package Repo​

Get the production version of the dependency​

We're usually talking about a premium plugin here, so this would mean getting the production version of the plugin—a .zip, usually.

Create a private repo in stellarwp's GitHub​

If you're unable to, submit a ticket.

Name the repo composer-{package name}​

The plugin advanced-custom-fields-pro, for example, would be:

stellarwp/composer-advanced-custom-fields-pro.

Add the production files to the repo​

The repo should have one branch—main—and it should contain the unzipped contents of the production .zip.

Add a bare-bones composer.json​

If there is already a composer.json in the unzipped files, delete it! Likewise with a composer.lock if one is there.

Then add a new composer.json with only a few key lines in it:

{
    "name": "stellarwp/{package name}",
    "type": "wordpress-plugin",
    "version": "{version}"
}

Notice that the package name does not include the composer- prefix seen in the repo name. To stick with the example of Advanced Custom Fields PRO:

  • Plugin name: Advanced Custom Fields PRO
  • Plugin slug: advanced-custom-fields-pro
  • Repo name: stellarwp/composer-advanced-custom-fields-pro
  • Package name: stellarwp/advanced-custom-fields-pro

Valid types include:wordpress-plugin, wordpress-muplugin, and wordpress-theme.

Tag the package version​

If the plugin version is 6.2.7, ensure that this is set for the composer.json's version value.

Then, tag the main branch at this moment in time, naming the tag just 6.2.7.

This ensures you can specify that version when using this package in other projects.

A Real-World Example​

Let's look at the private package repo for StellarWP's very own Kadence Blocks Pro plugin, a premium plugin not available from e.g. WPackagist.

Development for that plugin happens at this stellarwp repo:

stellarwp/kadence-blocks-pro

So, couldn't we just use this? Maybe, but it would be far from ideal as this repo is meant for active development by the Kadence dev team.

As such, version-number tagging on the repo is not consistent. This repo is not meant for public consumption, so even if things were tagged, it could mean we'd risk pulling in untested code, or code that is not optimized for production environments.

To save us from those issues and more, we simply "mirror" the production version of the plugin at a private package repo here:

stellarwp/composer-kadence-blocks-pro

Further Reading​