The site-list visualization work has run across several posts: the blue pulse and green completion border, the marker-based running-site detection, and the three-state visual hierarchy. v1.6.8 added three more UX improvements to the same area. This post records the design decisions behind them.
All three share a common starting point: managing 10–20 sites in a bulk maintenance run that takes several tens of minutes, and making that time easier to follow without introducing new failure modes.
Improvement 1 — refresh the thumbnail and badge the moment a site finishes
Previously, thumbnails and the pending-plugin badge were only refreshed after the entire bulk run completed. If the first of ten sites finished early, its thumbnail stayed stale until all ten were done.
The fix: refresh only the completed site the instant its completion is detected. A new _refreshCompletedSitesNow function wires into the streaming-log loop. Each time a site-completion marker arrives, it:
- Updates that site’s
?v=<mtime>to bust the thumbnail cache - Calls
_invalidatePendingPluginCacheForSiteIdsto partially invalidate and re-render the plugin badge
The key constraint: each refresh touches exactly one site and doesn’t interrupt the sites still running behind it.
Improvement 2 — highlight error sites in red for 24 hours
To make “which site had an error” visible at a glance after a run, a site-error CSS class was added — red border (#ef4444) plus a light red background (rgba(239,68,68,0.08)), applied to both the grid and list views. It follows the same pattern as the existing running / completed / pending classes. Status priority is running > error > completed > pending.
The error state persists for 24 hours via a _siteErrorStatus map with a completion timestamp. Twenty-four hours matches the green completion border from the earlier work — long enough to cover “what happened today.” Starting a new maintenance run resets the previous error badge for those sites, so badges don’t carry over across separate sessions.
False-positive prevention — marker lines only
The most important design constraint in the error detection logic was avoiding false positives. Streaming logs contain many internal lines from the maintenance agent. If the detection is too broad, an innocent log line could trigger a red badge for a site that succeeded.
The fix: the agent emits exactly one conclusive marker line at the end of each site’s processing:
[site name] ✗ Maintenance result: ERROR
[site name] ✓ Maintenance result: OK
The front-end _detectSiteResultFromLog function only looks at lines containing Maintenance result: (or the Japanese equivalent). Every other line is ignored — the site stays green. This is the same conservative approach established in the streaming-log marker post: one unambiguous marker, no inference from surrounding context.
The tradeoff: a site whose marker line is never emitted stays green instead of showing an error. Missing an error badge is less harmful than showing a false-positive red badge, so the logic deliberately favors the cautious side.
Improvement 3 — auto-deselect after the run completes
After a multi-site maintenance run, the selected checkboxes remained checked. The next operation could unintentionally target those same sites again if the user forgot to clear them.
The fix: _finalizeMaintenanceRun — the shared teardown path for both standard maintenance and selective plugin updates — now automatically unchecks the sites that were part of the completed run (_runningSiteIdOrder). No toggle was added; auto-deselect is unconditional.
After a run, completed sites have a green or red border for 24 hours, so context about what ran is still visible through the color state. The checkbox doesn’t need to carry that history — the border does.
Wrap-up
These three improvements extend the site list from three states to four: waiting / running / completed / error. V33’s blue pulse and green border introduced running and completed. V44’s visual hierarchy formalized the three-level visual weight. Error is now an explicit fourth state with its own color and persistence.
The thread running through all three improvements is the same: when you can’t determine the right answer with certainty, default to the safer outcome. Partial refresh should not disturb other running sites. Error detection should not fire on ambiguous lines. Auto-deselect should not depend on the user remembering to clear. Each is a different problem, but the same instinct drove each solution.