Evitando colisões de nomes de plugins com o WP updater

4

Eu tenho um cliente que tem um site WordPress que usa um plug-in personalizado escrito para eles por outro desenvolvedor. Recentemente, eles executaram o atualizador do WordPress e uma das atualizações destruiu esse plugin personalizado e o substituiu por um plug-in do Repositório de Plug-ins que tinha o mesmo nome.

Estou tentando descobrir exatamente o que precisa mudar para evitar que isso aconteça novamente no futuro. O plugin em questão não tinha nenhum identificador particularmente exclusivo nos nomes dos diretórios / arquivos principais; imagine que é assim:

foo/foo.php

Então, se já existe um plugin "Foo" no repositório, é compreensível porque o WP iria confundir os dois.

Meu entendimento no passado foi que a maneira de evitar isso era colocar um identificador único nesses nomes, como:

client-foo/client-foo.php

Adicionando o bit "client-", pensei, foi o caminho para reduzir as chances de uma colisão, tornando o plugin específico para o site WordPress que o estava executando.

No entanto, mesmo depois de renomear os arquivos, descobri que o atualizador ainda estava confundindo o plugin com o plugin "foo" no repositório.

Em seguida, tentei alterar o campo "Nome" no cabeçalho de metadados do plug-in, em

Plugin Name: Foo

para

Plugin Name: Foo (Client)

E isso pareceu remover a colisão; o atualizador não sinalizou mais como compatível com o plug-in público.

Então agora estou confuso. É realmente o caso que a única coisa que o atualizador verifica para evitar colisões é o campo de metadados Nome do Plugin? Isso parece realmente frágil em comparação com a maneira que eu pensei que estava fazendo (comparando nomes de arquivos), pelo menos para mim.

De qualquer forma, não consegui encontrar uma palavra definitiva sobre as informações que o atualizador usa para fazer essa verificação e, embora eu tenha encontrado

    
por jalefkowit 13.11.2014 / 20:41

2 respostas

1

A maneira como o WordPress usa para encontrar um plugin no repositório não é pública AFAIK.

De acordo com a resposta da Otto em questão, você vinculou o cabeçalho do URL do plugin ao nome do plugin.

BTW, remova o plug-in da lista do plug-in para atualizar é a melhor maneira de garantir que esse problema não aconteça novamente: uma vez que o método correspondente não é público, não é possível saber se ele será alterado no futuro .

    
por gmazzap 15.11.2014 / 21:09
3

Como a lógica usada para atualizações de repositórios oficiais é fuzzy e os detalhes exatos são mantidos em segredo - não é possível evitá-los de maneira confiável simplesmente manipulando detalhes.

A única prática confiável no momento é filtrar os dados do conjunto enviado para verificação de atualização. Mesmo isso é altamente inconveniente e precisa ser executado no nível de solicitação da API HTTP. Um dos desafios relacionados é que, se o plug-in excluir o próprio , ele não poderá fazê-lo quando inativo e ainda correr o risco de ser destruído pela atualização nesse caso.

Pessoalmente, escrevi um pequeno ajudante Update Blocker para isso. Em sites mais sérios, eu recomendaria matar completamente as atualizações e gerenciar o site com o Composer.

Enquanto o projeto WP geralmente concorda que este é um problema agora (que levou literalmente anos ) o ticket propondo o sinalizador de desativação do cabeçalho está parado há algum tempo, exigindo atualizações no site do WordPress. Veja o ticket # 32101 no trac .

    
por Rarst 14.04.2016 / 21:16