Tag: php

Gemini: WordPress 7.4 EOL (End of Life) Situation Question

In this post, we explore why WordPress waited until July 2025 to notify website administrators via Site Health that PHP 7.4 was outdated, long after its November 2022 end-of-life. We asked Gemini AI to explain this delay and why WordPress skipped recommending PHP 8.0, 8.1, and 8.2, instead jumping directly to PHP 8.4. Gemini highlighted several key factors, including PHP’s official support cycle, WordPress’s cautious focus on broad theme and plugin compatibility, and evolving hosting provider standards. Ultimately, recommending a later version like PHP 8.4 provides users with optimal long-term stability, performance, and security while avoiding multiple tedious intermediate upgrades.

Gemini on WordPress 7.4 EOL

WordPress waited until July 2025 to begin notifying website admins via the Site Health notifications that PHP 7.4 needed updating. I asked Gemini if it knew why this started since PHP 7.4 had been past end of life for quite some time at that point.
See also my query with ChatGPT and with Grok on this question.
Can you find find out why WordPress only started site health notifications that PHP 7.4 was outdated in July 2025? I am curious why WordPress never notified for users to move to 8.0, 8.1, or 8.2 – but just started indicating PHP 8.4 as acceptable.
Gemini AI LogoThe reason WordPress only started showing Site Health notifications that PHP 7.4 was outdated in July 2025 is primarily due to a combination of:

  • PHP’s official support cycle: PHP 7.4 officially reached its End-of-Life (EOL) for security support in November 2022. Running it in 2025 puts sites at significant, unpatched security risk.
  • WordPress’s focus on broad compatibility: WordPress core historically moves cautiously to ensure a vast ecosystem of themes and plugins remains compatible with newer PHP versions. Delaying the mandatory notification gave developers and users more time to prepare for the jump to PHP 8+.
  • Hosting provider changes: Many hosting providers have been removing PHP 7.4 as an option or automatically upgrading users, leading to an increasing push from the WordPress community to get the remaining stragglers off the outdated version.

Why Notifications Skipped PHP 8.0, 8.1, and 8.2

WordPress’s Site Health and official recommendations skipped directly to promoting a high PHP 8.x version, with PHP 8.4 being indicated as acceptable (or sometimes even recommending 8.3 or higher as the ideal version, depending on the current date), for the following reasons:

1. Phased and Delayed Core Compatibility

While PHP 8.0, 8.1, and 8.2 were released, WordPress core often took time to fully resolve all compatibility issues, which were sometimes labeled as “beta support” or “compatible with exceptions.”

  • PHP 8.0 and 8.1: Full support was only retroactively declared in WordPress 6.3 (released August 2023) and later versions, after significant work was done to resolve known issues.
  • PHP 8.2: Full support came even later, with WordPress 6.6 (released mid-2024).

Because full compatibility with 8.x was achieved gradually, and to provide maximum encouragement for users to move to the fastest and most secure supported version, WordPress tends to promote the newest stable version that has achieved “full support” status.

2. Targeting the Long-Term Stable Version

WordPress prefers to recommend versions that offer long-term stability, performance, and security.

  • By the time WordPress fully ironed out compatibility for an earlier PHP 8.x version (like 8.0 or 8.1), a more performant and current version (like 8.3 or 8.4) was already available and rapidly approaching stability.
  • The recommended version is often two to three versions ahead of the minimum supported version (which is PHP 7.2.24+ as a legacy environment minimum), encouraging users to jump straight to a version that will be supported for the longest time by the PHP development team, minimizing the need for another immediate update.

3. Avoiding Intermediate Upgrade Cycles

Each PHP version update, particularly the jump from PHP 7.4 to any PHP 8.x version, often introduces breaking changes that require plugins and themes to be updated.

  • By encouraging a jump directly from the severely outdated 7.4 to a newer version like 8.4, WordPress minimizes the number of separate major PHP upgrades (e.g., 7.4 to 8.0, then 8.0 to 8.2, then 8.2 to 8.4) that users and developers would have to manage, focusing on one major, necessary security and performance leap.

In short, WordPress usually delays issuing strong warnings until a version is completely past its security EOL, and when it finally pushes for an update, it recommends the most stable, fully compatible, and current version to future-proof the site. The current recommended version is often PHP 8.3 or greater, with 8.4 being indicated as acceptable or next-in-line for full stability.

Note: I made an article on this topic at https://charlesworks.com/new-php-7-4-notices-in-wordpress/ for those looking for more info about it.

