v9.93 2026-07-15 WeKan ® release

This release adds the following new features:

• Snap: new snap run wekan.migrate command to force a fresh MongoDB → FerretDB migration (snap-src/bin/wekan-force-migrate, registered in snapcraft.yaml). Ignores the database setting and the migration marker, removes any partial FerretDB SQLite + resume checkpoint, then re-runs the migration so it re-reads the existing MongoDB (3 or 7) data and migrates text + attachments + avatars to FerretDB again. The source MongoDB data is never modified or deleted. Watch it with snap logs -f wekan.mongodb or the migration dashboard. Thanks to xet7.

• Snap: new maintenance mode (snap run wekan.maintenance on|off) so you can run MongoDB OR FerretDB by hand for data access (snap-src/bin/wekan-maintenance, snap-src/bin/wekan-maintenance-page.mjs, and the DB control scripts). While the $SNAP_COMMON/.wekan-maintenance marker is present, the control scripts do not auto-migrate or auto-disable, so snap start wekan.mongodb (old MongoDB data) or snap start wekan.ferretdb (migrated FerretDB SQLite data) stays up instead of shutting itself down — letting you reach the data over the MongoDB wire protocol on port 27019 (one at a time; they share the port). WeKan itself serves an “under maintenance” page (HTTP 503) on the web port for all URLs while maintenance is on, so end users see a clear message. The page shows the Admin Panel product name if one is set (not “WeKan”): it is cached to $SNAP_COMMON/.productname.txt while a database is running (by wekan-control on startup and by the migration importers), so it is still available in maintenance mode when both databases are stopped. Thanks to xet7.

and fixes the following bugs:

• Snap: db-eval could not load the MongoDB driver, so EVERY database readiness check silently failed (snap-src/bin/db-eval.mjs; also migrate-schema-v843.mjs, migrate-gridfs-to-fs.mjs). db-eval is the small Node helper the snap uses (instead of mongosh) to check whether MongoDB/FerretDB is up, elect the replica-set primary, and run the migration’s mongod-7 readiness probe. It did import { MongoClient } from 'mongodb' and the wrapper set NODE_PATH=$SNAP/programs/server/node_modules to point at the bundled driver — but Node’s ESM loader ignores NODE_PATH (that env var is honored only by the CommonJS loader). So the import resolved nothing, db-eval exited before ever opening a connection, and every ping/primary/rs-* check “failed.” This was the single root cause behind a whole family of symptoms: WeKan looping “MongoDB not ready yet, retrying…” or “FerretDB not ready yet…” forever even though the database was running and listening; replica-set initialisation failing; and — most damaging — the MongoDB → FerretDB migration falling back to MongoDB 3.2 because the mongod-7 readiness probe never connected (mongod 7 opened the data fine, but db-eval couldn’t reach it, so migration-control wrongly concluded “mongod 7 can’t open this” and tried the 3.2 reader, which cannot read WiredTiger-7 files — producing no FerretDB SQLite). Proven by the migration source mongod log: mongod 7 reached Waiting for connections with zero Connection accepted before being killed by the readiness timeout. Fixed by resolving the driver with createRequire (CommonJS, which does honor NODE_PATH and the bundle layout), anchored inside the modern bundle. Thanks to xet7.

• Snap: the presence of a FerretDB SQLite database — not the migration marker — now decides whether to use FerretDB, so a FAILED migration no longer leaves the snap with no database (snap-src/bin/ferretdb-control, snap-src/bin/mongodb-control, snap-src/bin/wekan-control). An earlier attempt keyed the “use FerretDB / disable MongoDB” decision off the $SNAP_COMMON/.migration-to-ferretdb-done marker. But migration-control also writes that marker when the migration falls back (data unreadable, tools missing) or when there is nothing to migrate — with no FerretDB data produced. So on a server whose MongoDB → FerretDB migration failed, mongodb-control saw the marker, logged “migration already finished; disabling mongodb service” and disabled MongoDB, while FerretDB’s SQLite was empty — leaving WeKan with no database at all, looping “MongoDB not ready yet, retrying…” forever and refusing to keep wekan.mongodb running. Now all three scripts decide from actual data on disk: MongoDB is disabled / FerretDB is forced only when a *.sqlite database exists in files/db; an empty files/db means the migration did not succeed, so MongoDB starts normally and WeKan keeps working while the migration can be retried. The check is a single shared helper (snap-src/bin/ferretdb-has-data) that requires a *.sqlite file bigger than 0 bytes, not merely present, so a 0-byte stub never counts as “migrated”. And migration-control’s finish_success now verifies that non-empty SQLite (with its WAL) exists before switching to FerretDB — if the importer returns success but wrote no data, the snap keeps MongoDB and retries next start instead of switching to an empty database. Thanks to xet7.

• Snap: the migration’s mongod-7 readiness probe fast-fails when the temporary mongod has exited (snap-src/bin/migration-control). ready_via_node waits up to 45 s for the temporary source mongod to accept connections (a large MongoDB 6/7 database can need that long to replay its journal, #6454), but it now also checks the process is still alive: if the temp mongod has exited — e.g. mongod 7 cannot open old MongoDB 3.x data — it stops waiting immediately and drops to the MongoDB 3.2 reader instead of pinging a dead process for the full timeout. Matters across many unattended 6.09 → 9.x upgrades. Thanks to xet7.

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