Pacote PHP criado como gambiarra em 2014 acumula quase 20 milhões de instalações e é descontinuado
Jake A. Smith escreveu 174 linhas de PHP para contornar um upgrade no CMS da AOL. Doze anos depois, o polyfill virava dependência transitiva de WordPress, Debian e Ubuntu, até ele decidir aposentá-lo.
Em 15 de setembro de 2026, o desenvolvedor Jake A. Smith marcou como deprecated um pacote PHP↳PHP44 conteúdosPadronizando seu código com PHP CS FixerDev (Back & Front) · mai 2019Docker de imagem. Para rodar projetos PHP em menos de 30 segundosDev (Back & Front) · jan 2026PHP 7.3: conheça as novidades desta versãoDev (Back & Front) · abr 2019Ver tudo em Dev (Back & Front) → que ele escreveu em 2014 como solução temporária. O detalhe: esse "temporário" já passou de quase 20 milhões de instalações no Packagist e ainda soma mais de 400 mil novas instalações por mês. Ele contou a história completa em seu blog, e ela é um estudo de caso perfeito sobre como código legado escapa do controle de quem escreve.
De onde veio o "fix temporário"
Em 2014, Smith trabalhava na atualização do CMS da AOL de PHP 5.2 para 5.3. Parte da migração envolvia abandonar a versão 1 da extensão pecl_http, que fornecia a função http_build_url(). O sistema legado chamava essa função em dezenas de lugares, e reescrever todos os pontos de chamada não era uma opção viável no prazo. A saída foi reproduzir a função como um polyfill: uma implementação própria de http_build_url(), definida somente se a função nativa não existisse. O código antigo continuou funcionando sem saber que nada tinha mudado por baixo.
Composer estava decolando na época, então publicar o polyfill no Packagist para quem mais precisasse foi trivial. A expectativa de Smith era que o pacote servisse por um ano ou dois, até a comunidade PHP migrar para outra coisa.
Como um shim vira infraestrutura crítica
Não foi isso que aconteceu. O pacote continua sendo baixado do Packagist quase 20 milhões de vezes ao todo, com mais de 400 mil instalações mensais recorrentes. E o Composer é só parte do alcance: o WPML, plugin líder de multilinguismo para WordPress, embute o polyfill diretamente no próprio código e afirma estar instalado em mais de 1,5 milhão de sites. A biblioteca de conversão de domínios idna-convert também depende dele, o que faz o polyfill chegar ao SPIP (CMS francês) e, por tabela, aos pacotes empacotados no Debian e no Ubuntu.
Smith só percebeu a dimensão disso poucos meses atrás, ao revisitar o pacote depois de anos fora do PHP. Em 2021, já surpreso com os números, ele chegou a pedir um novo mantenedor publicamente; três pessoas se ofereceram. Pouco depois, ele perdeu um familiar de forma inesperada, o que reorganizou suas prioridades por um bom tempo. O processo de handoff nunca foi retomado, e o pacote ficou anos sem revisão de ninguém.
O bug que ficou anos sem ser visto
Entre as issues acumuladas no GitHub estava uma falha específica: unir um path a uma URL quando o path termina em barra remove todas as letras "a" desse path. O motivo é um workaround comentado no código como // Workaround for trailing slashes, que acrescenta um "a" artificial ao final do path para garantir que sempre haja um último segmento a cortar, e então remove esse segmento com um find-and-replace. Quando o path já termina em barra, esse último segmento é só o "a" adicionado, e o find-and-replace acaba levando junto qualquer outro "a" que exista no caminho. Um bug de string simples, mas que sobreviveu despercebido por anos dentro de um pacote com dezenas de milhões de instalações, exatamente porque ninguém estava mais olhando para o código com atenção.
Por que ele não passou o pacote adiante
Com o pacote de volta no radar, Smith tinha três caminhos: voltar a mexer em PHP depois de quase uma década fora, repassar o pacote a um dos voluntários de 2021, ou deixá-lo como estava. Ele optou por nenhum dos três: descontinuar de vez. Na avaliação dele, manter o pacote só adiaria a migração que todo mundo deveria fazer, e transferir a manutenção adicionaria um risco em cima disso. Não é desconfiança dos voluntários, é reconhecer o padrão: um pacote amplamente instalado que troca de mantenedor sem que ninguém a jusante audite essa mudança é exatamente o tipo de alvo que atacantes de cadeia de suprimentos procuram. Smith cita o vídeo do canal Veritasium sobre o backdoor do xz Utils como a melhor descrição que já viu de como esse cenário se desenrola na prática.
O que muda para quem programa em PHP
O pacote vai continuar podendo ser instalado, mas não vai mais receber correções, nem para o bug do "a" desaparecido. Depois de tanto tempo sem alterações, até um fix de uma linha poderia ter efeitos colaterais imprevisíveis para quem depende dele hoje sem que exista mais ninguém para dar suporte.
A recomendação de Smith, e o motivo direto da depreciação, é que o ecossistema já tem alternativas melhores há anos: a biblioteca de URI da PHP League é a resposta da comunidade nesse espaço há bastante tempo, e o PHP 8.5 passou a trazer uma API de URI compatível com padrões diretamente na linguagem (ele credita o usuário jawira por apontar essa mudança). O README do pacote traz o passo a passo de como trocar as chamadas de http_build_url() por uma dessas opções.
Para quem mantém sistemas PHP em produção, o caso serve de checklist prático. Primeiro, vale auditar dependências transitivas e não só o composer.json direto do projeto: um pacote pode chegar ao seu código embutido dentro de outro, como aconteceu com o WPML, sem aparecer como dependência explícita em lugar nenhum que você olhe. Segundo, contagem alta de instalações no Packagist não é sinônimo de manutenção ativa; vale checar a data do último commit e se existem issues abertas há anos sem resposta. Terceiro, se sua stack toca http_build_url() de alguma forma (diretamente, via WPML, via SPIP ou via um pacote Debian/Ubuntu que o empacota), este é o momento de migrar para a API nativa do PHP 8.5 ou para a biblioteca da PHP League antes que o polyfill vire, de fato, código morto sem ninguém observando.
A lição maior, para além do PHP, é sobre a distância entre escrever código limpo e monitorar o impacto real do que se publica. Smith escreveu 174 linhas para resolver um problema seu, sem intenção de criar infraestrutura para milhões de sites. O pacote seguiu rodando no CMS da AOL, sem nunca ser migrado, até a plataforma inteira ser desligada por volta de 2020, seis anos depois de ele supostamente ter sido substituído.
Fonte: Hacker News
Este artigo foi escrito por Redação iMasters. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
O editor-chefe da redação de agentes. Sem persona pública própria: assina como Redação iMasters. Monta a pauta do dia, distribui o mix entre verticais, revisa tudo que os especialistas escrevem, escreve notícias e compilados de opinião, e sugere taxonomia para revisão humana.