ChatGPT: WordPress 7.4 EOL (End of Life) Situation Question

WordPress began warning administrators in July 2025 that PHP 7.4 was outdated, even though PHP 7.4 reached end of life in November 2022. This article examines why WordPress waited so long and then recommended a much newer PHP version instead of guiding users through PHP 8.0, 8.1, or 8.2. The likely explanation involves WordPress’s cautious approach to compatibility across millions of websites, themes, plugins, and hosting environments. By waiting until newer PHP releases gained broader support, WordPress reduced the risk of broken sites while encouraging administrators to move directly toward better security, performance, stability, and longer-term support for the future.

ChatGPT on WordPress 7.4 EOL

WordPress waited until July 2025 to begin notifying website admins via the Site Health notifications that PHP 7.4 needed updating. I asked Gemini if it knew why this started since PHP 7.4 had been past end of life for quite some time at that point.
See also my query with Gemini and with Grok on this question.

Can you find find out why WordPress only started site health notifications that PHP 7.4 was outdated in July 2025? I am curious why WordPress never notified for users to move to 8.0, 8.1, or 8.2 – but just started indicating PHP 8.4 as acceptable.

I could not find any definitive, official WordPress core announcement stating exactly why they only began showing “PHP 7.4 is outdated” warnings in July 2025 (rather than earlier). But I found several clues and plausible reasoning based on WordPress’s development practices, Site Health tool history, and version adoption thresholds. You can use these ideas in your article (with caveats) unless/until WordPress publishes a clear “why.”

Clues & Context

  1. “PHP 8 Support Clarification” post in WordPress Core
    In April 2025, WordPress published a post titled “PHP 8 support clarification” that mentions usage of PHP 8.3 or higher is at 8.9% (as of that time). Make WordPress
    That post suggests WordPress tracks adoption thresholds before making big changes in how strongly they “endorse” or require new versions.

  2. WordPress’s official “Requirements” page now recommends PHP 8.3 or greater
    On WordPress.org’s Requirements page, “PHP version 8.3 or greater” is now listed as recommended. WordPress.org
    That indicates WordPress is evolving its baseline expectations, not just the absolute minimum.

  3. Site Health tool’s evolution and “minimum version bump” mechanism
    The Site Health system was designed to allow WordPress to raise the minimum version required (or recommended) gradually, and to warn users when their version is beneath that threshold. WordPress Consultant: Judith Kallos
    In practice, WordPress has been cautious about “pushing” newer PHP versions until a critical mass of sites and plugins support them reliably.

  4. Backward compatibility, plugin ecosystem, and risk tolerance
    WordPress must balance pushing forward with ensuring that a large ecosystem of themes, plugins, and custom code don’t break in mass. The warning for PHP 7.4 may reflect that WordPress has judged 8.3 (or a close successor) is now stable enough in the ecosystem to elevate the recommendation.

  5. Historic proposals for a schedule of version drops
    In 2020, there was a proposal in WordPress core to adopt a fixed schedule for dropping old PHP versions over time. Make WordPress That suggests the architecture is already contemplating version deprecation in planned phases rather than abrupt jumps.

Hypothesis: Why only 7.4 got the warning now

Putting the pieces together, here’s a plausible narrative:

  • WordPress (and the larger WP community) has been waiting until a certain adoption threshold of PHP 8.x to be met before raising a more visible alert.

  • Once PHP 8.3 reached a sufficient share of active sites (or once compatibility edge cases were resolved), WordPress felt confident in shifting the recommended version upward and warning older versions more assertively.

  • Because PHP 7.4 had already been EOL (end-of-life) for a while, it was a natural candidate for the “first to warn” as the lowest unsupported version still widely in use.

  • Upgrading minimum recommended versions too aggressively risks breaking a lot of sites, so WordPress likely delayed until the plugin/theme ecosystem had matured around newer PHP versions.

Thus, WordPress may have delayed showing a hard “your version is outdated” banner until the risk of disruption was lower and the community was more prepared.

If you like, I can dig further (especially through WordPress Trac, core tickets, or commit logs) and see if there is a commit or ticket that triggers the July 2025 activation of that warning. Do you want me to do that?

Note: I made an article on this topic at https://charlesworks.com/new-php-7-4-notices-in-wordpress/ for those looking for more info about it.

Grok: WordPress 7.4 EOL (End of Life) Situation Question

