Eu sei o quanto isso é frustrante. Quando o LiteSpeed (o servidor web do CyberPanel) “encasqueta” com um limite, ele ignora as configurações globais porque guarda o processo antigo do PHP em cache ou porque o site está rodando numa versão diferente da que editamos.

Na sua foto, vi que você editou o PHP 8.0. É muito provável que o seu site imprensaamazonica.com.br esteja rodando no PHP 8.1 ou 8.2, e por isso ele ignorou a sua alteração.

Vamos parar de brigar com o painel e usar a “Opção Nuclear”.

Vamos injetar um arquivo chamado .user.ini direto na raiz do seu site. Esse arquivo tem prioridade máxima e força o servidor a obedecer aos 2 Gigas apenas para este site, independentemente da versão do PHP ou dos bugs do CyberPanel.

Abra o seu Putty, copie o bloco de código inteiro abaixo, cole lá e aperte Enter:

cat <<EOF > /home/imprensaamazonica.com.br/public_html/.user.ini
upload_max_filesize = 2048M
post_max_size = 2048M
memory_limit = 2048M
max_execution_time = 3600
max_input_time = 3600
EOF
chown -R nobody:nogroup /home/imprensaamazonica.com.br/public_html/.user.ini
systemctl restart lsws

O que isso faz:

1. Ele cria um arquivo oculto (.user.ini) dentro da pasta public_html do seu site, que é o padrão oficial do LiteSpeed para forçar limites individuais.

2. Ele preenche com os 2 Gigas corretamente (com o “M”).

3. Ele dá a permissão correta para o servidor ler o arquivo e reinicia o LiteSpeed para limpar qualquer cache preso.

Após rodar isso: Feche a aba do seu WordPress, abra novamente (para forçar a página a recarregar do zero) e tente enviar o arquivo. Esse método sobrepõe qualquer bloqueio!

Carlos, se o servidor está sendo tão teimoso a esse ponto, vamos parar de “pedir permissão” para ele e contornar esse bloqueio.

O LiteSpeed às vezes fica com o processo antigo do PHP “preso” na memória RAM (como um fantasma) e simplesmente recusa a leitura dos arquivos novos, não importa quantas vezes a gente reinicie o painel.

Temos duas coisas a fazer agora: um atalho para você conseguir instalar seu plugin imediatamente e uma verificação para descobrirmos onde o servidor está escondendo esse limite.

1. O Atalho (Bypass de 100% do limite)

Como você já tem o FileZilla conectado e funcionando perfeitamente, a forma mais rápida de subir esse plugin sem esbarrar em nenhum limite do PHP é por lá (o FTP ignora as regras do PHP):

1. Descompacte o arquivo .zip desse plugin aí no seu computador (ele vai virar uma pasta normal).

2. Arraste essa pasta inteira pelo FileZilla para dentro de public_html/wp-content/plugins/.

3. Vá no painel do seu WordPress (na tela de Plugins), atualize a página e clique em Ativar logo abaixo do nome dele. Pronto, o plugin já está no ar!

2. A Prova Real (Fazendo o WordPress confessar)

Para não deixarmos esse erro impune (já que você vai precisar subir mídias e imagens pesadas depois), vamos usar o seu Putty para descobrir exatamente qual arquivo o CyberPanel está forçando o seu site a ler.

Copie e rode este comando no Putty (dentro da pasta public_html):

wp eval "echo \"Limite de Upload: \" . ini_get('upload_max_filesize') . \"\nArquivo INI carregado: \" . php_ini_loaded_file() . \"\nVersão do PHP: \" . phpversion() . \"\n\";" --allow-root

O que isso faz: Ele pergunta diretamente ao “cérebro” do WordPress qual é o limite real que ele está enxergando neste exato segundo, qual a versão do PHP ele está usando (pode ser que ele esteja no 8.2 e nós editamos o 8.0) e qual o caminho exato do arquivo que está travando tudo.

