Skip to content

Tudo para WordPress, desenvolvimento web — e não só

🧪 Testar código PHP em versões antigas sem instalação: guia 2026

🧪 Testar código PHP em versões antigas sem instalação: guia 2026

Escreveu código PHP funcional na versão mais recente, enviou para produção e recebeu uma enxurrada de relatórios de bugs de clientes com alojamentos antigos. Parece-lhe familiar? Uma sintaxe que lhe parece «óbvia» transforma-se num erro fatal no PHP 7.0. Instalar uma dúzia de versões desatualizadas localmente para verificar cada trecho de código é uma tarefa de meio dia, quando não é impossível.

O problema é mais profundo do que parece. As versões antigas do PHP desaparecem dos repositórios oficiais, não compilam em kernels Linux modernos e entram em conflito com extensões. O WordPress ainda funciona em servidores onde o fornecedor de alojamento não se preocupou em atualizar o PHP. Como resultado, o seu plugin ou tema quebra para centenas de utilizadores simplesmente porque usou um argumento tipado string ou a sintaxe curta de array.

Mas existe uma ferramenta que resolve este problema em segundos: o 3v4l.org, um testador de código PHP online e gratuito em mais de 300 versões em simultâneo. Sem instalação, sem máquinas virtuais. Neste guia, vou mostrar-lhe como detetar incompatibilidades antes do lançamento e demonstrar erros do mundo real que nós próprios enviámos para produção.

💡 Visão geral rápida:

  • Cole um trecho de código PHP no 3v4l.org e execute-o em todas as versões, desde o PHP 4.3.0 até ao mais recente 8.5
  • Reveja o resultado agrupado: o site mostra onde o código funciona, onde gera erros e onde o comportamento difere
  • Estude dois exemplos clássicos de incompatibilidade que quebram plugins do WordPress em alojamentos antigos, com código e links para testes ao vivo
  • Compare métodos de verificação alternativos: contentores Docker, PHPBrew, inspetor integrado do PhpStorm, os seus prós e contras
  • Veja um vídeo em inglês que demonstra o fluxo de trabalho TemPHPest + 3v4l diretamente do VSCode

Por que razão a instalação manual de versões antigas do PHP é penosa

Se administra um servidor Linux, já deve ter notado: os ramos antigos e sem suporte do PHP simplesmente desaparecem dos gestores de pacotes. O repositório ppa:ondrej/php, a principal fonte de pacotes PHP para Ubuntu, avisa honestamente durante a instalação:

Apenas são fornecidas versões suportadas do PHP para versões suportadas do Ubuntu.

Lista de versões PHP disponíveis no repositório ppa ondrej

A partir de junho de 2026, os ramos oficialmente suportados são o 8.2, 8.3, 8.4 e 8.5. O PHP 8.1 foi retirado em dezembro de 2025. O PHP 7.4 é história há muito tempo. Mas em alojamentos partilhados e VPS desatualizados, ainda se encontra o PHP 7.0, ou até o 5.6. Verificar o código contra essas versões localmente é uma verdadeira odisseia.

O PHPBrew já foi a salvação: o utilitário conseguia compilar qualquer versão do PHP a partir do código-fonte e alternar entre elas com um único comando. Mas o projeto quase não foi atualizado desde 2020, e compilar o PHP 5.6 no kernel Linux 6.x é um autêntico quebra-cabeças com patches e flags de compatibilidade. Os contentores Docker são mais simples, mas exigem escrever um Dockerfile para cada versão, descarregar imagens e continuam a consumir gigabytes de espaço em disco.

Existe uma alternativa, e funciona diretamente no seu navegador.

3V4l.org: o seu testador online para mais de 300 versões do PHP

O 3v4l.org (leetspeak para «eval») é uma sandbox online que executa o seu código PHP em mais de 300 versões do interpretador em simultâneo. Do antigo PHP 4.3.0 ao mais recente 8.5. O criador do projeto compilou e mantém todas as versões significativas lançadas ao longo da história da linguagem.

A mecânica é simples até à genialidade: cole um trecho no painel esquerdo, clique em eval() e, em segundos, obtém uma tabela de resultados. O site agrupa as versões por resultado: as linhas verdes significam que o código correu de forma idêntica, as amarelas/vermelhas significam que o comportamento difere ou ocorreu um erro. Vê imediatamente a partir de que versão mínima do PHP a sua sintaxe se torna aceitável.

