DaisyVotes — Migrating & Upgrading

Read this before you drop in a new JAR. Upgrades are listed newest first; if you are coming from 2.0.x, read the 2.5.0 section — it resets vote statistics.

Upgrading to 2.6.2

Nothing resets or migrates. Replace the JAR and restart — no config change is required.

If you run more than one server, or use MySQL

Two faults in earlier builds were silent — nothing errored, the only symptom was numbers that didn’t add up:

Two servers on one machine could share a network identity

With server-id: auto in network.yml, DaisyVotes derived the id from the server software name plus the hostname — and that software name is Paper on every Paper server there is. Two servers on the same machine could therefore end up with the same id, and each then discarded the other’s cross-server messages as its own echo: vote counts drifted apart, vote parties fired on one server only, and rewards were never routed across.

auto now derives the id from the hostname and the game port, so two servers on one machine can no longer collide. If you set your own server-id, nothing changes for you. If two servers ever do share one — a hand-copied network.yml is still a way to hit this — /daisyvotes doctor now fails loudly and names it. See Cross-Server (Redis).

MySQL — not MariaDB — could fail to set up its tables at all

Index creation used CREATE INDEX IF NOT EXISTS, which MariaDB, SQLite and Postgres all accept and genuine MySQL rejects outright. On real MySQL, table setup failed. MariaDB was never affected, which is why this went unnoticed for a while — the two are usually spoken of as interchangeable. If you tried MySQL, hit errors, and gave up, it works now.

A vote on one server and a shop purchase on another, close together, could overwrite one another. Each server locked a player’s row only within its own JVM, which does nothing against a second server writing the same row at the same time. Player-record updates are now locked across the whole network when Redis is enabled. Single-server setups were never affected. See Locking a player’s record across servers.

Legacy colour codes