Mande o resultado que aparecer na tela preta. Com esse caminho exato, nós vamos lá com um comando certeiro e derrubamos esse limite!

Ah, esse erro aconteceu porque o seu Putty voltou para a pasta inicial do servidor (o diretório /root/), então o comando não encontrou os arquivos do WordPress ali.

Para não precisar ficar navegando entre as pastas, eu adicionei um atalho (--path) no comando. Assim, ele vai direto na “veia” do seu site, não importa em qual pasta o Putty esteja.

Copie e cole este comando completo:

wp eval "echo \"Limite de Upload: \" . ini_get('upload_max_filesize') . \"\nArquivo INI carregado: \" . php_ini_loaded_file() . \"\nVersão do PHP: \" . phpversion() . \"\n\";" --allow-root --path=/home/imprensaamazonica.com.br/public_html

Assim que rodar, mande o resultado que aparecer na tela preta. Com essas informações exatas do arquivo e da versão do PHP, nós vamos lá e derrubamos esse bloqueio de vez.

Mistério resolvido! Pegamos o culpado em flagrante.

Acontece que o seu site está rodando na versão PHP 8.3 (como mostra a última linha do seu terminal), mas lá no CyberPanel nós estávamos editando o PHP 8.0! É por isso que o servidor simplesmente ignorava todas as nossas alterações, e o nosso comando inicial não encontrou o caminho exato porque o Ubuntu organiza as pastas do PHP 8.3 de um jeito ligeiramente diferente.

Agora que sabemos a versão exata e o caminho perfeito do arquivo, vamos esmagar esse limite de 2M de uma vez por todas.

Copie todo este bloco de código, cole no Putty e dê Enter:

sed -i 's/^.*upload_max_filesize.*/upload_max_filesize = 2048M/' /usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini
sed -i 's/^.*post_max_size.*/post_max_size = 2048M/' /usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini
sed -i 's/^.*memory_limit.*/memory_limit = 2048M/' /usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini
sed -i 's/^.*max_execution_time.*/max_execution_time = 3600/' /usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini
sed -i 's/^.*max_input_time.*/max_input_time = 3600/' /usr/local/lsws/lsphp83/etc/php/8.3/litespeed/php.ini
systemctl restart lsws
killall lsphp

O que vai acontecer agora: Esse comando foi diretamente na “veia” do PHP 8.3, alterou os limites para 2 Gigas, reiniciou o LiteSpeed e matou qualquer processo “fantasma” que pudesse estar segurando o cache do limite antigo.

Pode voltar lá no painel do WordPress, dar um F5 e subir o seu plugin ou arquivo pesado. Agora vai passar liso!

Que notícia espetacular! 🎉 Finalmente vencemos esse servidor teimoso!

Parabéns pela persistência. Lidar com linha de comando, versões diferentes de PHP e painéis de hospedagem não é uma tarefa fácil, mas você tirou de letra e assumiu o controle total da sua máquina.

Como você acabou de atualizar todos os plugins (e vi que você usa o Elementor, que às vezes é sensível a atualizações), deixo apenas duas dicas rápidas de ouro para este momento pós-batalha:

1. Limpe o Cache: Como o seu servidor usa o LiteSpeed, passe o mouse sobre o ícone do LiteSpeed Cache na barra superior do seu painel WordPress e clique em “Purge All” (Limpar Tudo). Isso garante que o servidor apague qualquer arquivo velho que ficou para trás.

2. Teste Final: Abra o site numa aba anônima e clique em algumas páginas (como a Central do Agente) só para confirmar que o visual e os menus estão 100% no lugar.

O seu site Imprensa Amazônica agora está rodando num servidor super rápido, com os limites estrangulados liberados e com todos os plugins atualizados!

Se precisar de mais alguma ajuda para configurar outras coisas, otimizar a velocidade ou qualquer outro desafio, é só chamar. Um excelente trabalho!

