Add an "unsupported WordPress version" upgrade task for EOL branches #772

Companion to ProgressPlanner/progress-planner-server#63, and a sibling of the security-update task shipped in #769.

Context

#769 covers sites on a supported branch that are behind on a security patch: UI lockdown, one-click branch-pinned update, admin emails. A site running a branch that WordPress no longer patches (beyond the backport window) is a different case: there is no same-branch patch to install, so #769 never fires — the site just stays insecure.

The server side will email the registered subscriber about this (progressplanner-server#63, feed-driven like the patch alerts). That email is the safety net for neglected sites. This issue is the in-product half for actively used sites: a persistent recommendation task in the dashboard, where the fix actually happens.

What to build

A new task: "Your WordPress version no longer receives security updates — upgrade to WordPress X."

• A normal high-priority recommendation, not the Add critical security-update task with UI lockdown and admin alerts #769 lockdown treatment: a major upgrade is planned work (compatibility checks, backups), not a drop-everything patch. It should be prominent and persistent, but the user keeps their task list.
• CTA links to update-core.php. Unlike the branch-patch case (where core's Updates screen hides same-branch offers and Add critical security-update task with UI lockdown and admin alerts #769 needed the pinned-form trick), the major upgrade is what core's Updates screen offers by default — no special update flow needed.
• Task ID versioned per branch (unsupported-wp-6-5), mirroring Add critical security-update task with UI lockdown and admin alerts #769's per-release IDs: if the user upgrades to a branch that later goes EOL too, that's a fresh task with fresh points.
• Completes automatically when the installed major changes (reuse the completion hooks from Add critical security-update task with UI lockdown and admin alerts #769: manual update celebration, automatic_updates_complete silent completion).
• Copy should acknowledge the effort honestly: recommend a backup first, mention that plugins/themes may need updates for compatibility — not the "update within hours" urgency of Add critical security-update task with UI lockdown and admin alerts #769, but clear that staying is not an option.

Detection — needs a design decision

The update-core transient alone is ambiguous: "no same-branch offer + newer major exists" is also true for a site that is current on an old-but-supported branch. Options:

1. Fetch the stable-check feed (https://api.wordpress.org/core/stable-check/1.0/) on a daily cron and check whether the newest patch of the installed branch is marked insecure — the same rule the server uses. Small JSON, cacheable, exact.
2. Heuristics on core's own signals (the "insecure version" nag state) — fragile and undocumented.

Option 1 is probably right, but it adds an outbound HTTP call to wordpress.org (note: core itself already calls api.wordpress.org routinely, and #769's zero-outbound-HTTP guarantee applied to the alert email path, not to detection — worth preserving that distinction in tests).

Also unlocks (server-side)

The get-stats payload's plugin_url currently gives the server's EOL email nothing better than update-core.php to link to. Once this task exists, the dashboard deep link becomes the natural target, same as the patch-alert email (see decision 3 in progressplanner-server#63).

Out of scope

• Emailing admins from the plugin about EOL (core already nags in wp-admin; the subscriber email is the server's job).
• Any lockdown/dismissability changes to Add critical security-update task with UI lockdown and admin alerts #769's security-update task.

🤖 Generated with Claude Code