Skip to content

v0.61.3

Choose a tag to compare

@github-actions github-actions released this 26 Jun 11:03
4e7d53f

Backup fixes reported by a self-hoster. Agent updated to 0.61.3.

Fixes

  • Scheduled backups stalled on membership-gated sites (#117). On sites where a membership/privacy plugin (e.g. SureDash "private community") redirects every front-end URL to a login page, scheduled backups stalled with "no progress for >2m0s" because the agent drove the backup continuation through WordPress cron loopbacks to /wp-cron.php, which the gate intercepts. The agent now probes the loopback and, when it is gated, runs the backup in-process after fastcgi_finish_request instead of via the dead loopback. If the continuation still cannot run, the watchdog now reports a clear reason ("redirected to login — the site may be behind a membership/privacy gate blocking WordPress cron") instead of a silent stall. Manual backups were never affected.
  • Deleting a snapshot left its manifest.json orphaned in object storage (#116). Snapshot deletion correctly cleaned up chunks but skipped the per-snapshot manifest.json object, leaving it with no database row and unreclaimable by GC. Both delete paths (operator delete and retention auto-prune) now remove the manifest object (best-effort, 404-tolerant).
  • Backups "Upcoming" panel contradicted the schedule (#114). The panel showed "No upcoming runs. Enable the backup schedule to queue runs." even when the schedule was enabled and the next runs were listed on the same page. It now shows the computed projected runs when the schedule is enabled, and only prompts to enable when the schedule is actually off.

Upgrade

  • Pull ghcr.io/mosamlife/wpmgr-{api,web,media-encoder}:v0.61.3.
  • Update the agent plugin to 0.61.3 (the #117 fix is agent-side; hosted fleets self-update automatically).
  • Pre-existing orphaned manifest.json objects from past deletes are not auto-swept; an S3/R2 lifecycle rule on the tenant/*/site/*/backup/*/manifest.json prefix can reclaim them.