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.