# What to do when a WordPress or PHP version reaches end of support > PHP 7.4 hasn’t received any security patch since late November 2022. That doesn’t mean a site still running on it stops working overnight, but that any flaw found since then will never get fixed by the maintainers. The risk grows over time, silently, with no visible alert. - Source canonique : [https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/fin-de-support-version](https://allaux.fr/en/wordpress-woocommerce/mise-a-jour/fin-de-support-version) - Langue : EN - Dernière mise à jour : 2026-09-30 ## Direct answer > Open Tools, Site Health: the Info tab gives the exact PHP, MySQL and WordPress core versions, and the Status tab flags a PHP version that no longer receives fixes. Write those three numbers down, then compare them with the end-of-support dates published by php.net and by WordPress. Nothing stops working on the end-of-life date: what sets the priority is how long you sit there before the next vulnerability. ## What "end of support" actually means A PHP or WordPress version reaching end of life keeps working exactly as before: the code runs, pages render, orders go through. Nothing visibly changes on the day support stops. What changes is that from that date, the maintainer stops publishing security patches for that version. Any vulnerability found afterwards stays open indefinitely on installations that haven’t migrated. PHP 7.4 illustrates this well: no security patch has been published for that version since late November 2022. WordPress technically still runs on PHP 7.4, but WordPress.org’s official recommendation is PHP 8.3 or higher. WordPress core itself remains usable beyond the minimum technically supported version, but staying on an old version deprives the site of the security fixes published for more recent ones. The danger of this situation lies precisely in its lack of signal. An end-of-life site doesn’t crash, doesn’t show a warning, doesn’t slow down. It keeps working until the day an unpatched flaw gets exploited, at which point the cost of intervention is nowhere near that of a migration planned ahead of time. ## How to spot an approaching or already-passed end of life - PHP version shown in the admin or by the host lower than the version WordPress.org recommends - Plugins or themes flagging incompatibility with recent PHP versions in their documentation - A host notice announcing the end of availability of a PHP version on its infrastructure - No recent security update on a WordPress or PHP version still in place - No visible incident so far, which is exactly the sign that no check has taken place yet ## Planning a move without waiting for an incident 1. **Audit the version actually in use** — I check the PHP version genuinely active at the host, not the one stated in general documentation: the two can diverge, particularly on older shared hosting. 2. **List what blocks a version upgrade** — I list plugins and the theme whose compatibility with a more recent PHP version isn’t confirmed, to know what needs updating or replacing before migrating. 3. **Plan a test window** — I test the version upgrade on a clone of the site before any production switch, with enough margin to fix what breaks without deadline pressure. 4. **Schedule the migration before it’s urgent** — I set a switch date outside any outage constraint, rather than waiting for a security incident or a host-side cutoff to force a rushed migration. 5. **Switch over and monitor** — The actual switch to the new version is the moment to watch closely: once the site is live on the new PHP version, reverting to the old one requires a full intervention rather than a simple setting change. ## End of life isn’t synonymous with immediate failure > A site on PHP 7.4 keeps working today. The risk isn’t a sudden stop but the lack of a fix for any flaw found after November 2022, a risk that builds up silently as long as nothing is done. ## Related pages - **Updating PHP under WordPress** — The technical detail of the version upgrade: deprecated functions, incompatible plugins, testing method before switching. ([/wordpress-woocommerce/mise-a-jour/php-wordpress](/wordpress-woocommerce/mise-a-jour/php-wordpress)) - **Checking plugin compatibility before an update** — How to know what blocks the migration before starting. ([/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour](/wordpress-woocommerce/mise-a-jour/verifier-extensions-avant-mise-a-jour)) - **Duplicating a WordPress site into staging** — The method for testing a PHP version upgrade on a copy before production. ([/wordpress-woocommerce/migration/dupliquer-en-preproduction](/wordpress-woocommerce/migration/dupliquer-en-preproduction)) - **Choosing e-commerce hosting** — What sets apart a host that keeps its PHP versions current from one that doesn’t. ([/guides/choisir-hebergement-ecommerce](/guides/choisir-hebergement-ecommerce)) ## FAQ ### My site still runs on PHP 7.4 and works fine, do I really need to migrate? Yes, even if nothing breaks today. Since late November 2022, no flaw found on PHP 7.4 gets fixed. Current functioning says nothing about the accumulated security risk. ### Which PHP version does WordPress recommend today? WordPress.org officially recommends PHP 8.3 or higher, even though WordPress core technically remains compatible with older versions. ### How do I know if my host already offers a recent PHP version? I check the active version in the hosting control panel or via a WordPress diagnostic plugin, rather than trusting the general documentation for the plan subscribed to, which can differ from the version actually provisioned. ### Should I wait for a plugin to flag an incompatibility before acting? No, that’s exactly the opposite of the goal: waiting for the incident means losing the room to manoeuvre that planning ahead provides. The audit happens before the problem arises. ### Does WordPress itself reach end of life the same way PHP does? The principle is similar: beyond a certain version, security patches stop. The difference is that WordPress publishes security updates on older major branches for longer than PHP does on its outdated versions, which doesn’t remove the need to plan a regular version upgrade.