Show the Enable auto-updates toggle for the self-updater

WordPress only renders the "Enable auto-updates" toggle for a plugin that appears in the update_plugins transient's response or no_update list, which is what sets core's update-supported flag. UpdateChecker only populated the response side (when a newer release existed), so between releases the plugin was absent from the transient and the toggle never showed. provideUpdate() now returns a no_update payload (installed version, empty package) whenever no newer release is offered — including when the release lookup fails — so the plugin stays in the transient and the toggle appears. The response path (one-click and unattended updates) is unchanged. Bumps to 1.1.1 so the fix ships to installed sites via the self-updater. Co-Authored-By: Claude Opus 4.8 <[email protected]>
2026-07-24 08:46:31 -03:00
parent 37ec8a3315
commit 51dd032668
4 changed files with 68 additions and 22 deletions
@@ -50,9 +50,16 @@ update for a same-slug plugin and makes core fire the
 4. When newer, returns the release's first `.zip` asset as the update
   package. Core takes over from there: Plugins-screen notice, one-click
   update, and WP-Cron auto-updates if enabled.
+5. When not newer — the site is current, or the lookup failed — returns a
+   `no_update` payload (installed version, empty package). This keeps the
+   plugin in core's `update_plugins` transient so core's `update-supported`
+   flag stays set and the **Enable auto-updates** toggle shows on the
+   Plugins screen. Without it, an off-directory plugin is absent from the
+   transient between releases and the toggle never appears.

 Any API failure, malformed response, or asset-less release degrades to
-"no update available" — never an error surfaced to the site.
+"no update available" (the `no_update` payload) — never an error surfaced
+to the site, and never a lost auto-update toggle during a Gitea blip.

 ## Cutting a Release
 1. Bump the version in `unsupervised-schedular.php` (both the `Version:`