Painel de hospedagem
Permite verificar arquivos, versões de PHP, logs, banco de dados, backups, limites do ambiente e outras configurações essenciais.
Erro 500, Critical Error, tela branca, plugin quebrado, banco de dados, acesso ou configuração. Com acesso à hospedagem, investigamos a causa para recuperar e estabilizar o ambiente.
Um erro visível pode ter origem em plugin, tema, versão do PHP, memória, permissões, banco de dados, servidor, cache, atualização incompleta ou código customizado. Corrigir apenas o sintoma pode esconder a causa e produzir uma nova falha depois.
Primeiro entendemos o que quebrou. Depois decidimos o que precisa ser alterado.
O WordPress Rescue é uma intervenção técnica de recuperação e estabilização. Trabalhamos a partir de evidências: logs, arquivos, banco de dados, configurações e histórico recente do ambiente sempre que essas informações estiverem disponíveis.
Em muitos incidentes, o próprio WordPress está inacessível. Por isso, somente um usuário do wp-admin pode não ser suficiente.
Permite verificar arquivos, versões de PHP, logs, banco de dados, backups, limites do ambiente e outras configurações essenciais.
Pode ser necessário para inspecionar, isolar, substituir ou recuperar arquivos quando o painel administrativo não responde.
Falhas de conexão, tabelas corrompidas ou usuários administrativos podem exigir acesso direto ao MySQL/MariaDB ou ferramenta equivalente.
Em ambientes que oferecem esse recurso, o terminal pode acelerar diagnóstico, análise de logs, permissões, WP-CLI e operações controladas.
O formulário serve somente para triagem. Após a análise inicial, a RADIAL orientará quais acessos são realmente necessários e o canal adequado para compartilhá-los.
Os sintomas abaixo são comuns, mas a causa real só é confirmada após diagnóstico no ambiente.
O navegador mostra erro 500 e o website ou wp-admin deixa de carregar.
Analisamos logs, PHP, .htaccess, plugins, tema, memória, permissões e alterações recentes para isolar a origem da falha.
A mensagem “There has been a critical error on this website” aparece após atualização, instalação ou alteração.
Ativamos diagnóstico seguro, identificamos o componente que gera a exceção e definimos rollback, correção ou substituição.
O website abre em branco, sem mensagem clara de erro.
Verificamos fatal errors, memória, compatibilidade de PHP, tema, plugins, cache e saída prematura de código.
O site pode até abrir, mas o painel administrativo entra em loop, bloqueia o usuário ou retorna erro.
Analisamos autenticação, cookies, URLs, permissões, usuários, banco, plugins de segurança e configurações do servidor.
Uma atualização ou instalação derruba páginas, checkout, formulário ou todo o website.
Isolamos o plugin sem depender do wp-admin, verificamos dependências e versão do PHP e avaliamos rollback, correção ou alternativa.
Layout desaparece, funções quebram ou o site para após alteração ou atualização do tema.
Verificamos tema pai, child theme, functions.php, templates, dependências e arquivos modificados para recuperar a camada visual com segurança.
O WordPress exibe “Error establishing a database connection” ou perde acesso a conteúdos e configurações.
Validamos serviço de banco, credenciais, host, privilégios, wp-config.php, capacidade do servidor e integridade das tabelas.
Tabelas retornam erros, conteúdos somem, consultas falham ou o WordPress se comporta de forma inconsistente.
Mapeamos a extensão da corrupção, avaliamos backups, executamos reparos possíveis e reconstruímos estruturas quando tecnicamente viável.
Redirecionamentos, arquivos desconhecidos, usuários estranhos, spam, bloqueios do navegador ou alertas de segurança.
Investigamos arquivos alterados, usuários, persistência, plugins vulneráveis e pontos de entrada; removemos o que for identificado e recomendamos hardening.
WordPress, plugin, tema ou PHP é atualizado e recursos deixam de funcionar imediatamente ou pouco depois.
Comparamos versões, logs e dependências, recuperamos uma combinação estável e planejamos a atualização correta quando necessário.
A primeira hora técnica é utilizada para diagnóstico e intervenção inicial. Se o incidente puder ser resolvido nesse período, o atendimento pode terminar ali. Quando encontramos uma falha que exige mais trabalho, explicamos o cenário e estimamos a continuidade antes de avançar.
A classificação é confirmada após a triagem. Os valores abaixo são referências de hora técnica para o atendimento WordPress Rescue.
Falhas comuns com causa relativamente localizada e baixo risco de reconstrução.
Problemas que envolvem mais de uma camada do ambiente ou exigem investigação de servidor e compatibilidade.
Incidentes com risco elevado, perda de integridade ou necessidade de reconstrução técnica parcial.
Cobrança mínima de 1 hora técnica para início do diagnóstico.
Após a primeira hora, a continuidade pode ser contabilizada em blocos de 30 minutos.
Se o diagnóstico indicar um projeto maior de reconstrução, apresentamos escopo separado antes de prosseguir.
Licenças, serviços de terceiros, infraestrutura, migração ou recursos externos não fazem parte da hora técnica salvo indicação expressa.
O processo é técnico, mas a comunicação precisa continuar simples.
Você informa o endereço do website, sintomas percebidos e quais acessos estão disponíveis.
Solicitamos somente os acessos necessários para investigar o incidente com segurança.
Quando o ambiente permite, verificamos backups ou criamos uma cópia antes de alterações de maior risco.
Logs, arquivos, banco, versões e configurações ajudam a localizar a causa real.
Aplicamos a intervenção apropriada: isolamento, rollback, reparo, substituição ou reconstrução técnica.
Validamos o funcionamento e indicamos atualizações, segurança, backup ou mudanças necessárias para reduzir recorrência.
Se o problema revelar uma estrutura tecnicamente inviável, separamos recuperação de reconstrução para manter escopo e expectativa claros.
Restaurar o funcionamento e tratar a causa identificada com a menor intervenção coerente.
Corrigir riscos diretamente relacionados ao incidente e indicar o que precisa ser atualizado ou reorganizado.
Quando banco, código ou arquitetura não permitem uma recuperação segura, um projeto de reconstrução pode ser recomendado separadamente.
Sim. Para um atendimento de recuperação real, normalmente precisamos acessar a hospedagem. O wp-admin sozinho pode não ser suficiente, principalmente quando o próprio WordPress está indisponível.
Podemos fazer uma triagem, mas a recuperação pode ficar limitada. Se o problema estiver em PHP, arquivos, banco, permissões ou servidor, será necessário obter acesso junto à empresa de hospedagem ou responsável técnico.
Não. Nunca envie senhas no formulário de diagnóstico. Após a triagem, informamos quais credenciais são realmente necessárias e como compartilhá-las.
Erro 500 é um sintoma genérico. Muitos casos são simples, mas outros podem envolver servidor, banco ou código customizado. O diagnóstico determina a causa e a viabilidade da recuperação.
Ainda podemos investigar e tentar recuperar o ambiente atual. Porém, a ausência de backup aumenta risco e pode limitar as opções disponíveis, especialmente em corrupção de banco, invasão ou perda de arquivos.
Podemos atuar em diferentes provedores desde que o ambiente ofereça acesso e ferramentas suficientes para diagnóstico. Restrições do provedor podem limitar algumas intervenções.
Sim, como incidente de alta complexidade. A atuação pode incluir identificação e remoção de arquivos maliciosos, usuários suspeitos e vetores visíveis, além de recomendações de hardening. Nenhum ambiente conectado à internet pode receber promessa absoluta de invulnerabilidade.
Depende da causa. Um plugin quebrado pode ser resolvido rapidamente; banco corrompido ou malware exige investigação maior. A primeira hora serve justamente para transformar o sintoma em um diagnóstico técnico.
Sim. O trabalho técnico de diagnóstico é realizado mesmo quando a conclusão é que a recuperação não é segura ou economicamente adequada. Nesse caso, explicamos as alternativas antes de qualquer projeto adicional.
Somente quando isso fizer parte da solução segura para o incidente. Atualizar tudo indiscriminadamente durante uma falha pode criar novos conflitos. Primeiro estabilizamos; depois planejamos as atualizações necessárias.
Sim, mas migração é um escopo diferente da recuperação. Se a infraestrutura atual estiver contribuindo para o problema, podemos avaliar uma migração após estabilizar ou preservar o que for recuperável.
Não como escopo padrão. Rescue é recuperação e estabilização. Redesign, novas páginas, e-commerce, integrações e desenvolvimento evolutivo são tratados como projetos separados.
Você não precisa saber o nome técnico do problema. Informe o que está vendo, quando começou e o que mudou recentemente, se souber.
Não envie senhas neste formulário.
A RADIAL solicitará os acessos necessários somente após a triagem inicial.