LiteSpeed Hosting e Gerenciamento de Versões PHP: Um Guia Técnico Completo para Usuários da AlexHost

Escolher a versão correta do PHP para o seu ambiente de hospedagem é uma das decisões mais importantes na implementação de aplicações web. A versão errada pode degradar silenciosamente o desempenho, introduzir vulnerabilidades de segurança ou quebrar completamente a compatibilidade com frameworks. A hospedagem partilhada com LiteSpeed da AlexHost suporta PHP 7.3, 7.4, 8.0 e 8.1 simultaneamente, permitindo atribuir diferentes versões de PHP por domínio através do MultiPHP Manager do cPanel — sem tocar em ficheiros de configuração do servidor ou abrir um ticket de suporte.

Este guia aborda o que cada versão do PHP realmente oferece ao nível do motor, como mudar de versão corretamente na infraestrutura da AlexHost, e como evitar os erros comuns que causam falhas nas aplicações após uma mudança de versão.

Por Que a Seleção da Versão do PHP Importa Mais do Que a Maioria dos Programadores Percebe

O PHP não é um runtime monolítico. Cada versão principal e secundária altera o comportamento do Zend Engine, deprecia funções, modifica as regras de coerção de tipos e altera a forma como o OPcache e o compilador JIT interagem com o seu código. Executar código PHP 7.3 em PHP 8.1 sem testes não é uma atualização segura — é uma aposta com o seu ambiente de produção.

O LiteSpeed Web Server trata a execução do PHP através do LSAPI (LiteSpeed Server Application Programming Interface), que é arquiteturalmente distinto do mod_php ou FastCGI do Apache. O LSAPI mantém processos de worker PHP persistentes, eliminando a sobrecarga de criação de processos por pedido que sobrecarrega as configurações tradicionais. O resultado é um tempo-até-primeiro-byte (TTFB) mensurável mais baixo e ciclos de CPU significativamente reduzidos por pedido — particularmente importante para aplicações intensivas em PHP como WordPress, Magento ou Laravel.

Quando combina o LSAPI do LiteSpeed com o MultiPHP Manager do cPanel, obtém isolamento de versão PHP por domínio ao nível do processo, não apenas ao nível da configuração. Esta é uma distinção crítica para agências ou programadores que alojam múltiplos sites de clientes numa única conta de Hospedagem Web Partilhada.

Comparação de Versões PHP: Matriz de Funcionalidades e Segurança

Conclusão principal desta tabela: O PHP 7.3 e 7.4 ultrapassaram as suas datas oficiais de fim de vida. Devem ser utilizados apenas quando uma aplicação legada tem dependências rígidas que não podem ser resolvidas — não como escolha padrão para novas implementações.

PHP 7.3: Estabilidade Legada com Limitações Conhecidas

O PHP 7.3 foi uma versão focada em manutenção que introduziu array_key_first(), array_key_last(), sintaxe flexível de heredoc/nowdoc e a função is_countable(). Representou uma plataforma estável para aplicações que estavam a ser executadas em PHP 5.x e precisavam de um caminho de migração sem refatoração agressiva.

Realidade operacional crítica: O PHP 7.3 atingiu o fim de vida em dezembro de 2021. Não recebe patches de segurança do projeto PHP. Executá-lo em produção significa que qualquer vulnerabilidade recentemente descoberta no Zend Engine ou nas extensões principais permanecerá sem correção. A única razão legítima para usar PHP 7.3 na AlexHost hoje é manter uma aplicação legada enquanto uma migração para PHP 8.x está ativamente em curso.

Caso de uso comum: Instalações mais antigas do Joomla 3.x, aplicações legadas do CodeIgniter 3, ou bases de código personalizadas da era PHP 5.6 que não foram atualizadas para usar declarações de tipo modernas.

PHP 7.4: O Último da Linha 7.x — Útil para Implementações de Transição

O PHP 7.4 foi a versão final do ramo PHP 7 e introduziu várias funcionalidades que tornaram o código significativamente mais fácil de manter e com melhor desempenho, sem exigir as alterações disruptivas que vieram com o PHP 8.0.

As propriedades de classe tipadas permitem impor restrições de tipo ao nível da classe:

class User {
    public int $id;
    public string $email;
    public ?DateTime $lastLogin;
}

Isto elimina toda uma categoria de erros de runtime que anteriormente só surgiam em caminhos de execução específicos.

As arrow functions reduzem a verbosidade de closures curtos, particularmente úteis em operações com arrays:

$multiplied = array_map(fn($n) => $n * 2, $numbers);

