Migração

Como migrar um plugin do WordPress de uma API de geocodificação paga

Plugins do WordPress que chamam uma API de geocodificação, como um localizador de lojas, um verificador de área de entrega ou um mapa de anúncios de imóveis, costumam ser construídos com a chave de um provedor específico, inserida uma vez em uma página de configurações e usada em todos os pontos em que o plugin precisa consultar um local. Esse único campo de configuração é prático para os donos de sites, mas também significa que o provedor de geocodificação muitas vezes está mais entranhado no código do plugin do que uma olhada rápida na página de configurações sugere.

A primeira coisa a definir é se você está migrando um plugin que você mesmo mantém ou um plugin de terceiros que você apenas configura. São situações realmente diferentes:

Se você mantém o plugin, a migração é uma alteração de código normal: encontre todas as funções que chamam a API de geocodificação (buscar no código do plugin o nome do host do provedor ou o nome específico do parâmetro de chave costuma ser a forma mais rápida de localizar todos os pontos de chamada) e atualize essas funções para chamar o novo host com uma nova chave. Como PHP é a linguagem natural aqui e os hosts de compatibilidade do My Geocode reproduzem o formato de resposta exato de um provedor conhecido, se o código atual do plugin já interpreta o formato específico desse provedor, atualizar apenas o host da requisição e a autenticação, e não a lógica de parsing da resposta, muitas vezes é suficiente. A autenticação aceita um cabeçalho X-API-Key, Authorization: Bearer, HTTP Basic auth ou um parâmetro de query, então qualquer que seja a forma que o plugin usa hoje para enviar a chave, há um equivalente direto.

Se você apenas configura um plugin de terceiros, suas opções dependem totalmente do que a página de configurações do plugin oferece. Alguns plugins permitem configurar um endpoint de API personalizado junto com a chave e, nesse caso, apontar essa configuração para um host de compatibilidade correspondente, se existir um para o provedor para o qual o plugin foi originalmente feito, pode funcionar sem nenhuma alteração de código, já que, do ponto de vista do plugin, ele continua falando com uma API do mesmo formato. Outros plugins deixam o nome do host do provedor totalmente fixo no código e, nesse caso, suas opções se limitam a entrar em contato com o desenvolvedor do plugin, procurar um fork ou uma atualização que traga mais flexibilidade ou, para uma dependência crítica, considerar uma pequena modificação própria, se a licença do plugin permitir.

Algumas observações práticas para os dois cenários:

  • Teste qualquer alteração primeiro em uma cópia de homologação do site, nunca diretamente em uma instalação do WordPress em produção, já que o código de um plugin interagindo com um banco de dados em produção traz mais risco do que uma alteração de código isolada traria em outro lugar
  • Verifique se o plugin armazena resultados de geocodificação em cache em uma tabela própria do banco de dados, já que uma troca de provedor pode exigir que esse cache seja limpo ou revalidado separadamente da alteração de código em si
  • Confirme que o tratamento de erros do plugin lida bem com um formato de resposta inesperado, já que um site WordPress mostrando um erro bruto de PHP a um visitante por causa de uma resposta de API incompatível é um resultado pior do que o recurso de geocodificação simplesmente não aparecer por um momento

Para o site de uma pequena empresa que depende de um único plugin para um localizador de lojas ou um recurso parecido, a cota diária gratuita, 2.500 requisições sem nenhuma chave ou 2.500 por conta por dia, compartilhadas por todas as suas chaves, muitas vezes cobre com folga o tráfego que um site pequeno típico gera, e vale conferir isso com o volume real de visitantes e de consultas do seu site antes de presumir que um plano pago seja necessário.