Nesta página: [ocultar]
PHP 8.1 parou de receber patches de segurança em 31 dezembro 2025. WordPress ainda diz ao 11.6% dos sites que o executam que está tudo bem. Essa lacuna não é um bug que você pode relatar. É um limite definido por uma API do WordPress.org que é executada em seu próprio calendário. Portanto, não procure um menu suspenso ainda. Descubra qual das três mensagens você está vendo primeiro. Dois deles significam coisas diferentes, e o terceiro nunca aparece.
Resposta rápida: Altere a versão do PHP no painel de controle da sua hospedagem, não no WordPress. WordPress não pode atualizar o PHP, e nenhum plugin pode. Faça backup primeiro, atualize todos os plugins e temas, então mude para PHP 8.4 e recarregue seu site. O aviso do painel desaparece no próximo carregamento da página de administração, porque o WordPress armazena em cache a verificação em relação à string exata da sua versão.
Última revisão: agosto 2026. Limites de versão consultados ao vivo na API Serve Happy do WordPress.org, e a lógica de aviso lida no núcleo do WordPress no mesmo dia.
Which Warning Are You Actually Seeing?
A caixa em seu painel tem um título, e esse título é um diagnóstico. Escolhas principais entre dois deles, e qual deles você obtém informa onde está sua versão do PHP antes de você procurar qualquer coisa. Não conseguir nenhuma caixa é a terceira resposta.
- “Atualização do PHP necessária” significa que seu PHP está abaixo 8.0. O núcleo codifica essa linha. Cobre 23.4% de todas as instalações do WordPress, a maioria deles em PHP 7.4, que morreu em 28 novembro 2022.
- “Atualização PHP recomendada” significa que você está em PHP 8.0 exatamente. Esse ramo morreu em novembro 2023, então não recebe patches, mas o WordPress fala suavemente de qualquer maneira.
- Nenhuma caixa significa que você está em PHP 8.1 ou mais alto. Isso inclui PHP 8.1, que é o fim da vida.
O corpo do texto sob o título também varia. Em PHP abaixo 8.0 você recebe a ameaça completa: “Seu site está rodando em uma versão desatualizada do PHP, que não recebe atualizações de segurança e em breve não será compatível com WordPress. Certifique-se de que o PHP seja atualizado em seu servidor o mais rápido possível. Caso contrário, você não conseguirá atualizar o WordPress.” Existe PHP 8.0 a ameaça diminui para “que não recebe atualizações de segurança. Deve ser atualizado.” A diferença é o mínimo futuro. Core carrega uma verificação codificada para qualquer coisa abaixo do PHP 8.0, com um comentário dizendo que o mínimo suportado aumentará para pelo menos 8.0 mais tarde.
Essa última ameaça já é real para algumas pessoas. WordPress 7.0, lançado 20 Maio 2026, abandonou o suporte para PHP 7.2 e 7.3 inteiramente. Se você estiver em qualquer um, você não pode instalar o WordPress 7.0 ou o 7.1 lançamento que se seguiu 19 agosto 2026. Você está congelado 6.9 até que a versão do PHP seja movida. Isso é 3% de instalações, e eles não receberão outro lançamento de recurso principal até que alguém faça login em um painel de controle.
Site Health conta uma história um pouco diferente da caixa do painel, e é o mais preciso dos dois. Vamos para Ferramentas > Saúde do Site. A guia Status classifica seu PHP como bom, recomendado, ou crítico. A guia Informações, em Servidor, imprime a string de versão exata que seu servidor web executa. Confie nesse número acima de qualquer coisa que a página de faturamento do seu host diga.
How This Guide Was Checked
Três fontes decidiram o que há aqui, classificados em uma ordem fixa. Primeiro, a própria fonte principal do WordPress, continue lendo 27 agosto 2026. Isso significa que a lógica do widget em wp-admin/includes/dashboard.php, o check-in da versão wp-admin/includes/misc.php, e o teste de integridade do site em classe-wp-site-health.php. Cada mensagem citada acima é uma string literal desses arquivos, não é uma paráfrase da captura de tela de alguém.
Segundo, as duas APIs do WordPress.org que orientam o comportamento. o Servir endpoint feliz foi consultado com sete strings de versão diferentes para encontrar os pontos exatos onde seu veredicto muda. o API de estatísticas públicas forneceu a distribuição da versão. Cada porcentagem abaixo foi calculada a partir dessa carga bruta, não citado de outro guia.
Terceiro, Calendário de suporte próprio do php.net para as datas de fim de vida, e a tabela de compatibilidade do manual principal para qual WordPress é executado em qual PHP.
Aqui está o que está faltando no guia, então você pode julgar o resto. Nenhum teste de carga foi executado aqui, portanto, os números de desempenho abaixo são atribuídos às pessoas que os administraram. Os caminhos do menu do painel de controle foram verificados em relação à documentação do fornecedor atualizada em agosto 2026. Painéis são redesenhados, então trate isso como uma forma e não como um script. A API de estatísticas é uma amostra contínua de sites que ligam para casa, não é um censo de todas as instalações do WordPress no mundo.
The Two Numbers Behind the Notice
WordPress não decide isso localmente. Em um ciclo semanal, ele faz uma pergunta ao api.wordpress.org: esta versão do PHP é aceitável? The answer comes back with two numbers attached, and both matter.
Minimum version: 7.4. Below this, core refuses to install. It’s also the value hard-coded in wp-includes/version.php, so it isn’t going anywhere without a major release.
Recommended version: 8.3. This is the number quoted in the notice itself, in Site Health, and on the official documentation page. Bater 8.3 or higher and Site Health grades you green.
Here’s the part that matters for troubleshooting. WordPress caches that answer for seven days in a transient (a database entry with an expiry date). The storage key is built from your exact PHP version string. Change your PHP version and that key changes with it. A new key means no cached answer, so WordPress asks again on the next admin page load. So the warning is not sticky. If it survives a PHP change, Na verdade, o PHP não mudou para essa solicitação, e a seção abaixo cobre o porquê.
Há mais um mecanismo enterrado no núcleo que vale a pena conhecer. Um filtro chamado wp_is_php_version_acceptable permite que um plugin ou host restrinja a verificação. A própria documentação do Core é direta sobre o limite: isto “só podemos tornar esta verificação mais rigorosa, mas não afrouxe.” Tradução: seu host pode forçar este aviso, mas ninguém pode desligá-lo através desse gancho. Os anfitriões também podem reposicionar o “Saiba mais sobre como atualizar o PHP” botão em sua própria documentação, usando o WP_UPDATE_PHP_URL variável de ambiente. É por isso que o botão às vezes chega à base de conhecimento do seu provedor, em vez do WordPress.org.
The Warning You’ll Never See
Agora a parte desconfortável. Pergunte à API Serve Happy sobre PHP 8.1 hoje e responde é_seguro: verdade. PHP 8.1 chegou ao fim da vida em 31 dezembro 2025 e não recebeu nenhum patch de segurança desde. WordPress’s own API disagrees with php.net, and WordPress core believes the API.
Follow that through the code and the outcome is that PHP 8.1 sites get no dashboard box at all. Nenhum. Site Health downgrades them to an orange “recomendado” instead of a red “crítico”. The label reads “Your site is running on an older version of PHP, which should be updated.” Meanwhile PHP 8.0, which died two years earlier, does trigger a box. The site in more danger gets the quieter warning.
Scale that against the distribution and the picture gets worse. Adding up every branch that receives no security patches at all, 39.2% of WordPress sites are running dead PHP right now. Somente 11.1% are on a branch still in active support. Roughly half the WordPress web sits on PHP 8.2 ou 8.3. Those two get security fixes but no bug fixes, e 8.2 loses even that on 31 dezembro 2026.
So the honest version of the advice is this: the absence of a warning proves nothing. Check the actual number in Site Health against the calendar, not against your dashboard.
Which PHP Version Should You Move To?
WordPress says 8.3. WordPress is being conservative, and on this one you can safely ignore it. Here’s how the four live branches stand as of August 2026.
- PHP 8.2 gets security fixes until 31 dezembro 2026. That’s four months of runway. Pick it and you’re doing this again over New Year.
- PHP 8.3 left active support on 31 dezembro 2025 and gets security fixes until 31 dezembro 2027. It’s WordPress’s recommended version and it’s already past its bug-fix window.
- PHP 8.4 is in active support until 31 dezembro 2026, with security fixes through 31 dezembro 2028. It shipped 21 novembro 2024, so plugin authors have had 21 months to catch up with it.
- PHP 8.5 shipped 20 novembro 2025 and runs until 31 dezembro 2029. WordPress 6.9 added support for it, e 7.0 e 7.1 are both fully compatible.
Vamos para PHP 8.4. It buys you nearly two and a half years, and it’s the version most plugin authors have actually tested against. If a dependency does break, you’re on well-trodden ground where somebody has already written down the fix. PHP 8.5 is the right call for a small, modern stack you control end to end. You’ll want somewhere to test it first.
Don’t do this for speed. Tideways benchmarked WordPress 6.8.3 on an 8-core AMD server, with JIT (PHP’s just-in-time compiler) switched off. Response times between PHP 8.4 e 8.5 showed no meaningful change. Variation across 8.2 para 8.5 fell inside the margin of error. Under concurrency, only PHP 7.4 lagged, and by around 5% on requests per second. That’s what they measured. What follows from it is that moving 8.2 para 8.5 is a security and compatibility decision, not a performance one. Anyone selling you a 3x speed-up from a version bump is quoting synthetic loops, not a real site.
One curiosity from the stats, since it comes up: 0.011% of WordPress sites report PHP 8.6. That branch doesn’t exist yet. It hit beta on 13 agosto 2026 and ships 19 novembro 2026. Somebody is running WordPress on a pre-release PHP build, and it isn’t you, and it shouldn’t be.
Before You Touch the Dropdown
Four things, em ordem. Skipping the first two is how a five-minute job becomes an evening.
Take a real backup. Arquivos e banco de dados, baixado em algum lugar fora do servidor. A restore point inside the same hosting account is useless if the account is what breaks.
Update everything first. painel de controle > Atualizações, then core, então plugins, then themes. Load the front end and the admin afterwards and confirm nothing shifted. Most PHP upgrade failures are not really PHP failures. They’re a plugin three years behind that was already broken and nobody noticed.
Turn on the error log. Adicionar definir("WP_DEBUG", verdade); e definir("WP_DEBUG_LOG", verdade); to your wp-config.php file, com WP_DEBUG_DISPLAY set to false so visitors see nothing. Errors land in wp-content/debug.log. Set this up before the switch and you’ll have the answer waiting for you instead of a blank screen.
Test on a copy. Estadiamento, um subdomínio, a local install, qualquer coisa. If your host offers one-click staging, this is what it’s for.
Now the compatibility check, which is where the standard advice falls apart. WordPress’s own documentation page, the one the dashboard button links to, tells you at step three to install the PHP Compatibility Checker plugin. Open that plugin’s page and the first line of its own description reads: “WARNING: PHP Compatibility Checker is no longer actively maintained.” It goes on to say no further releases will be made, including security releases. Seu alvo de verificação mais alto é PHP 8.0 e foi testado pela última vez no WordPress 6.4. Esse plugin foi baixado mais de três milhões de vezes, e as instruções oficiais de correção do WordPress ainda direcionam as pessoas para ele. Ele não pode testar a versão para a qual você está migrando.
Então, o que funciona em vez disso? Para a maioria das pessoas, nada se compara a uma cópia temporária com o log de erros. Mude o PHP para lá, clique em suas páginas principais, e leia o registro. Confortável em uma linha de comando? A opção mantida é o conjunto de regras PHPCompatibilityWP para PHP_CodeSniffer. Instale-o através do Composer e execute-o com um sinalizador de versão de destino. É o mesmo mecanismo que o plugin abandonado usou para empacotar, menos o invólucro.
Há também um passe de sanidade mais rápido que não custa nada. Classifique seus plug-ins pela data da última atualização no WordPress.org. Qualquer coisa intocada desde 2023 is the thing that will break (and you probably already know which one it is). No scanner needed.
How to Change the PHP Version on Your Host
PHP lives on the server, so this happens in your hosting panel. WordPress has no control over it, and any plugin claiming otherwise is lying to you.
cPanel: MultiPHP Manager
Under Software, abrir MultiPHP Manager. Tick the domain you want, choose a version from the PHP Version dropdown, click Apply. It takes effect immediately. You can tick several domains and change them together. This tool handles the ea-php packages that cPanel itself ships.
cPanel: Selecione a versão do PHP
There’s a second tool in the same panel, and it trips people up constantly. If your host runs CloudLinux you’ll also see Selecione a versão do PHP under Software. That’s the CloudLinux PHP Selector. It manages alt-php packages and applies at the account level. Where both exist, the Selector is the one that wins for your account. A related gotcha: settings you change in MultiPHP INI Editor have no effect on an alt-php version. You have to edit those inside Select PHP Version instead.
Which should you use? Whichever one your host actually configured. If changing MultiPHP does nothing, check Select PHP Version, e vice-versa.
Plesk
Vamos para Websites & Domínios, click the domain, então PHP Settings. Pick your version from the dropdown at the top and click Apply. Older Plesk builds label the same screen “Versão PHP”.
Hostinger hPanel
From the Hosting section, hit Manage next to your domain, então Avançado > PHP Configuration in the sidebar. Choose the version and click Update. Subdomains and subfolders are configured separately here. A site living in a subfolder can still be on the old version after you’ve changed the main domain.
SiteGround Site Tools
Abrir Devs > Gerenciador PHP and click the pencil icon. New sites default to Managed PHP, where SiteGround picks the version for you. Para escolher você mesmo, mudar para “Alterar a versão do PHP manualmente”, selecione uma versão, e confirme. Em uma configuração PHP Ultrafast, a mudança se aplica a todo o site, incluindo subdomínios, o que é conveniente até que não seja.
Hospedeiros WordPress gerenciados
Kinsta, Motor WP, Prensável, Cloudways e o resto expõem o PHP como uma configuração por site em seu próprio painel. Procure na guia Ferramentas ou Ambiente. Esses hosts também forçam a migração de clientes de filiais mortas em um prazo publicado, em vez de esperar por você. Essa é uma das razões mais silenciosas hospedagem gerenciada de WordPress custa o que custa. Verifique sua caixa de entrada antes de procurar, já que a mudança pode já estar agendada.
Your own server
Em um VPS ou caixa dedicada não há menu suspenso. Você instala o novo pacote PHP-FPM (o serviço que executa PHP para o seu servidor web). Em seguida, aponte a configuração do pool para o novo soquete e reinicie os dois serviços. Observe uma coisa: php -v sobre SSH relata o binário CLI, que geralmente é uma versão diferente daquela com a qual o FPM atende seu site. O número no Site Health é o que conta.
Nenhum painel, ou um que não oferece a versão que você deseja? Suporte por e-mail e pergunte. A documentação oficial do WordPress ainda fornece um modelo para isso, que informa com que frequência os hosts ouvem a pergunta.
You Changed PHP and the Warning Is Still There
Então o PHP não mudou para a solicitação que renderizou aquela página. Lembre-se do cache. O WordPress verifica a string exata da sua versão, portanto, uma mudança de versão real força uma nova pesquisa no próximo carregamento do administrador. Um aviso sobrevivente não é um cache obsoleto. É uma versão errada.
Percorra estes, aproximadamente na ordem de quantas vezes eles são os culpados:
- Domínio errado. Domínios adicionais, subdomínios e instalações de subpastas são configurados separadamente na maioria dos painéis. Você alterou a versão em example.com e o WordPress continua vivo loja.exemplo.com.
- Duas ferramentas PHP, um servidor. A situação CloudLinux Selector versus MultiPHP descrita acima. Troque no outro.
- Uma linha de manipulador .htaccess. Um velho AdicionarHandler ou SetHandler diretiva em seu root .htaccess pode fixar uma versão específica do PHP e substituir silenciosamente o painel. Pesquise o arquivo por “php” e comente qualquer coisa que nomeie uma versão.
- Você verificou a CLI. Coberto acima, e atrai mais pessoas experientes do que iniciantes.
- Chegou ao palco. Vale a pena dar uma olhada se você ativou o teste e mudou de contexto recentemente.
O desempate é sempre Ferramentas > Saúde do Site > Informações > Servidor > Versão do PHP. Esse valor é lido em tempo de execução, dentro da mesma solicitação da web que desenha a página. Nada mente para isso.
If the Site Breaks After the Switch
Primeiro movimento: coloque a versão do PHP de volta. It’s the same dropdown, it takes ten seconds, and the site returns. Diagnose afterwards, with the pressure off. That reversibility is why a PHP change is safe to attempt on a live site. A database migration, dizer, is not.
Then read the log rather than guessing. Abrir wp-content/debug.log and look at what PHP actually said, because the three things it says are not equally serious:
- Deprecated is noise. The most common one on PHP 8.4 é “Implicitly marking parameter as nullable is deprecated”. It has hit Loco Translate, Cookiebot, MailPoet and WooCommerce PayPal Payments, entre outros. It fills your log. It does not break your site.
- Aviso means something went wrong and execution continued. Sometimes visible, sometimes not.
- Erro fatal is the one that white-screens you. The log names the file and the line, and the file path tells you which plugin or theme to blame.
Desde WordPress 5.2, core detecta erros fatais de plug-ins e envia por e-mail ao endereço do administrador um link do modo de recuperação. Esse link conecta você a um painel com o plug-in incorreto pausado, o que geralmente é suficiente para desativá-lo e seguir em frente. Verifique essa caixa de entrada antes de começar a editar arquivos por FTP.
Depois de conhecer o plugin culpado, você tem três opções e todas estão bem. Atualize-o, se existir uma atualização. Substitua-o por algo mantido. Ou recue uma versão PHP e dê um prazo ao desenvolvedor. O que você não deve fazer é ficar com o PHP morto indefinidamente porque um plugin do 2021 se recusa a se mover.
What Old PHP Costs You While You Wait
O argumento da segurança é o óbvio, então vamos pular para o mecanismo que a maioria das pessoas não conhece.
WordPress will not install a plugin update that requires a newer PHP than you’re running. Instead it prints this, verbatim from core: “There is a new version of X available, but it does not work with your version of PHP.” The update sits there, visible, unclickable. Automatic updates skip it silently too: core’s updater checks the plugin’s required PHP against yours and quietly declines. So a plugin ships a security patch, you have automatic updates switched on, you assume you’re covered, and you’re not. Old PHP doesn’t just expose you through PHP itself. It quietly freezes your plugins at whatever version last supported you, and each frozen plugin accumulates its own unpatched holes.
Plugin activation works the same way. Um plugin que declara um cabeçalho Requires PHP acima da sua versão simplesmente não será ativado. Portanto, uma instalação falha com uma mensagem sobre PHP, e você vai procurar um problema no plugin que não existe.
Administrar uma loja torna isso mais nítido. WooCommerce recomenda PHP 8.3 ou melhor, e as extensões de pagamento e envio em torno dele se movem mais rápido do que o plugin principal. Um gateway de pagamento congelado é um problema de conformidade tanto quanto técnico. É por isso Hospedagem WooCommerce empurra os clientes para o PHP atual mais rápido do que a hospedagem compartilhada geral.
E o número que une tudo: 6% das instalações do WordPress estão abaixo do PHP 7.4, então eles não podem executar o WordPress 7.0 ou 7.1 de forma alguma. Não “não deveria”. Não pode. Núcleo recusa. Cada recurso e cada correção de segurança nessas versões permanecem fora de alcance até que a versão do PHP seja movida. Nenhuma quantidade de cliques em Atualizar no painel muda isso.
Can You Just Hide the Warning?
sim, e é um mau negócio, mas vamos ser francos sobre como isso é feito, em vez de fingir o contrário.
A caixa do painel é um widget comum registrado sob o ID dashboard_php_nag. Uma única chamada para remove_meta_box(‘painel_php_nag’, 'painel', 'normal') viciado em wp_dashboard_setup remove. Vários pequenos plugins não fazem nada além disso.
O que isso não faz vale a pena listar, porque o aviso é o mínimo do que está acontecendo. Site Health ainda sinaliza a versão. As atualizações de plug-ins que exigem PHP mais recente ainda estão bloqueadas. Seu PHP ainda não recebe patches de segurança. E você removeu o único lembrete visível de que tudo isso é verdade. Esse é o custo real. Seis meses depois, ninguém se lembra por que a lista de plugins parou de se mover.
Uma coisa que você não pode fazer é suprimi-lo através do filtro do núcleo. o wp_is_php_version_acceptable hook só é executado quando a API já disse sim, e isso só pode reforçar o veredicto. Se você está procurando o “oficial” maneira de desligar isso, não há um, e isso é deliberado.
Oculte se você tomou uma decisão informada de permanecer parado por um período definido. Coloque uma data no seu calendário. De outra forma, gaste os dez minutos em vez disso.
perguntas frequentes
Will updating PHP break my WordPress site?
Geralmente não, e quando isso acontece, a causa quase sempre é um plugin abandonado, em vez do próprio PHP. O núcleo do WordPress é totalmente compatível com PHP 8.4 desde a versão 6.7, e com 8.5 Desde a 6.9. O risco está no código de terceiros que não é atualizado há anos. Update everything first, mantenha o log de erros conectado, e lembre-se que você pode restaurar a versão antiga em segundos.
Should I use PHP 8.4 ou PHP 8.5 para WordPress?
PHP 8.4 para a maioria dos sites. Funciona até 31 dezembro 2028 e tem um histórico mais amplo de plugins. PHP 8.5 dura mais um ano, para 31 dezembro 2029, e WordPress 7.0 e 7.1 ambos o apoiam totalmente. Escolher 8.5 se você puder testar primeiro o teste e sua lista de plugins for curta e moderna. O desempenho não é um fator de qualquer maneira, já que os benchmarks colocam a diferença entre os dois dentro da margem de erro.
How do I check which PHP version my site is running?
Ferramentas > Saúde do Site > Informações, expanda a seção Servidor, procurar “Versão do PHP”. Esse é o valor do tempo de execução da solicitação da web real. É melhor que o seu painel de controle, sua página de faturamento, e qualquer coisa php -v relatórios por SSH. Demora cerca de quinze segundos e não precisa de plugin.
Can I update PHP myself or do I have to ask my host?
No cPanel, Plesk, hPanel e Site Tools você mesmo faz isso em um menu suspenso. Em plataformas WordPress gerenciadas, é uma configuração por site em seu painel. Em um VPS você instala o pacote e reinicia o serviço. Somente em planos bloqueados ou compartilhados mais antigos você precisa enviar um e-mail para o suporte, e o WordPress publica o texto do modelo exatamente para essa solicitação.
Why does the PHP update warning keep coming back?
Porque a sua versão do PHP realmente não mudou. O WordPress armazena em cache a verificação em relação à string exata da sua versão. A troca de versões invalida esse cache por si só, e o aviso desaparece no próximo carregamento da página de administração. Se ainda estiver lá, três coisas causam isso. Um subdomínio configurado separadamente do domínio principal. Uma segunda ferramenta PHP em seu painel substituindo a primeira. Ou uma linha AddHandler em seu .htaccess fixando a versão antiga.
Preciso atualizar o PHP se meu site estiver funcionando bem?
sim, e “funcionando bem” é exatamente como parece até que não. Sua versão do PHP parou de receber patches de segurança em uma data fixa em um calendário publicado, e 39.2% dos sites WordPress já passaram dos seus. O custo prático chega mais cedo que o de segurança. Atualizações de plug-ins que exigem PHP mais recente são bloqueadas, então os patches que você supõe que estão sendo instalados automaticamente estão silenciosamente na fila.
Quanto tempo leva uma atualização do PHP?
A opção em si é uma lista suspensa e se aplica imediatamente, geralmente dentro de um segundo. A solução é o custo real. Quinze minutos para um backup e uma atualização completa do plugin, mais quinze cliques em suas páginas principais depois. Em um site simples com plug-ins mantidos, meia hora do início ao fim. Em um site com uma década de plugins acumulados, orçamento de uma tarde e teste em uma cópia.
Conclusão
Abra a integridade do site, leia o número real, e compare-o com o calendário e não com o seu painel. Se for 7.3 ou inferior, você está bloqueado no WordPress 7.0 e 7.1 inteiramente, e esse é o urgente. Se for 7.4, você ainda pode atualizar o WordPress, mas você está executando PHP sem patch desde novembro 2022. Se for 8.0 ou 8.1, você também não está recebendo patches de segurança, e 8.1 nem te avisa. Se for 8.2, você tem até 31 dezembro 2026 antes de você voltar aqui. Vamos para PHP 8.4 agora e pule a visita repetida.
Todo o trabalho é um backup, uma rodada de atualizações de plugins, e um menu suspenso. Parece arriscado porque o modo de falha é alto e a recompensa é invisível. Portanto, fica na lista de tarefas há anos. O aviso de que está atrasado: uma atualização de plugin que você pode ver, mas não pode clicar.
Dois problemas relacionados tendem a surgir logo após este. Se o site ainda parecer lento no PHP atual, o gargalo fica na frente do servidor. Nosso guia para corrigindo recursos de bloqueio de renderização no WordPress cobre onde normalmente se esconde. O seu host está preso em dois ramos PHP atrás?, com a versão mais recente faltando no menu suspenso? Isso é um problema de hospedagem usando uma fantasia de PHP. Nosso guia para escolhendo hospedagem para um site WordPress filtros para provedores que mantêm agências atuais disponíveis. Os bons migram clientes de filiais mortas de acordo com uma programação publicada.