Seletor de PHP na hospedagem partilhada: executar versões de PHP em paralelo com segurança

O que um seletor PHP controla

A Seletor PHP É uma interface de gestão para ambientes de execução PHP disponibilizada pelo operador do servidor. Através dela, podes, dependendo da configuração do alojamento, selecionar uma versão do PHP e as extensões ou opções associadas. A interface não instala automaticamente todas as versões pretendidas, nem garante que cada seleção se aplique separadamente a cada domínio.

Para o planeamento, há três níveis importantes: no servidor, podem existir várias versões instalado ; no plano, porém, o fornecedor só pode disponibilizar uma parte dessas opções para seleção. Além disso, a versão que uma solicitação concreta irá efetivamente executar depende da configuração do domínio, do servidor web e do manipulador PHP responsável. Uma entrada visível no menu, por si só, não responde a esta última questão.

O CloudLinux disponibiliza ambientes de execução alternativos como PHP antigo pronto. Além disso, existe o ambiente PHP nativo do servidor ou do painel de controlo. O termo «nativo» não se refere a um número de versão específico: a versão do PHP e a configuração subjacentes são determinadas pelo ambiente do servidor em questão. Por isso, ao mudar para o ambiente nativo, uma aplicação pode deparar-se com requisitos diferentes dos que encontraria ao optar por uma versão antiga do PHP.

Se precisares de uma versão específica do PHP para o teu alojamento, verifica primeiro os requisitos da aplicação e, em seguida, pergunta se essa versão está efetivamente disponível no plano. Esclarece também se as extensões e configurações necessárias podem ser alteradas. As funcionalidades documentadas do CloudLinux descrevem as capacidades do software, não o equipamento específico de um determinado pacote de alojamento.

Contas, domínios e isolamento

Imagina um site atual e uma aplicação empresarial mais antiga que necessitem de ramos PHP diferentes. Se estiverem em contas de alojamento separadas, podem utilizar versões diferentes, desde que ambas as contas tenham a sua própria seleção de seletores e que o fornecedor disponibilize as ramificações necessárias. Trata-se de uma possibilidade de funcionamento paralelo no mesmo servidor, mas não é garantido em todos os planos.

A situação é diferente no caso de dois domínios na mesma conta. O CloudLinux descreve uma seleção do Selector que se aplica a todos os domínios de um utilizador geridos pelo Selector. Por isso, se alterares a versão nesse local, deves contar com repercussões em ambas as aplicações; a mera existência do Selector não implica uma seleção independente dos domínios.

O Âmbito de aplicação Por isso, é necessário esclarecer esta questão antes de qualquer alteração. Caso o fornecedor não suporte um controlo adequado por domínio, a criação de contas separadas pode ser uma solução. Para tal, as aplicações têm de ser transferidas em conformidade e as respetivas condições tarifárias têm de ser verificadas. Um segundo domínio ou um diretório adicional, por si só, não permite ainda a escolha independente da versão.

O CageFS serve, no ambiente multiutilizador do CloudLinux, para isolar os ambientes dos utilizadores. Estes Isolamento deve ser distinguido da questão de saber qual a versão do PHP que pode ser definida para um domínio. Mesmo um isolamento adicional de sites dentro de uma conta não prova, por si só, uma seleção independente do seletor; para mais informações sobre este conceito, consulte o artigo sobre CageFS por site na hospedagem partilhada.

O CloudLinux também documenta uma configuração especial do Selector sem o CageFS ativado para um servidor com apenas uma conta de utilizador. Isso não implica, de forma alguma, uma recomendação para desativar o CageFS num servidor normal de alojamento partilhado. A arquitetura de segurança e a sua configuração são da responsabilidade do operador; enquanto cliente, deve informar-se sobre a separação oferecida e o seu âmbito.

Selector e MultiPHP Manager

CloudLinux PHP O Selector e o cPanel MultiPHP Manager são ferramentas diferentes. O Selector gere as opções de PHP disponibilizadas no âmbito da sua integração; o MultiPHP Manager permite gerir as configurações de PHP por domínio. No entanto, o facto de uma destas interfaces permitir configurações por domínio não significa que estas estejam disponíveis no seu próprio plano ou que sejam permitidas para todas as combinações.

Na interação documentada do cPanel, o CloudLinux indica, entre outros, o seguinte para a utilização do Seletor: Configuração do sistema no MultiPHP Manager e o PHP-FPM desativado para o domínio em questão. Estes pré-requisitos descrevem uma integração específica, não um guia passo a passo de aplicação geral. A forma como o fornecedor de alojamento configurou o handler e as interfaces determina qual a configuração que se aplica.