&c, &l, §a, and both hex spellings (&#FFC8DD and &x&F&F&C&8&D&D) now work everywhere MiniMessage does — messages, menu titles, item names, lore, action bars, boss bars — mixed freely with MiniMessage tags in the same line. A colour code inside a value (a player’s name) still renders as literal text, which is deliberate. See Legacy colour codes.

Custom items — Nexo, Oraxen, ItemsAdder

New in 2.6.2

Anywhere a material goes — menus.yml, rewards.yml, shop.yml — you can now write nexo:ruby_sword, oraxen:ruby_sword, or itemsadder:mypack:ruby instead of a vanilla id: site candles, shop icons, wheel prizes and previews, and reward icons all resolve it. No plugin dependency is added; DaisyVotes reaches whichever of the three is installed by reflection, and reports a missing plugin or unknown id through /daisyvotes doctor instead of failing quietly. See Custom items.

Postgres

backend: postgres in storage.yml now actually works — the JDBC driver was never bundled before, so it could only fail at startup. Remember to set remote.port: 5432; the shipped default is MySQL’s 3306. SQLite and MySQL/MariaDB remain the well-travelled paths; Postgres is the newest of the three. See Storage & Data.

Configs are organised differently, and comments stop piling up

A freshly generated config.yml now runs in roughly the order you’d work through it — license first, then how voting behaves, then the features you switch on, then presentation, ending with the long messages block. Your existing files are not touched by this: upgrades only ever append settings that are missing, exactly as before, and never reorder or rewrite a file you’ve already edited.

Separately, a real bug in the merge that adds those new settings is fixed: it used to leave a duplicate of some comment blocks behind on certain upgrades, so a config that had been through several releases could carry the same paragraph two or three times over. That no longer happens going forward; the extra copies already in your file from before are cosmetic and safe to delete by hand.

storage.yml also now documents mariadb as a valid backend value alongside mysql — it always worked, it just wasn’t written down.

Upgrading to 2.6.0

Nothing in 2.6.0 resets or migrates data. Your configs, database, receiver keys and v2 tokens are all untouched, and new config keys are appended to your existing files with their comments — nothing you wrote is removed or reordered.

If you are on Minecraft 1.21.4, update

Rewards were silently not being given out on 1.21.4

Paper changed how items are built partway through 1.21. Every item DaisyVotes built from config threw an error on 1.21.0 – 1.21.4, which meant votes arrived, were counted, and paid out nothing — with a NoSuchFieldError in the console and no other sign anything was wrong.

2.6.0 detects what the server it is running on supports. Every 1.21.x release now works, 1.21 through 1.21.11.

Vote counts were being recorded wrong

Four separate defects could make a player’s recorded votes disagree with the votes they cast. All four are fixed, but votes already recorded wrongly are not repaired automatically:

• A player could be split into two records. Most voting sites do not send a Minecraft UUID, so when a vote arrived while the player was offline, DaisyVotes invented one from their name. Votes cast while online and while offline landed under two different identities, and every total split between them. If your leaderboard has a player who looks like they lost votes, this is why.
• Simultaneous votes could be counted once. Two votes for the same player arriving together were both credited to the same starting total.
• On a multi-server setup sharing one MySQL database, one server could overwrite counts another had just saved.
• Daily, weekly and monthly counters were stale. They were only reset when that player next voted, so a player who last voted on Tuesday still showed Tuesday’s daily count on Friday — in-game, in PlaceholderAPI, and on any website reading the database.

Reading vote data from a website?

The daily/weekly/monthly columns are only trustworthy from 2.6.0, and only when you filter on the new period-key columns. See Database access for queries that are correct.

What’s new

• Every vote-menu button is configurable — slot, material, name, lore, and enabled: false to remove one. See Vote sites & menu.
• Per-site vote cooldowns, either a rolling window (every: "8h") or a fixed daily reset in the site’s own timezone.
• World restrictions for servers with per-world inventories. See Configuration.

1. Stop the server.
2. Replace the JAR. No backup is required for 2.6.0 itself — but if you are coming from 2.0.x, back up first and read the 2.5.0 section below.
3. Start the server and run /daisyvotes doctor.

Upgrading to 2.5.0

Vote statistics reset on this upgrade

2.5.0 stores vote data under new column names. Your old rows are not deleted — they stay in the database — but they are no longer read, so vote totals, streaks, points and wheel state all start again.

Back up plugins/DaisyVotes/data.db before upgrading (or dump your MySQL/MariaDB database). If you want the old numbers back, the previous JAR plus that backup restore them exactly.

This is a one-time cost of moving onto the new data layer and is not repeated in later releases. On first start you will see one warning per table naming the old and new columns — that is expected.

Your configuration is not affected. Every config file is read as-is and keeps your values and your comments. Your receiver’s RSA key and v2 tokens are unchanged, so you do not need to re-register anything with your voting sites.

Other things that changed in 2.5.0:

• Vote-party progress moved from a chat broadcast to a boss bar that appears on a vote and fades. vote-party.broadcast-progress-every now defaults to 0 on fresh installs; if you already set it, your value is kept.
• visuals.banner-style no longer does anything. The key is kept so existing configs still parse.
• Top-voter awards now run at 00:05 in wheel.reset-zone instead of on an interval sweep.
• Config files are watched again, so editing one on disk applies without /daisyvotes reload.

Upgrading to 2.0

What’s new in 2.0

The big one: DaisyVotes now has its own built-in vote receiver — NuVotifier is no longer required. It also adds an optional Redis cross-server mode.

Built-in Vote Receiver Receive votes directly (Votifier v1/v2). NuVotifier optional.

Cross-Server (Redis) Run a network off a shared database, with optional Redis.

Moving off NuVotifier

On first start, DaisyVotes automatically imports your plugins/Votifier/config.yml — port, tokens, and RSA keys — into receiver.yml. Your vote sites keep working unchanged.

1. Update the JAR and start the server. Check /daisyvotes receiver status (should be listening); /daisyvotes doctor confirms the import.
2. Once votes arrive, you can remove NuVotifier. Prefer to keep it? Set mode: NuVotifierBridge in receiver.yml.
3. Re-run an import any time with /daisyvotes receiver import.

New config files: receiver.yml (the receiver) and network.yml (cross-server). For a network, also switch storage.yml to a shared MySQL/MariaDB database.

The rest of the rewrite

Vote Points & Shop Earn points per vote, spend them in /vote shop.

Daily Reward Wheel Vote every site for a weighted daily spin.

Discord Webhooks Styled embeds on votes, parties, streaks, and rare wins.

Top Voter Awards Automatic daily/weekly/monthly Top 3 rewards.

Also new: cumulative rewards (every Nth vote), a /daisyvotes doctor setup diagnostic, stronger anti-fraud (strict mode + duplicate detection), a developer API (TopVoterAwardEvent), and a redesigned pastel GUI suite.

What changed for operators

• Config keys are now kebab-case. requiredVotes → required-votes, voteMenu → vote-menu, displayName → display-name, and so on.
• Five config files instead of the old set: config.yml, menus.yml, rewards.yml, shop.yml (new), and storage.yml.
• Data is SQLite via Sculk Data, with a fuller set of tables (points, wheel, shop, top-voter, and vote-event history). See Storage & Data.
• New reward categories: wheel-rewards, cumulative-rewards, plus per-period Top Voter rank rewards in config.yml.

Automatic migrations

DaisyVotes upgrades your files on startup so you don’t have to hand-edit them:

• menus.yml keys are converted from camelCase to kebab-case automatically (voteMenu → vote-menu, displayName → display-name, …). Your values and comments are preserved, and a backup is written to menus.yml.backup-before-kebab-keys.
• Legacy menu layouts (older multi-row formats) are upgraded to the current candle layout.
• The database schema is migrated forward; existing vote counts are kept.

Note

You’ll see a console line noting any conversion that ran, including where the backup was saved.

Upgrade steps

1. Back up first. Stop the server and copy your plugins/DaisyVotes/ folder (configs and the database file). See Storage & Data.

2. Swap the JAR. Replace the old DaisyVotes JAR in plugins/ with the new build.

3. Start the server. DaisyVotes generates shop.yml, migrates menus.yml keys (with a backup), and upgrades the database.

4. Review the new options. Skim config.yml for the new sections — points, wheel, discord, top-voters — and enable what you want.

5. Verify. Run /daisyvotes doctor, then /daisyvotes testvote <player> to confirm rewards still land.

Breaking changes to watch for

• NuVotifier is no longer a dependency. DaisyVotes receives votes itself and imports your old config automatically; keep NuVotifier only if you set mode: NuVotifierBridge in receiver.yml.
• Any tooling or docs that referenced camelCase config keys must use kebab-case now.
• If you previously hand-edited menus.yml, confirm your customizations survived the conversion (the backup is right next to it).
• Reward command lines are unchanged in format, but double-check they still match your other plugins after the upgrade.

Tip

If anything looks off after upgrading, the original files are safe: your pre-upgrade backup (step 1) plus the automatic menus.yml.backup-before-kebab-keys give you two ways back.

Troubleshooting & FAQ Something not working after the upgrade? Start here.