Use MeteorGPL in a Bedrock project

Bedrock manages a whole WordPress site with Composer: WordPress itself is a dependency, plugins from WordPress.org come from a Composer mirror of the plugin directory, and composer/installers sends every package to web/app/plugins or web/app/themes. Premium plugins are the usual gap: they get committed to the repository or uploaded by hand. MeteorGPL closes that gap with one more repository.

Step 1 — Store your token#

If you have not done it on this machine yet, create a token under Settings → Composer tokens and give it to Composer:

composer config --global http-basic.composer.meteorgpl.ddev.site token <your-token>

The user name is the literal word token. For a team project, use an organisation token (it keeps working when people leave); for servers and CI, read Composer tokens in CI.

Step 2 — Add the repository#

Bedrock's composer.json already has a repositories list. Add MeteorGPL to it:

"repositories": [
    {
        "type": "composer",
        "url": "https://composer.meteorgpl.ddev.site"
    }
]

Keep the entries Bedrock ships with; the new one goes next to them.

Step 3 — Check the installer paths (nothing to change)#

Bedrock requires composer/installers and maps the WordPress package types to its own folders:

"extra": {
    "installer-paths": {
        "web/app/mu-plugins/{$name}/": ["type:wordpress-muplugin"],
        "web/app/plugins/{$name}/": ["type:wordpress-plugin"],
        "web/app/themes/{$name}/": ["type:wordpress-theme"]
    },
    "wordpress-install-dir": "web/wp"
}

MeteorGPL publishes plugins as wordpress-plugin and themes as wordpress-theme, so they follow these rules with no extra configuration.

Step 4 — Require your premium plugins and themes#

composer require meteorgpl-plugin/elementor-pro:^3.21 meteorgpl-theme/rehub-theme:^19.0

The plugin lands in web/app/plugins/elementor-pro/, the theme in web/app/themes/rehub-theme/. Package names are always meteorgpl-plugin/<slug> for plugins and meteorgpl-theme/<slug> for themes, where the slug is the folder name the vendor ships; each package page shows the exact command.

Commit composer.json and composer.lock, not the installed code. The lock file records each version and the checksum of its zip, so every environment installs the same files.

Step 5 — Activate and add your license keys#

Activate the plugin in the WordPress admin, or with WP-CLI:

wp plugin activate elementor-pro

Packages are not modified: the vendor's license checks are intact, so activate the plugin with the key you bought from the vendor. The license key vault (Settings → License keys) keeps your keys encrypted and reminds you before they expire.

Step 6 — Deploy#

On the server, or in the pipeline that builds the release, Composer needs the token too. Either store it once for the deploy user:

composer config --global http-basic.composer.meteorgpl.ddev.site token <deploy-token>

or pass it in the COMPOSER_AUTH environment variable, then install exactly what the lock file says:

composer install --no-dev --prefer-dist --no-interaction

Use a separate token for each server or pipeline, limited to the packages the site needs: if one leaks, you revoke that one and nothing else stops working.

Updating#

composer update meteorgpl-plugin/elementor-pro

moves the plugin to the newest version your constraint allows and updates composer.lock. Test, commit, deploy. Every published version stays available, so a rollback is composer require with the previous version number. To hear about new versions and security notices, read Keep plugins up to date and watch for vulnerabilities.