O pré-carregamento OPcache (introduzido no 7.4) é arquiteturalmente significativo: permite ao PHP carregar e compilar um conjunto de ficheiros na memória partilhada no arranque do servidor, tornando esses ficheiros disponíveis para todos os processos worker sem compilação repetida. No LiteSpeed com LSAPI, isto multiplica o benefício de desempenho porque os workers persistentes já evitam a sobrecarga de criação de processos.

O PHP 7.4 atingiu o fim de vida em novembro de 2022. É adequado para instalações WordPress com plugins mais antigos com incompatibilidades conhecidas com PHP 8.x, ou para implementações Drupal 7 ainda a aguardar migração.

PHP 8.0: O Ponto de Inflexão Arquitetural

O PHP 8.0 não foi uma versão incremental. Introduziu mudanças que alteraram fundamentalmente a forma como o código PHP é escrito, executado e compreendido. Vários comportamentos de longa data foram alterados ou removidos, tornando-o uma atualização disruptiva para bases de código que dependiam de coerção de tipos flexível ou funções depreciadas.

Compilação Just-In-Time

O compilador JIT no PHP 8.0 compila caminhos de código frequentes para código máquina nativo em runtime, contornando a interpretação repetida. Em cargas de trabalho intensivas em CPU — cálculos matemáticos, processamento de imagens, pipelines de transformação de dados — o JIT pode proporcionar acelerações substanciais. No entanto, para aplicações web típicas com I/O intensivo (consultas a bases de dados, leituras de ficheiros, chamadas API), o benefício do JIT é frequentemente marginal porque o bottleneck não é a execução da CPU mas a espera por recursos externos.

Compreender esta distinção evita o erro comum de esperar que o JIT acelere automaticamente um site WordPress. Não o fará — a menos que esse site esteja a fazer computação significativa em processo.

Union Types e Named Arguments

Os union types permitem que um parâmetro de função ou valor de retorno aceite múltiplos tipos explicitamente:

function processInput(int|string $input): int|false {
    // ...
}

Os named arguments desacoplam a ordem dos argumentos das assinaturas de funções, melhorando drasticamente a legibilidade em funções com múltiplos parâmetros opcionais:

array_slice(array: $data, offset: 2, length: 5, preserve_keys: true);

A Expressão Match

A expressão match substitui switch com comparação de tipos estrita, sem comportamento de fall-through e retornos baseados em expressões:

$status = match($code) {
    200, 201 => 'success',
    404 => 'not found',
    500 => 'server error',
    default => 'unknown',
};

Ao contrário de switch, match lança um UnhandledMatchError se nenhum ramo corresponder e nenhum padrão predefinido for fornecido — tornando impossíveis as falhas silenciosas.

Atributos (Metadados Estruturados)

Os Atributos do PHP 8.0 substituem as anotações docblock usadas por frameworks como Doctrine e Symfony. São analisados pelo próprio motor, não por regex em código de utilizador:

#[Route('/api/users', methods: ['GET'])]
public function listUsers(): Response { ... }

Isto tem implicações significativas para o desempenho de frameworks e a precisão das ferramentas IDE.

PHP 8.1: PHP Moderno de Nível de Produção

O PHP 8.1 é a versão que a maioria dos novos projetos deve ter como alvo no momento desta escrita. Baseia-se na fundação do PHP 8.0 e adiciona funcionalidades que abordam lacunas de longa data no sistema de tipos da linguagem e no modelo de concorrência.

Enumerações

Os Enums resolvem o problema das “constantes mágicas” que afligiu as bases de código PHP durante décadas:

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
    case Pending = 'pending';
}

Os enums com suporte podem ser armazenados em bases de dados e serializados de forma limpa. Os enums puros fornecem representação de estado com segurança de tipos sem a fragilidade de constantes de classe ou flags inteiros.

Fibers: Multitarefa Cooperativa

As Fibers introduzem uma primitiva de concorrência de baixo nível no PHP. Ao contrário das threads, as Fibers são cooperativas — cedem o controlo explicitamente. Esta é a base que os frameworks PHP assíncronos (como ReactPHP e Amp) usam para implementar I/O não bloqueante sem exigir extensões como Swoole:

$fiber = new Fiber(function(): void {
    $value = Fiber::suspend('first suspension');
    echo "Resumed with: " . $value;
});

$value = $fiber->start();
$fiber->resume('hello');

Para aplicações em execução em VPS Hosting com controlo total sobre o runtime PHP, as Fibers abrem a porta para construir aplicações baseadas em event-loop em PHP puro.

Propriedades Readonly

As propriedades readonly impõem imutabilidade após a inicialização, o que é essencial para objetos de valor e entidades de domínio em arquiteturas DDD (Domain-Driven Design):

class OrderId {
    public function __construct(
        public readonly string $value
    ) {}
}

Uma vez definida no construtor, $value não pode ser modificada. Qualquer tentativa lança um Error. Isto elimina toda uma classe de código boilerplate de programação defensiva.

