DaisyVotes — Placeholders

With PlaceholderAPI installed, DaisyVotes registers an expansion under the identifier daisyvotes. Use these in scoreboards, HUDs, holograms, chat, and tab lists. Values are cached for ~10 seconds, so they never query the database on the main thread.

Player totals

Placeholder	Value
%daisyvotes_total_votes%	Lifetime votes
%daisyvotes_season_votes%	Votes since the last season reset — never rolled on a calendar
%daisyvotes_daily_votes%	Votes today
%daisyvotes_weekly_votes%	Votes this week
%daisyvotes_monthly_votes%	Votes this month

Easy to mistype

It’s %daisyvotes_daily_votes% — daily, not “daisy”. %daisyvotes_daisy_votes% is aliased to it, precisely because that misspelling is one letter away from the brand name and arrived as a support question within a week of the placeholder existing.

Streaks

Placeholder	Value
%daisyvotes_current_streak%	Current streak
%daisyvotes_best_streak%	Best streak ever

Vote points

Placeholder	Value
%daisyvotes_points%	Current vote-point balance
%daisyvotes_lifetime_points%	Total points ever earned

Queued rewards

New in 2.9.0

Placeholder	Value
%daisyvotes_queued_rewards%	Rewards waiting in this player’s /vote claim queue

%daisyvotes_queued% is the same number — that’s what it’s called in menus.yml (<queued>), so both spellings resolve.

Why it's a cached number

The claim queue is its own database table, and PlaceholderAPI resolves on the main thread — a scoreboard rendering this every tick can’t be the thing that queries it. So DaisyVotes reads the queue on join, on every /vote menu open, and on every claim, and the placeholder serves that. Rewards queued for a player while they’re online (a vote in a restricted world, a party payout) move the number as they land.

The consequence: for the first moment after a player joins, before the read comes back, it shows 0. It also shows 0 if the database can’t be reached — but that case is never silent, it’s a warning in the console and a failure in /daisyvotes doctor.

Vote party

Placeholder	Value
%daisyvotes_current_votes%	Votes toward the next party
%daisyvotes_party_required%	Votes needed for a party
%daisyvotes_votes_remaining%	Votes left to trigger
%daisyvotes_party_percent%	Percent complete (0–100)

Leaderboards

Ranked placeholders follow the pattern:

%daisyvotes_top_<scope>_<n>_<field>%

• <scope> — daily · weekly · monthly · alltime
• <n> — rank number, 1 through your stats.leaderboard-limit (default 10)
• <field> — name or votes

Example	Value
%daisyvotes_top_weekly_1_name%	This week’s #1 voter’s name
%daisyvotes_top_weekly_1_votes%	This week’s #1 voter’s vote count
%daisyvotes_top_alltime_3_name%	All-time #3 voter’s name

Example scoreboard line

&dVotes: &f%daisyvotes_total_votes%  &7| &dStreak: &f%daisyvotes_current_streak%
&dParty: &f%daisyvotes_current_votes%/%daisyvotes_party_required%

Note

PlaceholderAPI is optional — everything else in DaisyVotes works without it. /daisyvotes doctor reports whether the expansion is hooked.

Other plugins’ placeholders inside DaisyVotes

New in 2.8.0

Everything above is DaisyVotes supplying placeholders for other plugins to read. This is the other direction: with PlaceholderAPI installed, DaisyVotes now resolves other plugins’ %placeholder% tokens — %player_name%, %vault_eco_balance%, a rank prefix, anything — written into its own configs. Before 2.8.0 PlaceholderAPI.setPlaceholders was never called, so one of these pasted into a menu lore line or a message printed literally.

It resolves in:

• Vote-menu item name and lore, on every button and site candle (menus.yml) — see Vote Sites & Menus.
• Action bars (the vote/leaderboard/streak nudges and the points-earned feedback).
• /vote and /daisyvotes command replies.
• A reward’s Message-type value (rewards.yml) — see Reward placeholders.

The resolved value is escaped

A placeholder’s value is somebody else’s data — %player_name% for a player literally named <red>, or a rank prefix carrying its own colour codes. The resolved text is escaped before it’s inserted, so any colour codes or MiniMessage tags it contains show up as literal characters rather than being applied. This is deliberate and is the same protection that stops a player named <red> from recolouring a message they’re mentioned in — it is not a bug in the plugin providing the placeholder.

Does not resolve everywhere

• A reward’s Command value never resolves one. Splicing another plugin’s placeholder into a console command line is an injection surface escaping can’t close, so command rewards only ever substitute DaisyVotes’ own %player%-style values — see Reward placeholders.
• Resolution needs a specific player to resolve for. Server-wide broadcasts (party-progress, party-triggered, streak-milestone, a reward’s broadcast line, top-voter announcements) and Discord webhooks have no single viewer, so a placeholder in one of those is left exactly as written. Discord text is Markdown, not MiniMessage, and never reaches this renderer at all.
• shop.yml entry names and summaries do not resolve one. A shop entry’s text is built straight into the item rather than going through the message renderer, so neither a %placeholder% nor a <…> one resolves there. Use the entry’s own display-name and summary as plain text.
• Not every chat line under messages: is wired to this yet. Menu text, action bars, command replies, and Message-type reward values resolve; several of the direct per-vote confirmations — vote-received and wheel-reward-won among them — are still sent through DaisyVotes’ plain renderer and do not, even though they go straight to the voting player. If a placeholder you added to one of those isn’t showing up, this is why; the button/lore and action-bar paths above are the reliable ones today.

Messages & MiniMessage In-plugin messages use {…} placeholders, not %…%. See the difference here.