v0.61.3
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 afterfastcgi_finish_requestinstead 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.jsonorphaned in object storage (#116). Snapshot deletion correctly cleaned up chunks but skipped the per-snapshotmanifest.jsonobject, 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.jsonobjects from past deletes are not auto-swept; an S3/R2 lifecycle rule on thetenant/*/site/*/backup/*/manifest.jsonprefix can reclaim them.