O que é especialmente valioso: o 3v4l.org mostra o texto do erro para cada versão problemática. Não um abstrato «incompatível», mas um específico Parse error: syntax error, unexpected '[' in ..., com o número da linha indicado. Isto poupa horas de depuração.

Cada teste recebe um URL único; o link pode ser anexado a um ticket, enviado a um team leader ou usado como documentação: «Aqui está a prova de que as expressões match quebram no PHP 7.4.»

Exemplo 1: sintaxe curta de array, uma mina terrestre para o WordPress

Um programador escreve em JavaScript, muda para PHP e, por hábito, cria um array:

1$a = [];

Parece inofensivo. Na sua máquina local com PHP 8.4 funciona. Num servidor de testes com PHP 8.2, também funciona. Envia para produção e os clientes com PHP 5.6 veem um ecrã branco.

A sintaxe curta de array [] apareceu apenas no PHP 5.4. Antes disso, apenas array(). E embora o PHP 5.4 tenha saído em 2012, as estatísticas do WordPress.org mostraram durante décadas uma quota significativa de instalações em versões do PHP inferiores à 5.4. A situação já melhorou, mas os plugins do WordPress ainda têm de ter em conta as nuances de compatibilidade.

Execute este snippet no 3v4l.org e obtém um veredito definitivo:

1PHP 5.3.x and older: Parse error: syntax error, unexpected '['
2PHP 5.4.x and newer: OK

Sem suposições, sem ler o manual para cada construção. Tempo poupado: 30 segundos em vez de 15 minutos a pesquisar «qual a versão do PHP que suporta a sintaxe curta de arrays».

Exemplo 2: type hints, quando o código falha silenciosamente em PHP antigo

As declarações de tipo tornam o PHP mais rigoroso e previsível. Mas a evolução dos type hints foi irregular, e isso cria uma armadilha. Veja este código:

1function handleException(Exception $e) {}
2function greet(string $name) {}
3function processItems(array $items) {}
4
5handleException(new Exception('Test'));
6greet("hello");
7processItems([1, 2, 3]);

Parecem três declarações idênticas. Mas testar no 3v4l.org revela uma surpresa:

Tipo de argumento

Versão mínima do PHP

Nome de classe (Exception)

PHP 5.0

array

PHP 5.1

string / int / bool

PHP 7.0

callable

PHP 5.4

Os tipos escalares string, int e bool chegaram apenas no PHP 7.0, 12 anos depois dos tipos de classe! Se o seu plugin declara uma versão mínima de PHP 5.6 e usou function register(string $username), num alojamento antigo isto produz um erro fatal enigmático:

1Catchable fatal error: Argument 1 passed to greet() must be an instance of string,
2string given in...

A mensagem é confusa: «must be an instance of string, string given». O cliente lê isto como algo sem sentido e escreve uma crítica negativa. A razão é simples: o PHP 5.6 não compreende type hints escalares e tenta interpretar string como um nome de classe.

Com o 3v4l.org deteta estas incompatibilidades num minuto, e não depois de uma dúzia de relatórios de bugs.

Alternativas: IDE, Docker e utilitários de consola

O 3v4l.org cobre a maioria dos cenários de verificação de compatibilidade, mas não todos. Eis o que mais existe no arsenal, com prós e contras.

PhpStorm. O inspetor integrado do JetBrains destaca sintaxe incompatível com a versão de PHP selecionada: especifica «PHP 7.4» nas definições e o editor sublinha match(), propriedades tipadas, str_contains(). No entanto, o PhpStorm custa dinheiro (assinatura a partir de $99/ano) e a verificação é estática, não há execução real de código. O inspetor não mostra a diferença de comportamento do array_key_last() entre versões, enquanto o 3v4l.org mostra.

Docker. A abordagem mais flexível: docker run -v $(pwd):/app php:5.6 php /app/test.php executa código num ambiente exato. Mas testar 10 versões requer 10 contentores, 10 imagens diferentes e um script de automação. Para verificação rápida de snippets, é um exagero.

