v10.11 2026-07-21 WeKan ® release

This release fixes the following bugs:

• Fix: FerretDB high CPU that continued even with no clients connected (#6498). Meteor tails the OpLog (local.oplog.rs) with a tailable+awaitData cursor that starts at boot and runs with no clients; on FerretDB v1 that tail was re-running its query every 10 ms (~100 scans/second, forever), pinning CPU. This is a distinct cause from the OpLog bloat capped in the earlier fix — it is the tail’s poll rate, not the OpLog size. The bundled FerretDB fork now polls awaitData at a calmer 500 ms (still within the 1 s await budget, so reactivity latency stays low; tunable with FERRETDB_TAILABLE_AWAIT_POLL_MS), cutting idle tail load ~50x — see the FerretDB CHANGELOG. FerretDB OpLog stays ON by default (a reporter confirmed the earlier CPU fix worked), so this only makes the default mode cheap at idle. Additionally, for anyone who explicitly turns the OpLog OFF (WEKAN_FERRETDB_OPLOG=false), every launcher (snap, bundled release, Docker, Sandstorm) now also clears MONGO_OPLOG_URL in that polling-only branch, because merely having it set makes Meteor tail the OpLog regardless of the reactivity order — so polling-only is now truly tail-free. Covered by tests. Thanks to Alishara, bluetopaz1204, mueschel and xet7.
• Fix: on Sandstorm, the browser error that a page “can not be displayed embedded in another page” after a grain’s first-launch data migration. The grain launcher migrates the old MongoDB data to FerretDB v1 (SQLite) before starting WeKan, and while nothing was listening on the grain’s app port (during migration and the handoff to WeKan) sandstorm-http-bridge returned connection-refused, so the browser showed the framed-grain error and the user had to close and reopen the grain. The launcher now runs a tiny child-process bridge that answers the app port with an auto-refreshing “please wait” page across the whole migration and handoff — yielding the port to the migration importer’s own progress dashboard and releasing it just before WeKan binds it — so the grain stays framed until WeKan is up. Best-effort (guarded, killed on grain exit) so it never breaks grain startup; covered by wiring/ordering tests. Thanks to xet7.
• The recovery maintenance page now works the same on ALL FerretDB v1 platforms (#6492). Besides the in-app spinner (which shows once Meteor serves the client), every launch path now also serves a tiny standalone “recovering your data” page (HTTP 503) on the web port for the brief window while a just-restored FerretDB comes back up and before the app is up — so users never hit a bare connection error: the snap reuses wekan-maintenance-page.mjs with a recovery wording, and the bundled release/Docker paths serve the portable recovery-bridge.mjs. The bridge is time-bounded (WEKAN_RECOVERY_BRIDGE_SECONDS, default 20s) so it can never block WeKan from starting, hands straight over to the in-app spinner, and is skipped if its page or the marker is absent. Only the server clears the RECOVERY_IN_PROGRESS marker (after a real health probe), so the spinner behaves identically everywhere; tests enforce the bridge stays bounded and no launch script deletes the marker. Thanks to bluetopaz1204, mueschel and xet7.

Thanks to above GitHub users for their contributions and translators for their translations.