DaisyVotes — Messages & MiniMessage

Every piece of chat and action-bar text lives under messages: in config.yml. All of it supports MiniMessage formatting and {…} placeholders.

MiniMessage primer

DaisyVotes uses MiniMessage, Adventure’s modern text format:

Tag	Effect
<#FFC8DD>text	Hex color
<gradient:#FFC8DD:#BDE0FE>text</gradient>	Gradient across the text
<bold> <italic> <underlined>	Styles
<click:run_command:'/vote'>text</click>	Run a command on click
<click:open_url:'{url}'>text</click>	Open a URL on click
<hover:show_text:'…'>text</hover>	Tooltip on hover
<prefix>	Inserts your configured prefix

config.yml

messages:
  prefix: "<#B8C0CC>[<gradient:#FFC8DD:#BDE0FE>DaisyVotes</gradient><#B8C0CC>]</#B8C0CC>"
  vote-received: "<prefix> <gradient:#FFC8DD:#BDE0FE>{player}</gradient> <#B8C0CC>voted on <#FFF1C1>{site}</#FFF1C1><#B8C0CC> and earned rewards."

Two different placeholder styles

In-plugin messages use curly braces — {player}, {site}. Reward commands/messages use percent signs — %player%. PlaceholderAPI uses %daisyvotes_*%. They are not interchangeable.

Other plugins' %placeholders% work in some of these too

With PlaceholderAPI installed, a %player_name% or %vault_eco_balance% written into one of these strings resolves for whoever reads it, escaped the same way as in menus. This currently covers /vote and /daisyvotes command replies and the action-bar keys (actionbar-reminder, leaderboard-envy, and the rest). Server-wide broadcasts (party-progress, party-triggered, streak-milestone) have no single player to resolve for and never do this, and a handful of the direct per-vote confirmations — vote-received, wheel-reward-won among them — aren’t wired to it yet either. See Other plugins’ placeholders inside DaisyVotes for the full picture.

Legacy colour codes

&c, &l, §a, and both hex spellings (&#FFC8DD and &x&F&F&C&8&D&D) work anywhere MiniMessage does — messages, titles, action bars, boss bars, GUI titles, item names, lore. Mix them freely with MiniMessage tags in the same string:

vote-received: "&c<bold>{player}</bold> &fvoted on &e{site}&f!"

Two things this does not pretend to be

• Legacy codes reset; MiniMessage tags nest. In the old format a colour code cancels bold and italic, so &lBold &cRed prints “Red” unbolded. MiniMessage tags don’t work that way — &lBold &cRed keeps the bold, because it’s really <bold>Bold <red>Red. If you want the old reset behaviour, close the tag or start again with &r.
• A code inside a value stays literal text. Values — a player’s name, a site’s display-name — are inserted after the template is parsed, never before, so a player named &cSteve shows up as those exact characters rather than turning your broadcast red. This is the same boundary that stops a player named <red> from injecting markup, and it’s deliberate: allowing it would let a player’s name change the formatting of a message they’re mentioned in.

One consequence: a literal &c can’t be written — it will always be read as a code. A lone & with no code character after it (Tom & Jerry) passes through untouched.

All message keys

Key	Purpose	Placeholders
prefix	Prefix inserted by <prefix>.	—
vote-received	Broadcast when a player votes.	{player}, {site}
party-progress	Vote-party progress broadcast.	{party_current}, {party_required}
party-triggered	Broadcast when a party unlocks.	{party_required}
party-boss-bar	Boss-bar title while a party fills. Shown to everyone online.	{party_current}, {party_required}
rewards-queued	Shown on join when offline rewards are waiting.	{count}
rewards-claimed	Confirmation after /vote claim.	{reward_count}
no-queued-rewards	Shown when nothing is queued.	—
login-reminder	Clickable “you haven’t voted” message on join.	—
actionbar-reminder	The periodic action-bar nudge.	—
streak-milestone	Broadcast when a player hits a streak milestone.	{player}, {streak}
almost-there	Action bar within three days of the next streak milestone.	{next}
leaderboard-envy	”X votes behind the next player” nudge.	{behind}, {next_name}, {next_rank}
reload-complete	Confirmation after /daisyvotes reload.	—
site-link	The clickable single-site vote link (/vote <site>).	{site}, {url}
admin-force-party	Confirmation after /daisyvotes forceparty.	—
invalid-site	Error for an unknown site name.	—
wheel-spin-earned	Shown when a daily wheel spin is earned.	—
no-wheel-spins	Shown when a player has no spins yet.	—
wheel-reward-won	Shown when a wheel prize is won.	{reward}
points-balance	/vote points output.	{player}, {points}
points-earned	The “+N vote points” feedback on a vote.	{points}, {balance}
shop-purchased	Confirmation of a shop purchase.	{item}, {cost}, {points}
shop-insufficient-points	Not enough points to buy.	{cost}, {points}
shop-daily-limit-reached	Daily purchase limit hit.	{item}
shop-no-permission	Player lacks the item’s permission.	—
storage-unavailable	The database couldn’t be reached during a purchase or a claim. Nothing is charged and nothing is granted; the reason is in the console.	—
menu-blocked-here	Opening a DaisyVotes menu in a restricted world.	—
purchase-blocked-here	Buying from the vote shop in a restricted world. Points are untouched.	—
rewards-held-for-world	A vote counted, but its rewards were queued because the player was in a restricted world.	—
points-updated	Confirmation after an admin points adjustment.	{player}, {points}

Tip

After editing messages, run /daisyvotes reload to apply them with no restart.

An upgrade never rewrites a message you already have

Config files are merged by adding what’s missing, never by replacing what’s there. A key that gains a new placeholder in a later release — rewards-queued gaining {count}, for instance — keeps your existing wording on an upgraded server, because that line is already in your config.yml. To pick up the new default, add the placeholder to your own string. This is also why a message you’ve customised survives every update.

config.yml Reference The messages section in context with every other setting.