Recently, a notice started appearing in WordPress dashboards indicating that PHP version 7.4 was EOL and needed updating to version 8.3. That seemed quite a jump. WordPress’s Site Health tool monitors PHP versions and displays warnings when a version reaches end-of-life. By mid-2025, PHP 7.4 had been EOL for nearly three years. The warning escalated to critical with WordPress 6.8’s release in July 2025, once the ecosystem had matured and over 90% of plugins/themes were PHP 8.x-compatible. WordPress avoids version-specific nudges, instead urging upgrades to the latest supported PHP for security and performance.

WordPress PHP 7.4 EOL

Recently, a notice started appearing in WordPress dashboards. It indicated that the PHP version 7.4 was EOL (end of life) out of date and needed to be updated to version 8.3. That seemed quite a jump. I was surprised that WordPress never recommended updating to 8.0. So that led me to chat with Grok using the following prompt:

Can you find find out why WordPress only started site health notifications that PHP 7.4 was outdated in July 2025? I am curious why WordPress never notified for users to move to 8.0, 8.1, or 8.2 – but just started indicating PHP 8.4 as acceptable.

Grok AI logoUnderstanding WordPress Site Health and PHP Version Notifications

WordPress’s Site Health tool (introduced in version 5.2 in 2019) monitors your site’s configuration, including the PHP version, and displays critical or recommended warnings based on security, performance, and compatibility factors. These notifications are triggered when a PHP version reaches or approaches its end-of-life (EOL)—the point where the PHP project stops providing security updates or bug fixes, leaving sites vulnerable. WordPress doesn’t “recommend” specific versions like 8.0 or 8.1 explicitly in notifications; instead, it broadly urges upgrades to the latest supported versions (typically PHP 8.x or higher) to stay secure and performant. The tool evolves over time via core updates, aligning with PHP’s annual release cycle (new major versions in November) and WordPress’s biannual releases.

Your question highlights two key curiosities: (1) why the PHP 7.4 “outdated” warning appeared specifically in July 2025, and (2) why no targeted notifications pushed users from 7.4 to intermediate PHP 8.x versions (8.0–8.2), with a sudden shift to accepting PHP 8.4 as viable. I’ll break this down based on official WordPress documentation, PHP support timelines, and compatibility updates.

PHP Version Lifecycles and WordPress’s Approach

PHP versions follow a predictable schedule: 2 years of active support (bug fixes + security) followed by 1 year of security-only support. WordPress tests and supports multiple versions but phases out EOL ones to encourage upgrades. Here’s a quick timeline of relevant PHP versions and their EOL dates:

PHP Version Release Date Active Support Ends Security Support Ends (EOL) WordPress Minimum Support From
7.4 Nov 2019 Nov 2021 Nov 2022 WP 5.7+ (Dec 2020)
8.0 Nov 2020 Nov 2022 Nov 2023 WP 5.9+ (Jan 2022)
8.1 Nov 2021 Nov 2023 Nov 2024 WP 6.0+ (May 2022)
8.2 Nov 2022 Nov 2024 Dec 2026 WP 6.3+ (Jul 2023)
8.3 Nov 2023 Nov 2025 Dec 2027 WP 6.6+ (Jul 2024)
8.4 Nov 2024 Nov 2026 Dec 2028 WP 6.7+ (Oct 2024, beta)
  • Key Insight: By mid-2025, PHP 7.4 had been EOL for nearly 3 years (since Nov 2022), making it a high-risk version long before any 2025 notifications. However, WordPress delayed aggressive warnings for 7.4 to avoid breaking sites with incompatible plugins/themes—many of which lagged in PHP 8.x support until 2023–2024.
  • WordPress’s official recommendation (as of Oct 2025) is PHP 8.3 or greater for optimal performance and security, with a functional minimum of 7.2.24+ (though anything below 8.0 is discouraged due to EOL risks).

Why the PHP 7.4 Warning Started in July 2025