PHPBrew local. Como mencionado acima, o projeto está congelado e compilar versões antigas do PHP num kernel moderno exige malabarismos com patches. Em 2026, é mais fácil abrir o 3v4l.org.

GitHub Actions / CI. Uma matriz de versões de PHP no CI (por exemplo, strategy.matrix.php: ['7.4', '8.0', '8.1', '8.2', '8.3', '8.4', '8.5']) deteta problemas a cada push. Isto é obrigatório para bibliotecas, mas para autores de plugins WordPress que escrevem no Sublime Text ou VSCode sem CI, o 3v4l.org continua a ser a ferramenta mais acessível e rápida.

Vídeo: TemPHPest + 3v4l diretamente do VSCode

A extensão TemPHPest para VSCode integra o 3v4l.org no editor: selecione o código, pressione um atalho de teclado e obtenha resultados em todas as versões de PHP sem abrir o navegador. O autor da extensão gravou uma pequena demonstração:

A combinação VSCode + TemPHPest + 3v4l.org proporciona uma experiência praticamente perfeita: escreva código, verifique a compatibilidade de imediato, corrija erros. Funciona mais rápido do que alternar entre o editor e o navegador.

⁉️🤔 Perguntas frequentes

O 3v4l.org é gratuito?

Sim, completamente. Sem registo, sem limites no número de execuções, sem anúncios. O serviço é open source e funciona no servidor pessoal do criador. Se o utilizar com regularidade, pode apoiar o autor através do GitHub Sponsors, o que ajuda a pagar o alojamento e a eletricidade.

Que versões do PHP estão disponíveis no 3v4l.org?

Todas as versões significativas, a começar pelo PHP 4.3.0 (lançado em 2002) e a terminar no mais recente 8.5 (novembro de 2025). Cada versão menor é uma linha separada na tabela de resultados. No total, mais de 300 versões. Se uma versão necessária não estiver na lista, o autor adiciona novos lançamentos rapidamente.

É possível testar projetos inteiros ou apenas fragmentos?

O 3v4l.org foi concebido para fragmentos de código isolados, funções, classes, algoritmos individuais. Pode colar várias centenas de linhas, mas sem require e include com autoloading do composer e ligações a bases de dados. Para testes de integração completos de um projeto, os contentores Docker ou o GitHub Actions com uma matriz de versões do PHP são mais adequados.

É seguro colar código sensível num servidor de terceiros?

Não. O código no 3v4l.org recebe um URL público e é tecnicamente acessível através de um link direto. Não utilize o serviço para dados confidenciais, chaves de API, palavras-passe ou lógica de negócio proprietária. Para código proprietário, execute um contentor Docker local: docker run -v $(pwd):/app php:7.4 php /app/private-code.php.

Em que é que o 3v4l.org é melhor do que a verificação integrada no IDE?

A análise estática no IDE (PhpStorm, PHPStan) verifica a sintaxe e os tipos, mas não executa o código. O 3v4l.org executa realmente o fragmento através dos interpretadores de todas as versões e mostra o output real, as diferenças de comportamento de array_key_last(), json_encode() e preg_match() entre versões. Além disso, não requer a compra de um IDE, funciona num navegador.

O que escolher para verificar a compatibilidade do código PHP em 2026

Para o trabalho diário como autor de temas e plugins, o esquema é este. Um fragmento que levanta dúvidas vai diretamente para o 3v4l.org. Resultado em 5 segundos, o link para o teste é anexado ao commit. Um projeto onde a compatibilidade com uma dúzia de versões do PHP é importante, uma matriz no GitHub Actions: configura-se uma vez e cada push é executado automaticamente. Verificação rápida de código de terceiros antes da revisão de código, TemPHPest no VSCode (gratuito, integrado com o 3v4l.org).

O principal que mudou em comparação com 2020 (quando a versão original deste material apareceu pela primeira vez): o PHP 5.6 finalmente saiu da maioria das plataformas de alojamento, a fasquia mínima passou a ser o PHP 7.4 e no horizonte está o PHP 8.5 com novas funcionalidades e novas potenciais incompatibilidades. Mas o princípio mantém-se inalterado: verifique a compatibilidade antes do lançamento, durma descansado. O 3v4l.org torna esta verificação trivial.