Intersection Types

Onde os union types dizem “isto OU aquilo,” os intersection types dizem “isto E aquilo” — exigindo que um valor implemente múltiplas interfaces simultaneamente:

function processEntity(Serializable&Countable $entity): void { ... }

Isto é particularmente valioso em arquiteturas de contentores de serviços e pipelines de middleware.

Como Alterar Versões PHP na Hospedagem LiteSpeed da AlexHost via cPanel

Os ambientes de VPS com cPanel e hospedagem partilhada da AlexHost expõem a gestão de versões PHP através do MultiPHP Manager do cPanel. Aqui está o procedimento exato:

Passo 1: Aceder ao Painel cPanel

Inicie sessão na sua conta AlexHost e navegue até à secção Detalhes de Login para obter as suas credenciais cPanel. Abra o cPanel diretamente através do URL fornecido (normalmente yourdomain.com:2083 ou o IP direto com porta).

Passo 2: Navegar para o MultiPHP Manager

Dentro do cPanel, localize a secção Software. Clique em MultiPHP Manager. Esta interface lista todos os domínios e subdomínios associados à sua conta, cada um com a versão PHP atualmente atribuída exibida.

Passo 3: Selecionar o Domínio Alvo e a Versão PHP

Marque a caixa de seleção ao lado do domínio ou subdomínio que pretende modificar. Use o menu suspenso Versão PHP para selecionar entre as versões disponíveis — PHP 7.3, 7.4, 8.0 ou 8.1 dependendo da configuração do seu plano de hospedagem. Clique em Aplicar.

Passo 4: Verificar a Alteração

Após aplicar, a alteração entra em vigor imediatamente para novos pedidos. Verifique criando um ficheiro temporário phpinfo.php na raiz do documento do domínio:

<?php phpinfo(); ?>

Confirme a versão PHP no resultado, depois elimine este ficheiro imediatamente — deixar phpinfo() exposto em produção é uma vulnerabilidade de segurança que revela a configuração do seu servidor a atacantes.

Passo 5: Testar a Funcionalidade da Aplicação

Não assuma que uma alteração de versão PHP é segura sem testar. Verifique o registo de erros da sua aplicação (/home/username/logs/ ou através da ferramenta Erros do cPanel) para avisos de depreciação, erros fatais ou chamadas de funções indefinidas que indiquem incompatibilidade.

Substituição de Versão PHP por Diretório via .htaccess

Para controlo granular — por exemplo, executar um subdiretório legado em PHP 7.4 enquanto o site principal corre PHP 8.1 — pode substituir a versão PHP ao nível do diretório usando .htaccess:

<FilesMatch ".php$">
    SetHandler application/x-httpd-ea-php81
</FilesMatch>

O formato do nome do handler é application/x-httpd-ea-phpXX onde XX corresponde ao número de versão sem o ponto decimal. Esta é uma convenção EasyApache 4 usada em ambientes cPanel.

Matriz de Decisão para Seleção de Versão PHP

Implicações de Segurança de Executar Versões PHP em Fim de Vida

Este ponto merece ênfase explícita. As versões PHP após a sua data de fim de vida não recebem patches de segurança do projeto PHP. Isto significa:

• CVEs descobertos após o EOL não são corrigidos no ramo da versão afetada.
• Ambientes de hospedagem partilhada estão particularmente expostos porque um processo PHP comprometido pode potencialmente afetar contas vizinhas dependendo da configuração de isolamento.
• A conformidade PCI DSS proíbe explicitamente a execução de software após a data de fim de vida suportada pelo fornecedor. Se processar pagamentos, executar PHP 7.3 ou 7.4 é uma violação de conformidade.
• As Firewalls de Aplicações Web (WAF) podem mitigar alguma exposição, mas não podem corrigir vulnerabilidades ao nível do motor.

Se precisar de controlo total sobre o seu ambiente PHP, cadência de patches de segurança e a capacidade de compilar extensões PHP personalizadas, um Servidor Dedicado oferece o isolamento e o acesso administrativo que os ambientes partilhados não conseguem proporcionar.

Considerações de Desempenho PHP Específicas do LiteSpeed

Vários comportamentos do LiteSpeed interagem com a seleção de versão PHP de formas que não são óbvias:

LiteSpeed Cache (LSCache): O plugin LSCache para WordPress opera ao nível do servidor web, não ao nível do PHP. No entanto, as taxas de acerto OPcache melhoradas do PHP 8.x significam que as falhas de cache são servidas mais rapidamente, reduzindo a penalidade de desempenho dos pedidos não armazenados em cache.