Isso é super comum em migrações e restaurações! Quando importamos bancos de dados ou ativamos e desativamos temas várias vezes, o WordPress às vezes se emociona e cria essas “cópias fantasma” para tentar não perder dados.

A boa notícia é que é bem fácil limpar a casa sem correr o risco de quebrar o site. Aqui está o passo a passo seguro para você descobrir quem é quem:

1. O Selo de Garantia (O mais óbvio)

Olhe para a página Rede Regional na sua lista. Uma delas tem o aviso escrito “— Página principal” ao lado.

• Essa é a página oficial que o seu WordPress está exibindo para o público neste exato momento. Essa é intocável. As outras três “Rede Regional” sem esse aviso são clones ou rascunhos antigos que podem ir para o lixo.

2. A Prova Visual (A mais garantida)

A forma mais à prova de balas de não errar é usar os seus próprios olhos:

1. Passe o mouse sobre o título de uma das páginas repetidas (por exemplo, a primeira “Central do Agente”).

2. Clique com o botão direito do mouse em cima da opção Ver e escolha “Abrir link em uma nova guia”.

3. Faça o mesmo com a segunda “Central do Agente”.

4. A que abrir o seu site com o design bonito e completo é a verdadeira. A que abrir com o layout quebrado, em branco, ou só com um título perdido, é a cópia.

3. O Truque do Link (Slug)

O WordPress nunca deixa duas páginas terem exatamente o mesmo link. Se ele duplica algo, ele adiciona números ao final.

1. Passe o mouse sobre a página e clique em Edição rápida.

2. Olhe para a caixinha chamada Slug (que é o endereço da página).

3. A página original terá o slug limpo: central-do-agente. A cópia que o sistema gerou sem querer terá um número: central-do-agente-2 ou central-do-agente-3. As que têm número no slug geralmente são as duplicatas que podem ser deletadas.

🛡️ A Regra de Ouro da Faxina (Para não ter dor de cabeça):

Quando você descobrir as cópias falsas, NÃO as exclua permanentemente ainda.

Apenas clique em Colocar na lixeira. Quando a página vai para a lixeira, ela sai do ar. Abra o seu site e navegue por ele. Se tudo estiver funcionando perfeitamente e nenhum menu tiver sumido, ótimo! O lixo pode ficar lá (o WordPress esvazia sozinho depois de 30 dias).

Se por acaso você colocou na lixeira uma página que não devia e um link quebrou, basta clicar na aba “Lixo” lá no topo da tela, passar o mouse na página e clicar em Restaurar. Ela volta para o ar em 1 segundo.

Pode fazer a limpa com tranquilidade usando essas dicas!

Esse erro ERR_CONNECTION_TIMED_OUT logo após uma ação simples (como colocar uma página na lixeira) em uma VPS rápida é um sintoma clássico de duas coisas: ou o servidor sofreu um pico extremo e travou (um loop infinito gerado por algum plugin tentando reconstruir o cache), ou o firewall do CyberPanel bloqueou o seu IP por achar que você estava fazendo “requisições suspeitas” rápido demais.

Como o site está fora do ar (dando timeout), não conseguimos instalar um plugin agora. Precisamos dar um “choque” no servidor para ele voltar e, em seguida, armar o WordPress com as ferramentas de raio-X que você pediu.

Aqui está o plano de ação e as ferramentas exatas para fazer essa varredura profunda:

Passo 1: Ressuscitar o Servidor (Agora)

Antes de analisar, precisamos do site no ar. Abra o seu Putty e rode estes três comandos para reiniciar o servidor web, o banco de dados e limpar qualquer processo travado:

systemctl restart lsws
systemctl restart mariadb
killall lsphp

Dica: Tente abrir o site do seu celular usando o 4G (desligue o Wi-Fi). Se no celular abrir e no computador continuar dando Timeout, o Firewall do CyberPanel bloqueou o seu IP. (Se for isso, me avise que eu te passo o comando para desbloquear).

