Usar o MeteorGPL em um projeto Bedrock

O Bedrock gerencia um site WordPress inteiro com o Composer: o próprio WordPress é uma dependência, os plugins do WordPress.org vêm de um espelho Composer do diretório de plugins, e o composer/installers envia cada pacote para web/app/plugins ou web/app/themes. Os plugins premium são a lacuna de sempre: acabam commitados no repositório ou enviados à mão. O MeteorGPL fecha essa lacuna com mais um repositório.

Passo 1 — Guarde o seu token#

Se você ainda não fez isso nesta máquina, crie um token em Configurações → Tokens do Composer e entregue-o ao Composer:

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

O nome de usuário é literalmente a palavra token. Para um projeto de equipe, use um token da organização (ele continua funcionando quando pessoas saem); para servidores e CI, leia Tokens do Composer no CI.

Passo 2 — Adicione o repositório#

O composer.json do Bedrock já tem uma lista repositories. Adicione o MeteorGPL a ela:

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

Mantenha as entradas que vêm com o Bedrock; a nova fica ao lado delas.

Passo 3 — Confira os caminhos do instalador (nada a mudar)#

O Bedrock tem o composer/installers como dependência e mapeia os tipos de pacote do WordPress para as suas próprias pastas:

"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"
}

O MeteorGPL publica plugins como wordpress-plugin e temas como wordpress-theme, então eles seguem essas regras sem nenhuma configuração extra.

Passo 4 — Faça o require dos seus plugins e temas premium#

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

O plugin vai para web/app/plugins/elementor-pro/, o tema para web/app/themes/rehub-theme/. Os nomes de pacote são sempre meteorgpl-plugin/<slug> para plugins e meteorgpl-theme/<slug> para temas, em que o slug é o nome da pasta que o fornecedor distribui; cada página de pacote mostra o comando exato.

Faça commit do composer.json e do composer.lock, não do código instalado. O arquivo lock registra cada versão e o checksum do zip dela, então todo ambiente instala os mesmos arquivos.

Passo 5 — Ative e adicione as suas chaves de licença#

Ative o plugin no painel do WordPress, ou com o WP-CLI:

wp plugin activate elementor-pro

Os pacotes não são modificados: as verificações de licença do fornecedor estão intactas, então ative o plugin com a chave que você comprou do fornecedor. O cofre de chaves de licença (Configurações → Chaves de licença) guarda suas chaves criptografadas e lembra você antes que elas expirem.

Passo 6 — Faça o deploy#

No servidor, ou no pipeline que gera a release, o Composer também precisa do token. Ou você o guarda uma vez para o usuário de deploy:

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

ou o passa na variável de ambiente COMPOSER_AUTH e, em seguida, instala exatamente o que o arquivo lock diz:

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

Use um token separado para cada servidor ou pipeline, restrito aos pacotes de que o site precisa: se um vazar, você revoga esse e nada mais para de funcionar.

Atualização#

composer update meteorgpl-plugin/elementor-pro

leva o plugin para a versão mais nova que a sua restrição permite e atualiza o composer.lock. Teste, faça commit, faça o deploy. Toda versão publicada continua disponível, então um rollback é um composer require com o número da versão anterior. Para ficar sabendo de novas versões e avisos de segurança, leia Manter plugins atualizados e acompanhar vulnerabilidades.