Persistência de workers LSAPI: O LiteSpeed mantém os workers PHP ativos entre pedidos. Isto significa que o compilador JIT do PHP 8.1 tem mais oportunidade de aquecer e otimizar caminhos de código frequentes em comparação com uma configuração CGI tradicional onde cada pedido inicia um processo a frio.

PHP-FPM vs. LSAPI: Em Painéis de Controlo VPS onde configura a stack por si mesmo, pode escolher entre PHP-FPM e LSAPI. O LSAPI supera consistentemente o PHP-FPM em benchmarks para ambientes LiteSpeed porque utiliza um protocolo de comunicação construído especificamente em vez da interface genérica do FastCGI.

Limites de memória e contagem de workers: O PHP 8.x tem uma pegada de memória base ligeiramente superior ao PHP 7.x devido a estruturas de runtime adicionais para JIT e o sistema de tipos. Se estiver a executar num ambiente com memória limitada, monitorize as definições memory_limit após a atualização.

Lista de Verificação Prática de Conclusões Principais

Antes de alterar ou selecionar uma versão PHP na sua hospedagem LiteSpeed da AlexHost, trabalhe com esta lista de verificação:

• Verifique a matriz oficial de compatibilidade PHP da sua aplicação — não adivinhe. Laravel, WordPress, Magento e Drupal publicam versões PHP mínimas e máximas suportadas.
• Audite plugins e extensões instalados — o código de terceiros é a fonte mais comum de incompatibilidade com PHP 8.x. Execute composer check-platform-reqs se usar Composer.
• Teste a alteração primeiro num ambiente de staging — use um subdomínio ou ambiente de staging para testar a alteração de versão PHP antes de a aplicar em produção.
• Reveja os registos de erros imediatamente após a mudança — procure entradas E_DEPRECATED, E_NOTICE e E_FATAL que indiquem compatibilidade quebrada.
• Elimine quaisquer ficheiros phpinfo() criados durante a verificação.
• Não execute versões PHP em EOL em produção a menos que tenha um plano de migração documentado e com prazo definido e controlos de segurança compensatórios.
• Use o MultiPHP INI Editor (também na secção Software do cPanel) para ajustar diretivas PHP por domínio como memory_limit, upload_max_filesize e max_execution_time após uma mudança de versão — os padrões diferem entre versões.
• Se a sua aplicação requer PHP 8.2 ou 8.3, considere atualizar para um plano VPS onde controla a stack de software completa e pode instalar qualquer versão PHP através de repositórios como Remi ou ondrej/php.

Perguntas Frequentes

Posso executar diferentes versões PHP em diferentes domínios dentro da mesma conta de hospedagem partilhada da AlexHost?

Sim. O MultiPHP Manager do cPanel aplica definições de versão PHP ao nível por domínio. Cada domínio ou subdomínio na sua conta pode executar uma versão PHP diferente de forma independente, gerida através da mesma interface sem afetar outros domínios.

A mudança de versões PHP no MultiPHP Manager requer um reinício do servidor ou causa tempo de inatividade?

Não. A alteração aplica-se imediatamente a novos pedidos recebidos. Os processos PHP de longa duração existentes podem continuar na versão antiga até serem concluídos, mas para pedidos web típicos esta transição é transparente e não causa tempo de inatividade mensurável.

O compilador JIT do PHP 8.1 irá automaticamente acelerar o meu site WordPress?

Não significativamente para implementações WordPress padrão. O JIT beneficia cargas de trabalho intensivas em CPU. O desempenho do WordPress é principalmente limitado pelo tempo de consulta à base de dados e operações de I/O, que o JIT não acelera. As melhorias mais impactantes do PHP 8.x para WordPress são a melhor eficiência do OPcache e a redução da sobrecarga de chamadas de funções.

Qual é a diferença entre o MultiPHP Manager e o MultiPHP INI Editor no cPanel?

O MultiPHP Manager controla qual versão PHP é atribuída a cada domínio. O MultiPHP INI Editor controla as diretivas de configuração PHP (definições php.ini) para cada combinação de domínio e versão PHP. Ambas as ferramentas são necessárias para a gestão completa do ambiente PHP — a seleção de versão por si só não configura limites de memória, tempos limite de execução ou carregamento de extensões.

O que devo fazer se a minha aplicação falhar após atualizar para PHP 8.x?

Primeiro, reverta para a versão PHP anterior no MultiPHP Manager para restaurar o serviço. Em seguida, examine os registos de erros para mensagens de erro específicas. Os problemas comuns incluem funções removidas (each(), create_function()), comportamento alterado de coerção de tipos e métodos de classe de estilo construtor depreciados. Resolva cada problema num ambiente de staging antes de tentar a atualização novamente. Se a aplicação for um CMS ou framework, verifique se existe uma versão atualizada que suporte oficialmente PHP 8.x.