Se ambas as interfaces estiverem visíveis, não deves determinar as respetivas funções através de tentativas num site em produção. Uma configuração relacionada com o domínio no MultiPHP Manager e uma seleção no Selector podem, de outra forma, criar expectativas que não correspondem ao handler efetivamente utilizado. Pede ao fornecedor que te explique qual é a ferramenta determinante para o domínio em questão e quais as alterações que afetam outros domínios.

Para tomar uma decisão concreta, é útil fazer algumas perguntas: Que interface está disponível no plano? A escolha aplica-se por conta ou por domínio, e quais são as versões de PHP e extensões autorizadas? Pergunte também se o SSH e as tarefas agendadas estão disponíveis e qual o interpretador que as executa. Desta forma, é possível planear separadamente as aplicações web e as tarefas em segundo plano, em vez de ter de deduzir todas as vias de execução a partir de um painel de controlo.

Por fim, verifique se existe um ambiente de teste isolado e uma cópia de segurança disponível e quem poderá restaurar a configuração anterior em caso de falha. Só quando se souber quem é responsável pela interface e qual a área afetada é que se poderá preparar uma mudança com um risco controlável. Opções de menu não confirmadas ou uma solução de configuração supostamente universal não ajudam em nada.

Escolher o âmbito de aplicação adequado

Antes de alterares a versão do PHP no alojamento, verifica o Âmbito de aplicação da configuração disponível. O que é determinante não é apenas o número de domínios que geres, mas sim quais deles utilizam o mesmo utilizador e a mesma seleção do Selector. A tabela traduz requisitos típicos em perguntas que podes esclarecer com o teu fornecedor.

O CloudLinux Selector aplica a sua seleção, conforme documentado, aos domínios de um utilizador que gere. Se duas aplicações na mesma conta necessitarem de versões diferentes, a separação em contas distintas pode ajudar, desde que o plano e as versões disponibilizadas o permitam. Deve consultar o fornecedor para saber quais são os custos adicionais e as condições aplicáveis.

Outra possibilidade é uma gestão específica por domínio expressamente suportada, por exemplo, através do cPanel MultiPHP Manager. Não é possível afirmar de forma geral se esta opção está disponível no plano específico nem como interage com um seletor. Também é possível efetuar uma alteração através de .htaccess não deves partir do princípio de que é um substituto fiável.

Além disso, a separação das versões não resolve todas as dependências: uma aplicação pode exigir determinados módulos ou configurações, enquanto uma tarefa agendada utiliza o seu próprio interpretador. Regista estes requisitos separadamente, para que, ao contactar o fornecedor, não te limites a perguntar apenas pelo número da versão, mas sim pelo caminho de execução completo.

Verificar a versão do PHP e o suporte

Escolhe um ramo do PHP que a tua aplicação específica suporte e para o qual existam correções de segurança disponíveis. Para tal, verifica os requisitos da versão do CMS ou da loja online utilizada, bem como dos plugins, temas, bibliotecas e código próprio. Uma versão atual do PHP, por si só, não torna automaticamente executável uma aplicação mais antiga e incompatível.

A tabela oficial do PHP distingue apoio ativo e uma fase subsequente com correções de segurança. De acordo com uma pesquisa realizada a 4 de novembro de 2026, o PHP 8.2 e o 8.3 recebem apenas correções de segurança; o PHP 8.4 e o 8.5 encontram-se em suporte ativo. Para o PHP 8.2, o suporte oficial à segurança termina a 31 de dezembro de 2026. Verifica novamente o estado antes de tomares uma decisão, pois esta classificação pode mudar com o tempo.

A indicação de uma versão no Selector responde a uma questão diferente da tabela de suporte: mostra uma seleção no teu ambiente, mas não confirma nem o suporte oficial nem a compatibilidade da tua aplicação. Por outro lado, o facto de uma ramificação ter suporte oficial não significa necessariamente que o teu plano de alojamento a ofereça.

Um fornecedor pode, eventualmente, oferecer o seu próprio suporte prolongado para pacotes mais antigos. Para tal, esclarece por escrito quais os pacotes e correções de segurança abrangidos, qual a duração desse suporte e como serão disponibilizadas as atualizações. Este Apoio ao fornecedor não deve ser confundido com o suporte oficial do projeto PHP e não substitui um plano de migração para a aplicação.