Passo 2: Os “Robôs” de Análise e Limpeza

Assim que o site voltar, você vai usar estas três ferramentas que são o padrão ouro para diagnosticar gargalos em VPS:

1. O Raio-X do Servidor: htop (Via Putty)

Você não precisa de plugin para ver o que está matando a VPS, o próprio Linux tem um monitor em tempo real.

• Como usar: No Putty, digite simplesmente htop e dê Enter.

• O que ele faz: Ele abre um painel colorido mostrando o uso exato de CPU e Memória RAM. Se a CPU estiver cravada em 100%, você verá exatamente qual processo (provavelmente o MySQL ou o lsphp) está causando o engasgo. Para sair da tela do htop, aperte Ctrl + C.

2. O Detetive de Erros: Plugin Query Monitor

Esta é a ferramenta de análise profunda que você pediu. É um plugin gratuito voltado para desenvolvedores.

• Como usar: Instale e ative o plugin Query Monitor no WordPress. Ele vai adicionar uma barra de status no topo do seu painel administrativo.

• O que ele faz: Ele monitora cada clique que você dá. Quando você carregar uma página, ele vai te dizer exatamente quantos segundos ela demorou para carregar, quais plugins estão consumindo mais memória e, o mais importante, vai listar em vermelho qualquer erro de banco de dados ou loop infinito. É a melhor forma de descobrir qual plugin ou função do tema está “agarrando” o servidor.

3. O Faxineiro Profissional: Plugin WP-Optimize

Já que você fez muitas importações, exclusões e trocas de tema, o banco de dados está cheio de “lixo oculto” (revisões de páginas antigas, rascunhos automáticos, tabelas de plugins que não existem mais).

• Como usar: Instale o WP-Optimize – Cache, Clean, Compress.

• O que ele faz: Vá na aba “Database” (Banco de dados) do plugin e rode a limpeza padrão. Ele vai deletar todas as revisões fantasmas, esvaziar a lixeira de forma limpa e otimizar as tabelas do banco de dados (o famoso defragment), deixando a resposta do MySQL instantânea novamente.

O que fazer agora: Rode aqueles comandos de restart no Putty. Se o site voltar, instale primeiro o Query Monitor para vermos se algo acende um alerta vermelho de imediato!

Você tem toda a razão! O htop é como se fosse o painel de instrumentos de um carro: ele é feito para ser assistido “ao vivo” e não deixa a gente selecionar e copiar o texto facilmente.

Mas não se preocupe em copiar nada, porque a sua foto já me deu o diagnóstico completo! E a notícia é excelente.

O Veredito da sua Foto:

• CPU (Processador): Suas barras numeradas de 0 a 5 estão quase vazias (todas abaixo de 6%).

• Memória RAM: Você tem quase 12 Gigas e está usando apenas 1.56G. Tem memória sobrando à vontade.

• Carga (Load Average): Está em 0.12, o que significa que o servidor está praticamente dormindo.

Conclusão: O erro de Timeout que derrubou o seu site não foi falta de recursos da máquina. O seu VPS aguentaria dezenas de sites pesados rodando aí tranquilamente.

O Verdadeiro Culpado: O Firewall (O “Leão de Chácara”)

Como a máquina está folgada, esse erro ao deletar páginas aconteceu porque o sistema de segurança do CyberPanel (geralmente o ModSecurity) é um pouco paranoico.

Quando você selecionou as 5 páginas e mandou para a lixeira de uma vez, o painel do WordPress enviou vários comandos rápidos para o banco de dados. O Firewall do servidor olhou para isso e pensou: “Opa, muitos comandos vindo do mesmo IP rápido demais! Deve ser um ataque de robô.” E aí ele bloqueia o seu IP por alguns minutos, causando a tela de Timeout só para você.

Como resolver isso agora e terminar a sua faxina:

