TDXPlugins Documentation

What survives an update, what gets backed up, and the one thing that doesn't auto-merge.

Both TDX plugins use a config-versioning system that auto-merges new bundled keys into your existing config.yml and messages.yml on every plugin update. Your customisations are preserved — you don't need to diff files by hand.

What happens when you update

Stop the server

Always stop the server cleanly before swapping a plugin jar. A graceful shutdown flushes any pending writes to disk; killing the process mid-write can corrupt the SQLite database (rare, but real).

Replace the jar

Delete the old jar from plugins/ and drop the new one in.

Start the server

On first boot with the new jar, the plugin runs the config updater:

It reads the bundled config.yml template from inside the new jar.
It compares every key against your live config.yml on disk.
For any key that exists in the bundled template but is missing from your file, it's added with the default value and the bundled comment.
Your existing values are never overwritten. Only new keys are added.
Before any change, the live file is copied to config.yml.backup-YYYYMMDD-HHMMSS so you have a known-good rollback.
The same process runs for messages.yml.

You'll see something like this in the log:

latest.log

[INFO] [TDXVotePlus] Updating config.yml from version 4 -> 5
[INFO] [TDXVotePlus] Backed up to config.yml.backup-20260411-1432
[INFO] [TDXVotePlus] Added 3 new keys, preserved 47 existing values

The auto-merger never deletes keys that are no longer used — it only adds. If a future plugin version drops a config block, your old block stays in the file and is silently ignored. This is by design: it makes rolling back to an older jar painless.

What doesn't auto-update

Two things are not touched by the config updater:

Storage backend. Switching from SQLite to MySQL (or vice-versa) is never automatic — you'd lose data. See each plugin's storage migration guide for the manual steps.
Database schema migrations. These run automatically on plugin start and are tracked in their own version table inside the database, but they are not rolled back if you downgrade the jar. Always test a major version bump on a staging copy before touching production.

Always read the changelog of a major version bump (e.g. 1.x → 2.x) before updating production. Patch bumps (1.2.7 → 1.2.8) are always safe.

If something goes wrong

Restore the timestamped backup that was written next to your config:

cd plugins/TDXVotePlus
mv config.yml config.yml.broken
mv config.yml.backup-20260411-1432 config.yml

Then restart the server. If the issue is database-shaped instead of config-shaped, ask in the TDX Discord before doing anything destructive — most "the plugin lost my data" reports turn out to be a config pointing at the wrong database.

Updating safely