Se estiver prevista uma mudança para um ramo mais recente, verifica também os passos de migração que foram ignorados e as tarefas em segundo plano. O artigo sobre PHP 8.5 na hospedagem e para verificação de compatibilidade explica quais as dependências e os processos que podem ser relevantes nesta mudança de versão específica.

Preparar a transição de forma controlada

Começa por fazer um balanço: que plataforma tens à tua disposição, que domínios gere e que versões de PHP estão autorizadas para a tua conta? Anota as opções disponíveis até ao momento e, em caso de dúvidas, esclarece o âmbito de aplicação efetivo. Desta forma, evita migrar um site que pensas ser único, quando na verdade existem outros domínios envolvidos.

Suponhamos que uma aplicação atual e uma aplicação mais antiga estejam a ser executadas em paralelo. Verifica primeiro se os seus requisitos são compatíveis com uma versão-alvo comum. Caso contrário, pode ser útil fazer uma seleção individual em contas separadas; uma alternativa relacionada com o domínio só é viável se o fornecedor a suportar para a tua configuração.

Antes de efetuar alterações em ambiente de produção, verifica se existe uma versão atualizada Cópia de segurança dos ficheiros e da base de dados e que a sua recuperação esteja definida. Um ambiente de teste isolado é útil, caso o possas disponibilizar: aí, podes testar a versão de destino sem colocar em risco desnecessariamente os visitantes ou os dados de produção. Cabe ao fornecedor esclarecer se o plano inclui um ambiente de staging ou cópias de segurança.

Além da versão atual e da versão pretendida do PHP, documente também as extensões necessárias e as opções relevantes. Compare estes dados com os requisitos da aplicação e com as configurações autorizadas no plano. O CloudLinux Manager permite definir regras administrativas para versões e extensões; isso não significa, contudo, que todas as opções possam ser alteradas pelos próprios clientes.

No ambiente isolado, testa não só a página inicial, mas também os processos de início de sessão, os formulários, as importações e outros procedimentos importantes para o teu projeto. Verifique as tarefas agendadas separadamente, uma vez que a sua execução não é comprovada apenas pela visualização do site. Registe quaisquer anomalias e resolva os problemas de compatibilidade antes da migração para o ambiente de produção.

Por fim, coloca um Viagem de regresso Importante: Quem pode voltar a selecionar a versão anterior e que definições devem ser verificadas depois disso? Planeie a transição para um momento adequado e, em seguida, acompanhe as aplicações afetadas. O simples facto de voltar à versão anterior não garante que todas as extensões e opções fiquem novamente definidas como antes.

Verificar a Web, a CLI e as tarefas Cron

Um site e as suas tarefas em segundo plano não têm de utilizar o mesmo interpretador PHP. As solicitações HTTP são processadas por um interpretador em tempo de execução determinado pelo servidor Web e pelo respetivo manipulador; por outro lado, uma chamada da linha de comandos inicia o interpretador que o ambiente em questão encontrar. O CloudLinux distingue os caminhos nativos para os interpretadores Web e CLI. Por isso, a informação apresentada no PHP Selector, por si só, não responde a todas as questões relativas à execução efetiva.

Se o SSH estiver disponível no teu plano, podes executar o seguinte comando de leitura numa sessão de terminal. Este comando mostra a versão do Interpretadores de CLI, que é encontrado precisamente para esta chamada. Para o teste, não são necessárias alterações nos ficheiros ou nas definições.

php -v

O resultado não indica nem a versão do PHP de um pedido HTTP nem a de uma tarefa cron executada de outra forma. Uma tarefa agendada pode utilizar um caminho de intérprete específico ou outro ambiente. Por isso, verifica a chamada definida e o ambiente de execução da tarefa em questão, em vez de extrapolar a saída da tua sessão interativa para esse contexto.

Para a verificação na Web, utiliza um método protegido e suportado pelo fornecedor e, se necessário, pergunta qual é o gestor responsável. Um script de diagnóstico acessível ao público com informações detalhadas sobre o ambiente não constitui uma solução padrão adequada. Verifique também as tarefas agendadas através de um canal suportado e, em seguida, verifique se, por exemplo, uma importação ou um trabalho de envio funciona efetivamente conforme previsto.

Para cada caminho de execução relevante, regista qual a versão esperada e como foi verificada. Se o painel, a saída do SSH e o comportamento de uma tarefa fornecerem indicações diferentes, esclarece primeiro com o fornecedor a responsabilidade pelo respetivo ambiente de execução. Desta forma, evitas alterar uma configuração no local errado.