1. O Teste de Confirmação (Tire a teima) Desligue o Wi-Fi do seu celular e tente acessar imprensaamazonica.com.br pelo 4G. Se o site abrir normal no celular, temos 100% de certeza que o servidor bloqueou apenas a internet da sua casa/escritório temporariamente.

2. Desligue a “Paranoia” do CyberPanel (Recomendado para a faxina) Para você poder apagar páginas, instalar plugins e mexer no site à vontade sem ser bloqueado, vamos pausar esse firewall rígido.

1. Acesse o painel do CyberPanel.

2. No menu lateral esquerdo, desça até Security (Segurança) e clique em ModSecurity Conf.

3. Você verá uma opção chamada SecRuleEngine. Provavelmente está como On.

4. Mude para Off e clique em Save Changes.

Pronto! Ao fazer isso, o servidor para de bloquear as suas ações rápidas no painel do WordPress. Você pode voltar lá, instalar o Query Monitor, o WP-Optimize e apagar as duplicatas sem medo do site cair.

(Dica extra: Se você quiser um comando no Putty que mostre o consumo e deixe você copiar o texto, o comando é top -b -n 1 | head -n 20. Ele tira uma “foto” em texto daquele momento exato).

Você tem toda a razão e definitivamente não é impressão sua. Essa é uma das diferenças arquitetônicas mais notáveis para quem faz a transição entre esses dois painéis.

A sensação de que o WHM/cPanel responde aos comandos de forma quase instantânea, enquanto o CyberPanel tem um certo “delay” (tempo de resposta maior), tem explicações técnicas bem claras relacionadas a como cada um foi construído.

Aqui está o que acontece nos bastidores:

1. A Arquitetura do WHM/cPanel (O Veterano)

• Linguagem Base: O cPanel é construído principalmente em Perl e C/C++. São linguagens de baixíssimo nível que conversam quase diretamente com o processador do servidor.

• Maturidade: São mais de 20 anos de mercado. O código do cPanel foi reescrito e otimizado à exaustão para executar comandos no servidor em milissegundos.

• Integração: Ele se “enraíza” no sistema operacional de uma forma muito profunda, o que torna as respostas do painel extremamente ágeis.

2. A Arquitetura do CyberPanel (O Moderno focado no Site)

• Linguagem Base: A interface e o motor de comandos do CyberPanel são construídos em Python usando o framework Django. Por natureza, o Python precisa passar por mais camadas de interpretação antes de executar um comando no servidor, o que gera aquele pequeno atraso de 1 a 3 segundos ao clicar em um botão.

• O Foco Principal: A filosofia do CyberPanel é totalmente invertida. Eles não focam em fazer o painel ser o mais rápido do mundo, mas sim em fazer o site ser o mais rápido do mundo (através da integração nativa e agressiva com o servidor web LiteSpeed).

O Grande “Trade-off” (A Troca)

Na prática, escolher entre os dois acaba sendo uma troca de prioridades:

• No cPanel: A sua experiência como administrador é impecável e rápida. Porém, o painel consome muita memória RAM apenas para existir rodando em segundo plano, e a licença custa uma fortuna. O servidor web padrão (Apache) também é mais lento para entregar o site aos visitantes.

• No CyberPanel: A sua experiência como administrador exige um pouco mais de paciência com os tempos de carregamento das telas. No entanto, ele consome menos recursos em repouso, é muito mais barato (ou gratuito) e o servidor web (LiteSpeed) faz os sites em WordPress carregarem absurdamente mais rápido para o usuário final.

Uma dica rápida para amenizar isso no CyberPanel é reiniciar o serviço do próprio painel de vez em quando via Putty (comando systemctl restart lscpd), o que limpa o cache do Python e dá uma pequena acelerada na interface.

Você tem notado essa lentidão mais ao navegar pelas opções básicas do painel ou ao executar tarefas pesadas, como backups e emissão de certificados SSL?