v1.1.9

• A release wordpress.org flags disable_autoupdate was reported as withdrawn by wordpress.org, which it is not. The flag means one thing only — do not install this one unattended. The release stays published and the Extensions screen offers it normally; a plugin genuinely pulled from the directory draws no update offer at all. The row now says wordpress.org has blocked unattended installation of this release
• Update now works on those rows again. It no longer goes through WP_Automatic_Updater, which core stops on the flag before any filter of ours is consulted, but through Plugin_Upgrader — the supervised install the flag is asking for, and the one the Extensions screen performs. Automatic passes still refuse the release, exactly as before
• Rebuilt the French translation binary, which had fallen eight strings behind its source

v1.1.8

• An update forced by hand from the Status screen was logged as Automatic. The marker saying a person asked for it was never read on the path that writes the entry, so Forced by hand — a label offered since 1.1.0 — could not appear. The marker is now read where the entry is actually written
• Entries already in the log keep the source they were written with: the column is stored at the time of the update, not worked out again when the log is read

v1.1.7

The menu opened on a form instead of on the answer.

• Status is now the screen the Update Pilot menu lands on, and the first entry in both the submenu and the row of tabs. Settings is where a site is set up, once; Status is where it is read, every time
• The Pending updates table moved out of a tab of its own and into Schedule, the section the screen opens on. What is held back, and how many days are left on each delay, is now the first thing the screen says rather than something behind a click
• Settings keeps its page=update-pilot address, so the plugin's own Settings link and any bookmark still land where they did

The compatibility report called a plugin's absence from wordpress.org a failure to check it.

• plugins_api() returns the same WP_Error for two opposite answers: "wordpress.org has no plugin with this slug" and "wordpress.org could not be reached". Only the first is a fact, and only the HTTP status separates them — 404 against everything else — so the status is now read off the response as it goes past. A site of 68 plugins, most of them commercial, reported 39 of them as Could not be checked; they are simply not in the directory, and now say so
• A transport failure never reaches that point, so an outage still cannot relabel a whole site's plugins as absent from a directory nobody managed to ask — the verdict stays unknown, which is what it is
• The slug asked about comes from core's update check where it exists, not from the folder name. Gravity PDF installs into gravity-pdf and is published as gravity-forms-pdf-extended; the folder name got a 404 and the plugin was written off unread
• The summary line counts the plugins that genuinely could not be checked. Four numbers that added up to 29 of 68 installed plugins, and said nothing about the other 39, was the whole complaint

A plugin distributed outside wordpress.org was never asked what it declares.

• The bundled GitHub updater answered plugins_api with tested set to get_bloginfo('version') — "tested against whatever you happen to be running", which is true of nothing. It now returns TESTED_WP, the constant that already fed the update transient. The View details popup was reporting a version the author never claimed
• The compatibility report reads that declaration instead of discarding it. A maintained plugin outside the directory still says what it was tested against, and refusing to look was why every such plugin sat in the table with nothing to say
• It is attributed, never merged: a self-declared figure is followed by (declared by the plugin itself, not by wordpress.org). Both numbers are written by the same hand and verified by nobody, but one of them is said with no third party in the room, and the table should not blur that
• A plugin outside the directory that declares nothing at all is still reported as not hosted, not as an author who forgot — there is no directory entry to have an opinion about

v1.1.6

Notices sat inside the column, but not aligned with it.

• A bare admin notice carries margin: 5px 15px 2px from WordPress, and WordPress takes those side margins back only for notices inside .wrap — which these screens deliberately do not use. A notice therefore stood 15px in from the column it belongs to, and 2px above whatever followed. Core's own rule is now applied where the notices actually land

v1.1.5

Admin notices were drawn edge to edge, across a page whose content is centred.

• The .wp-header-end marker now sits inside the 800px column. WordPress moves every notice on a screen to just after that marker — ours and any other plugin's — so with it above the column, notices were being lifted out of it and stretched the full width of the page

v1.1.4

Exclusions and Status now have sections of their own, as the settings screen does.

• Exclusions is split into Plugins and Themes; Status into Schedule, Pending updates, Environment and Plugin compatibility
• A panel no longer repeats its own tab as a heading. Last 30 days keeps its heading and sits under Schedule, where it belongs
• What acts on the whole screen stays outside the sections and reachable from any of them: the save button on Exclusions, and the three buttons under Actions on Status
• As on the settings screen, the sections are a convenience of the browser's: without JavaScript every panel shows at once and the screen is the one long page it was before

v1.1.3

The settings screen stood a little tighter than the other three.

• Its title now sits the same distance above its tabs as everywhere else. The second row of tabs makes that header taller, rather than the title moving up to hold the header at a fixed height

v1.1.2

An update run from the Status screen left the plugin it had just updated switched off.

• Plugin_Upgrader::upgrade() deactivates the plugin it is about to replace, silently, unless the request is a cron one — core's own comment says a browser is then required to switch it back on, and core does that from a path a pass of ours does not take. So Update now and Run an update pass now installed the new version and left the plugin deactivated. Update Pilot updating itself switched itself off, taking its own menu with it. Both buttons now switch back on whatever the upgrader switched off
• Scheduled runs were never affected: cron is precisely the case core exempts
• A plugin that cannot be switched back on again — which normally means the new version is broken — is now reported on screen instead of disappearing quietly. Reactivation runs core's fatal-error check, so a broken release stays off rather than taking the site with it

v1.1.1

The four screens now look like one plugin.

• Exclusions, Log and Status wear the same chrome as the settings screen: the plugin's name over a row of tabs moving between the four screens, the current one underlined, and the same 800px column beneath
• The settings screen keeps its five sections, now on a second row under the first. That row is still a tablist switching panels in place; the row above it is made of links, and loads a screen
• One list of screens behind both the menu and the tabs, so a screen cannot exist in one and be missing from the other

v1.1.0

An update held back can now be installed on the spot, without changing the rule that was holding it.

• Update now on each held row of the Pending updates table on the Status screen. It applies to that item, on that occasion: nothing is written to the settings, and the next pass judges everything by the rules again
• WordPress still performs the installation. The pass runs exactly as the scheduled one does, with every other item refused for its duration, so asking for one plugin cannot quietly install three
• The log records these as Forced by hand rather than as automatic, because the schedule did not choose them
• No button is offered where pressing it would do nothing: a release wordpress.org has withdrawn is refused before the policy is consulted, and the column is absent entirely for a user who may read this screen but not install updates. WP_AUTO_UPDATE_CORE still outranks the button