Identificar a causa do erro após a substituição

Se a página inicial carregar após a mudança, mas um formulário ou uma importação não funcionar, significa que a transição ainda não foi devidamente testada. Repete o processo em questão e anota a hora, a função e a mensagem de erro observada. Compare estas informações com os registos da aplicação e do servidor disponíveis, desde que o seu plano de serviços permita o acesso aos mesmos; os dados sensíveis dos registos não devem constar em ficheiros acessíveis ao público.

Em seguida, verifica a Compatibilidade da aplicação em questão e das suas extensões com o ramo PHP selecionado. Um formulário pode, por exemplo, depender de um plugin que nem sequer é executado na página inicial. Numa importação, as suas dependências e o caminho de execução efetivo são também relevantes: uma tarefa em segundo plano pode utilizar um ambiente de execução diferente do do site.

Antes de efetuar a mudança, compara as extensões PHP disponíveis e ativadas para a versão de destino, bem como as opções necessárias, com a tua documentação. A seleção de um ramo do PHP não confirma automaticamente que todos os módulos e configurações necessários estejam corretos. As alterações que pode efetuar por conta própria dependem da autorização do administrador.

Verifica também se o domínio em questão corresponde efetivamente ao esperado manipulador e é utilizado o período de execução pretendido. Caso existam várias interfaces de administração, esclarece as respetivas competências com o fornecedor antes de alterares outras definições. Uma indicação no Selector não tem de explicar qual o caminho de execução que processa um pedido específico.

Aviso: Não defina os caminhos de configuração de forma genérica através de PHPRC ou PHP_INI_SCAN_DIR . O CloudLinux alerta que essas alterações nos caminhos de configuração do PHP podem afetar o Selector. Se for necessário definir um caminho específico, consulte primeiro o fornecedor.

Caso não seja possível resolver o erro rapidamente, utiliza o procedimento de reversão previamente definido para voltar à versão anterior. Em seguida, verifica novamente a versão efetivamente em vigor, as extensões e opções, bem como as funções afetadas. Não confie no facto de que um regressão à versão anterior restaure automaticamente todas as configurações anteriores; registe as diferenças para a próxima tentativa.

Planear a operação de sistemas legados e a migração

Para um funcionamento contínuo, o fator determinante é, em primeiro lugar, a Âmbito de aplicação: Se for adequada uma seleção comum para os domínios de um utilizador geridos pelo Selector, este pode ser uma interface adequada. Se, por outro lado, duas aplicações necessitarem de versões independentes, considere uma gestão por domínio suportada pelo fornecedor ou contas de alojamento separadas. A opção documentada do Selector, por si só, não garante uma configuração independente para cada domínio na mesma conta.

Contas separadas podem dissociar organizacionalmente as decisões relativas às versões, desde que sejam disponibilizados os ramos necessários em cada caso. Uma solução específica para cada domínio também pode ser adequada, desde que o fornecedor a disponibilize e que a sua interação com outras ferramentas PHP esteja esclarecida. Antes de proceder à mudança, informe-se sobre os custos, as condições tarifárias e as responsabilidades; a viabilidade técnica não implica, por si só, a garantia de um determinado pacote.

Uma aplicação mais antiga não deve permanecer permanentemente numa versão antiga apenas pelo facto de esta estar disponível no menu. Planeia a Migração uma combinação suportada de aplicação, dependências e PHP: identifica atualizações em falta, extensões substituíveis e adaptações necessárias. Define uma data para a próxima verificação de compatibilidade e uma data-limite para a substituição.

Verifique regularmente o estado oficial do suporte da ramificação do PHP que está a utilizar e, ao mesmo tempo, acompanhe as mensagens de erro e os processos empresariais importantes. O facto de uma versão mais antiga estar disponível não constitui garantia de suporte oficial contínuo. A tabela de suporte do projeto PHP deve ser verificada novamente antes de qualquer decisão a longo prazo, uma vez que o estado pode alterar-se com o tempo.

Se um fornecedor prometer suporte alargado, pede que te forneçam comprovativos dos pacotes em causa, do tipo de correções de segurança e da duração do serviço. Este suporte deve ser avaliado separadamente do suporte oficial do PHP e não substitui nem as atualizações da aplicação nem a migração planeada. Regista também quem se encarregará de tratar das alterações e das falhas durante o período de transição.