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. It’s a threshold set by a WordPress.org API that runs on its own calendar. So don’t go hunting for a dropdown yet. Work out which of three messages you’re looking at first. Two of them mean different things, and the third never appears at all.
Resposta rápida: Change the PHP version in your hosting control panel, not in WordPress. WordPress cannot update PHP, and no plugin can either. Faça backup primeiro, update every plugin and theme, then switch to PHP 8.4 and reload your site. The dashboard notice clears itself on the next admin page load, because WordPress caches the check against your exact version string.
Última revisão: agosto 2026. Version thresholds queried live against the WordPress.org Serve Happy API, and the warning logic read from WordPress core on the same day.
Which Warning Are You Actually Seeing?
The box on your dashboard has a title, and that title is a diagnostic. Core picks between two of them, and which one you get tells you where your PHP version sits before you look anything up. Getting no box at all is the third answer.
- “PHP Update Required” means your PHP is below 8.0. Core hard-codes that line. Cobre 23.4% of all WordPress installs, most of them on PHP 7.4, which died on 28 novembro 2022.
- “PHP Update Recommended” means you’re on PHP 8.0 exatamente. That branch died in November 2023, so it gets no patches, but WordPress phrases it softly anyway.
- No box at all means you’re on PHP 8.1 ou mais alto. That includes PHP 8.1, which is end of life.
The body text under the title varies too. On PHP below 8.0 you get the full threat: “Your site is running on an outdated version of PHP, which does not receive security updates and soon will not be supported by WordPress. Ensure that PHP is updated on your server as soon as possible. Otherwise you will not be able to upgrade WordPress.” On PHP 8.0 the threat shortens to “which does not receive security updates. It should be updated.” The difference is the future minimum. Core carries a hard-coded check for anything below PHP 8.0, with a comment saying the supported minimum will rise to at least 8.0 mais tarde.
That last threat is already real for some people. WordPress 7.0, lançado 20 Maio 2026, dropped support for PHP 7.2 e 7.3 inteiramente. If you’re on either, you cannot install WordPress 7.0 ou o 7.1 release that followed on 19 agosto 2026. You’re frozen on 6.9 until the PHP version moves. Isso é 3% of installs, and they will not get another core feature release until somebody logs into a control panel.
Site Health tells a slightly different story from the dashboard box, and it’s the more accurate of the two. Vamos para Ferramentas > Saúde do Site. The Status tab grades your PHP as good, recomendado, ou crítico. The Info tab, under Server, prints the exact version string your web server runs. Trust that number over anything your host’s billing page says.
How This Guide Was Checked
Three sources decided what’s in here, ranked in a fixed order. Primeiro, the WordPress core source itself, read on 27 agosto 2026. That means the widget logic in wp-admin/includes/dashboard.php, the version check in wp-admin/includes/misc.php, and the Site Health test in class-wp-site-health.php. Every message quoted above is a literal string from those files, not a paraphrase of someone’s screenshot.
Segundo, the two WordPress.org APIs that drive the behaviour. o Serve Happy endpoint was queried with seven different version strings to find the exact points where its verdict flips. o public stats API supplied the version distribution. Every percentage below was calculated from that raw payload, not quoted from another guide.
Terceiro, php.net’s own support calendar for the end-of-life dates, e a core handbook’s compatibility table for which WordPress runs on which PHP.
Here’s what the guide is missing, so you can judge the rest. No load testing was run here, so the performance numbers below are attributed to the people who did run them. Control panel menu paths were checked against vendor documentation current in August 2026. Panels get redesigned, so treat those as a shape rather than a script. The stats API is a rolling sample of sites that phone home, not a census of every WordPress install on earth.
The Two Numbers Behind the Notice
WordPress doesn’t decide this locally. On a weekly cycle it asks api.wordpress.org one question: is this PHP version acceptable? 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, PHP did not actually change for that request, e a seção abaixo covers why.
There’s one more mechanism buried in core that’s worth knowing about. A filter called wp_is_php_version_acceptable lets a plugin or host tighten the check. Core’s own documentation is blunt about the limit: isto “can only make this check stricter, but not loosen it.” Tradução: your host can force this warning on, but nobody can switch it off through that hook. Hosts can also repoint the “Learn more about updating PHP” button at their own documentation, usando o WP_UPDATE_PHP_URL environment variable. That’s why the button sometimes lands on your provider’s knowledge base instead of WordPress.org.
The Warning You’ll Never See
Now the uncomfortable part. Ask the Serve Happy API about PHP 8.1 today and it answers is_secure: verdade. PHP 8.1 chegou ao fim da vida em 31 dezembro 2025 and has received no security patches since. 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. Files and database, downloaded somewhere off the server. 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, anything. 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. Its highest check target is PHP 8.0 and it was last tested against WordPress 6.4. That plugin has been downloaded more than three million times, and WordPress’s official fix instructions still send people to it. It cannot test for the version you’re moving to.
So what works instead? Para a maioria das pessoas, nothing beats a staging copy with the error log on. Switch PHP there, click through your key pages, and read the log. Comfortable on a command line? The maintained option is the PHPCompatibilityWP ruleset for PHP_CodeSniffer. Install it through Composer and run it with a target version flag. It’s the same engine the abandoned plugin used to wrap, minus the wrapper.
There’s also a quicker sanity pass that costs nothing. Sort your plugins by last update date on WordPress.org. Anything untouched since 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. To choose it yourself, mudar para “Change PHP Version Manually”, select a version, and confirm. On an Ultrafast PHP setup the change applies across the whole site including subdomains, which is convenient right up until it isn’t.
Hospedeiros WordPress gerenciados
Kinsta, Motor WP, Prensável, Cloudways and the rest expose PHP as a per-site setting in their own dashboard. Look under a Tools or Environment tab. These hosts also force-migrate customers off dead branches on a published deadline, rather than waiting for you. That’s one of the quieter reasons hospedagem gerenciada de WordPress costs what it does. Check your inbox before you go looking, since the change may already be scheduled.
Your own server
On a VPS or dedicated box there’s no dropdown. You install the new PHP-FPM package (the service that runs PHP for your web server). Then point the pool config at the new socket and restart both services. Watch one thing: php -v over SSH reports the CLI binary, which is often a different version from the one FPM serves your site with. The number in Site Health is the one that counts.
No panel at all, or one that doesn’t offer the version you want? Email support and ask. The official WordPress documentation even provides a template for it, which tells you how often hosts hear the question.
You Changed PHP and the Warning Is Still There
Then PHP didn’t change for the request that rendered that page. Remember the caching. WordPress keys its check on your exact version string, so a real version change forces a fresh lookup on the next admin load. A surviving warning is not a stale cache. It’s a wrong version.
Run through these, roughly in order of how often they’re the culprit:
- Wrong domain. Addon domains, subdomains and subfolder installs are configured separately in most panels. You changed the version on example.com and WordPress lives on loja.exemplo.com.
- Two PHP tools, um servidor. The CloudLinux Selector versus MultiPHP situation described above. Change it in the other one.
- An .htaccess handler line. An old AddHandler ou SetHandler directive in your root .htaccess can pin a specific PHP version and quietly override the panel. Search the file for “php” and comment out anything that names a version.
- You checked the CLI. Covered above, and it catches out experienced people more than beginners.
- It landed on staging. Worth a glance if you have staging enabled and switched contexts recently.
The tiebreaker is always Tools > Saúde do Site > Info > Servidor > Versão do PHP. That value is read at runtime, inside the same web request that draws the page. Nothing lies to it.
If the Site Breaks After the Switch
First move: put the PHP version back. 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 catches fatal errors from plugins and emails the admin address a recovery mode link. That link logs you into a dashboard with the offending plugin paused, which is usually enough to deactivate it and get moving. Check that inbox before you start editing files over FTP.
Once you know the guilty plugin, you have three options and they’re all fine. Update it, if an update exists. Replace it with something maintained. Or drop back a PHP version and give the developer a deadline. What you shouldn’t do is stay on dead PHP indefinitely because one plugin from 2021 refuses to move.
What Old PHP Costs You While You Wait
The security argument is the obvious one, so let’s skip past it to the mechanism most people don’t know about.
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. A plugin declaring a Requires PHP header above your version simply won’t activate. So an install fails with a message about PHP, and you go looking for a problem in the plugin that isn’t there.
Running a store makes this sharper. WooCommerce recommends PHP 8.3 ou melhor, and the payment and shipping extensions around it move faster than the core plugin does. A frozen payment gateway is a compliance problem as much as a technical one. É por isso Hospedagem WooCommerce pushes customers onto current PHP faster than general shared hosting does.
And the number that ties it together: 6% of WordPress installs are below PHP 7.4, so they cannot run WordPress 7.0 ou 7.1 de forma alguma. Não “shouldn’t”. Cannot. Core refuses. Every feature and every security fix in those releases stays out of reach until the PHP version moves. No amount of clicking Update in the dashboard changes that.
Can You Just Hide the Warning?
sim, and it’s a bad trade, but let’s be straight about how it’s done rather than pretend otherwise.
The dashboard box is an ordinary widget registered under the ID dashboard_php_nag. A single call to remove_meta_box(‘dashboard_php_nag’, ‘dashboard’, ‘normal’) hooked to wp_dashboard_setup removes it. Several small plugins do nothing but this.
What that doesn’t do is worth listing, because the warning is the least of what’s happening. Site Health still flags the version. Plugin updates requiring newer PHP are still blocked. Your PHP still receives no security patches. And you’ve removed the one visible reminder that any of it is true. That’s the actual cost. Seis meses depois, nobody remembers why the plugin list stopped moving.
One thing you cannot do is suppress it through core’s filter. o wp_is_php_version_acceptable hook only runs when the API has already said yes, and it can only tighten the verdict. If you’re looking for the “oficial” way to turn this off, não há um, and that’s deliberate.
Hide it if you’ve made an informed decision to stay put for a defined period. Put a date in your calendar. De outra forma, spend the ten minutes instead.
perguntas frequentes
Will updating PHP break my WordPress site?
Geralmente não, and when it does the cause is almost always an abandoned plugin rather than PHP itself. WordPress core has been fully compatible with PHP 8.4 since version 6.7, and with 8.5 Desde a 6.9. The risk sits in third-party code that hasn’t been updated in years. Update everything first, keep the error log on, and remember you can put the old version back in seconds.
Should I use PHP 8.4 ou PHP 8.5 para WordPress?
PHP 8.4 for most sites. It runs until 31 dezembro 2028 and has the broader plugin track record. PHP 8.5 runs a year longer, para 31 dezembro 2029, e WordPress 7.0 e 7.1 both support it fully. Escolher 8.5 if you can test on staging first and your plugin list is short and modern. Performance is not a factor either way, since benchmarks put the difference between the two inside the margin of error.
How do I check which PHP version my site is running?
Ferramentas > Saúde do Site > Info, expand the Server section, procurar “Versão do PHP”. That’s the runtime value from the actual web request. It beats your control panel, your billing page, and anything php -v reports over SSH. It takes about fifteen seconds and needs no plugin.
Can I update PHP myself or do I have to ask my host?
On cPanel, Plesk, hPanel and Site Tools you do it yourself from a dropdown. On managed WordPress platforms it’s a per-site setting in their dashboard. On a VPS you install the package and restart the service. Only on locked-down or older shared plans do you need to email support, and WordPress publishes template wording for exactly that request.
Why does the PHP update warning keep coming back?
Because your PHP version genuinely hasn’t changed. WordPress caches the check against your exact version string. Switching versions invalidates that cache on its own, and the notice clears on the next admin page load. If it’s still there, three things cause it. A subdomain configured separately from the main domain. A second PHP tool in your panel overriding the first. Or an AddHandler line in your .htaccess pinning the old version.
Do I need to update PHP if my site is working fine?
sim, e “working fine” is exactly how it looks right up until it doesn’t. Your PHP version stopped receiving security patches at a fixed date on a published calendar, e 39.2% of WordPress sites are past theirs. The practical cost arrives sooner than the security one. Plugin updates requiring newer PHP get blocked, so patches you assume are installing automatically are quietly queuing up instead.
How long does a PHP update take?
The switch itself is one dropdown and applies immediately, usually inside a second. The work around it is the real cost. Fifteen minutes for a backup and a full plugin update, another fifteen clicking through your key pages afterwards. On a straightforward site with maintained plugins, half an hour start to finish. On a site with a decade of accumulated plugins, budget an afternoon and test on a copy.
Conclusão
Open Site Health, read the real number, and compare it to the calendar rather than to your dashboard. If it’s 7.3 or lower, you’re locked out of WordPress 7.0 e 7.1 inteiramente, and that’s the urgent one. If it’s 7.4, you can still update WordPress, but you’ve been running unpatched PHP since November 2022. If it’s 8.0 ou 8.1, you’re getting no security patches either, e 8.1 doesn’t even warn you. If it’s 8.2, you have until 31 dezembro 2026 before you’re back here. Vamos para PHP 8.4 now and skip the repeat visit.
The whole job is a backup, a round of plugin updates, and one dropdown. It feels risky because the failure mode is loud and the reward is invisible. So it sits on the to-do list for years. The tell that it’s overdue: a plugin update you can see but cannot click.
Two related problems tend to surface right after this one. If the site still feels slow on current PHP, the bottleneck sits in front of the server. Nosso guia para fixing render-blocking resources in WordPress covers where it usually hides. Is your host stuck two PHP branches behind, with the newest version missing from the dropdown? That’s a hosting problem wearing a PHP costume. Nosso guia para choosing hosting for a WordPress website filters for providers that keep current branches available. The good ones migrate customers off dead branches on a published schedule.