O que acontece quando dois plugins têm a mesma classe de terceiros incluída neles?

4

Estou criando um plug-in que usa o Stripe para o processamento de pagamentos. Eu incluí a biblioteca PHP do Stripe no meu plugin e tudo funciona muito bem. Mas e se alguém mais fizer um plugin que também use Stripe ... ou pior, uma versão mais antiga do Stripe que não seja compatível com a minha? Parece que pode haver conflitos se alguém tiver nossos dois plug-ins ativados ao mesmo tempo.

Eu preciso nomear classes de Stripe? Isso é aconselhável? Eu imagino que seja um pesadelo de manutenção se eu quiser atualizar para uma versão mais nova da biblioteca do Stripe.

Estou totalmente bem ao fazer isso, mas quero ter certeza de que estou seguindo as práticas recomendadas aqui.

Obrigado! Tony

    
por Tony DeStefano 25.02.2016 / 00:15

2 respostas

2

Eu fui em frente e nomeei Stripe. Tudo funcionou muito bem. E agora eu não tenho que me preocupar com a biblioteca Stripe de qualquer outra pessoa bagunçando minhas coisas.

Original:

namespace Stripe;

Novo:

namespace MyRadNamespace\Stripe;

Se alguém estiver interessado em ver como é feito, sinta-se à vontade para navegar pelo meu repositório:

enlace

Felicidades!

    
por Tony DeStefano 26.02.2016 / 23:57
0

Quando analisei o link para o repositório anexado na resposta, notei a incrível quantidade de requice declarações em um único arquivo. O problema principal é que o repositório não possui um autoloader que pode ser otimizado para todo o projeto e que o plug-in inclui todos esses arquivos, independentemente de serem necessários ou não.

Quando você começar a usar o Composer para gerenciar anexos, descobrirá que ele cria um arquivo autoload.php para cada pacote que você escreve (ou busca). Você pode criar projetos completos usando o Composer como gerenciador de pacotes, que, como um bom efeito colateral, também cria um arquivo centralizado autoload.php em vez de um autoloader por pacote incluído ( plugin / theme / etc). Além deste autoloader único, o Composer também constrói um mapa "Class > File" como "cache" para evitar o máximo de leituras possíveis, o que manterá as pesquisas de classe o mais rápido possível.

Isso evitará o namespace de classes de namespace de fornecedor. O que significa que, caso vários pacotes tenham um arquivo composer.json , haverá apenas um local onde esses pacotes de fornecedores serão ser salvo (portanto, economizando largura de banda e espaço em disco) e obtido de. Mesmo se não ignorar os arquivos de fornecedores em um pacote controlado por VCS, não há necessidade de carregá-los.

# Before in Package (A)
$stripe = new \MyRadNamespace\Stripe;
# Before in Package (B)
$stripe = new \MyFunkyNamespace\Stripe;

# After – anywhere!
$stripe = new \Stripe;

No caso de um plugin ou tema não suportar ainda o Composer, você pode simplesmente buscá-lo através do serviço proxy / espelho WPackagist .

Para começar rapidamente com o gerenciador de pacotes do Composer, sugiro usar wecodemore / wpstarter por @gmazzap - docs aqui .

    
por kaiser 06.03.2016 / 13:04