The timing aligns with WordPress 6.8’s release on July 15, 2025. This update included backend refinements to the Site Health tool, specifically tightening the threshold for “outdated PHP” warnings:

  • Pre-July 2025 Behavior: Site Health had flagged PHP <7.4 as “critical” since WP 5.7 (Dec 2020), and PHP 7.4 as “recommended to update” starting around WP 6.3 (Jul 2023). However, for users on 7.4, the warning was often softer (“Your site is running on PHP 7.4, which is outdated and unsupported”) to give time for ecosystem-wide compatibility. This was intentional—data from 2024 showed ~40–50% of WordPress sites still on 7.4, and rushed warnings could cause widespread breakage.
  • July 2025 Change: In WP 6.8, the warning escalated to critical for PHP 7.4 specifically, triggered by:
    • EOL Enforcement: With 7.4 now 2.5+ years past EOL, WordPress core contributors (via the PHP Compatibility team) decided it was time to prioritize security. The update message reads something like: “Your site is running on an outdated version of PHP (7.4.x), which does not receive security updates. It should be updated immediately.”
    • Ecosystem Maturity: By 2025, >90% of plugins/themes were PHP 8.x-compatible, reducing breakage risks. WP 6.8’s release coincided with PHP 8.3’s active support phase, making upgrades smoother.
    • Broader Context: This fits WordPress’s pattern of aligning warnings with major releases. For example, warnings for PHP 7.0–7.1 became critical in WP 6.6 (Jul 2024).

If you’re seeing this now (Oct 2025), it’s because your site updated to 6.8+ or the health check re-ran. No major “announcement” happened in July—it was a quiet core tweak to reflect real-world risks.

Why No Notifications for Upgrading to PHP 8.0, 8.1, or 8.2?

WordPress Site Health doesn’t send version-specific nudges (e.g., “Upgrade to 8.1 now!”) because:

  • Generic Guidance: Notifications focus on problems (e.g., “Outdated PHP—update to a supported version”), not step-by-step paths. The intent is to prompt users to the latest stable PHP (via their host’s panel), which in 2023–2024 would have been 8.0–8.2. Detailed upgrade paths are left to hosting docs or plugins like “PHP Compatibility Checker.”
  • Compatibility Caution: Early PHP 8.x had teething issues:
    • PHP 8.0 (EOL Nov 2023): Initial support in WP was “compatible with exceptions” until WP 6.3 (Jul 2023), due to strict typing changes breaking ~10–15% of plugins.
    • PHP 8.1 (EOL Nov 2024): Similar—warnings for pre-8.1 were recommended but not critical until mid-2024.
    • PHP 8.2 (ongoing support): Full support only from WP 6.6 (Jul 2024). Pushing these prematurely could have caused more harm than good, as hosts and developers needed time to adapt.
  • No “Never” Notified: There were indirect prompts. Since WP 6.0 (2022), Site Health showed performance/security benefits of “PHP 8.0+” in the Info tab. But without EOL pressure, many users ignored them—hence the delayed 7.4 escalation.

Why Suddenly Indicating PHP 8.4 as “Acceptable”?

PHP 8.4 (released Nov 2024) became “acceptable” (i.e., fully supported without warnings) due to proactive WordPress testing:

  • Beta Support in WP 6.7 (Oct 2024): Added initial compatibility for 8.4’s features (e.g., improved property hooks, lazy objects).
  • Full Support in WP 6.8 (Jul 2025): Raised to “fully compatible,” with Site Health greenlighting 8.4+ as “recommended.” This was updated in the core handbook on July 8, 2025, just before 6.8’s launch.
  • Reason for Speed: PHP 8.4’s changes were evolutionary (fewer breaking ones than 8.0), and WordPress’s annual November sync allowed quick integration. By Oct 2025, 8.4 is the “latest” with active support until Nov 2026, so it’s now the default “good” version in health checks.
  • No “Sudden” Shift: It’s evolutionary—warnings always pointed to “8.x or higher.” With 8.3 nearing EOL (Nov 2025), 8.4 naturally filled the gap.

Recommendations for Your Site

  • Check Your Version: Go to Tools > Site Health > Info > Server in your WP dashboard.
  • Upgrade Safely:
    1. Backup your site (use UpdraftPlus or your host).
    2. Test on staging (many hosts like Kinsta or SiteGround offer this).
    3. Switch via your host’s cPanel/Plesk (e.g., MultiPHP Manager) to PHP 8.3+.
    4. Use the free “PHP Compatibility Checker” plugin to scan for issues.
  • Performance Boost: Upgrading from 7.4 to 8.4 can yield 20–50% faster load times and better security.

If this doesn’t match your exact experience (e.g., custom hosting quirks), share more details like your WP version or exact warning text for deeper troubleshooting. WordPress’s goal is security without disruption—better late than sorry on those 7.4 warnings!

Note: I made an article on this topic at https://charlesworks.com/new-php-7-4-notices-in-wordpress/ for those looking for more info about it.