MiniPlaceholders tasks

Task guides and troubleshooting for MiniPlaceholders. Check the installed release before changing configuration or data.

Compare MiniPlaceholders output with and without an audience

A tag that works for a player can remain unresolved in a console message. Test the audience explicitly before replacing the tag or adding another expansion to the server.

Prepare the test

Choose the correct execution platform before testing a tag. A proxy and a backend can have different expansions, audiences and permissions even when the same player appears on both.

Make the change

  1. Copy one failing tag and one global tag from their expansion documentation. Keep the surrounding message short so formatting and nested tags do not hide which part failed.
  2. Use miniplaceholders parse with a connected player, then repeat with --null. On Velocity use the documented vminiplaceholders command family instead of assuming a backend command reaches the proxy.
  3. Check whether your destination supplies a player audience. A server-wide console announcement may need global data, while a per-player join message can resolve information about its recipient.
  4. Change one destination line and test it through its actual delivery route. A preview command with a sender can supply context that a scheduled or console-triggered message lacks.

Check the result

The global test should resolve global values; the named-player test should resolve values belonging to that identity. Observe a real scheduled or console-triggered delivery before treating a manual preview as proof.

If the test fails

If the destination cannot provide the required audience, restore its prior text and use a documented global alternative. Do not expose one chosen player’s private values in a message intended for everyone.

Keep the command context and the destination context in your notes. They can differ even when the same tag appears in both strings.

References and related help

Check the official MiniPlaceholders documentation against your installed release before using a command or setting from another version.

Find a missing MiniPlaceholders expansion on the correct server

A backend can show the right expansion while the proxy still lacks it. Identify where the message renders before reinstalling files or comparing expansion lists from unrelated server consoles.

Prepare the test

Choose the correct execution platform before testing a tag. A proxy and a backend can have different expansions, audiences and permissions even when the same player appears on both.

Make the change

  1. Find the plugin that owns the affected message and establish whether it runs on Paper, another supported backend platform, or Velocity. Record that instance beside the exact tag.
  2. Run the documented expansions subcommand on that instance. Compare the listed identifiers with the expansion documentation, including spelling and any dependencies required by its current release.
  3. Check startup messages for the expansion and its data provider on the same instance. An expansion jar on a different server does not make the integration available here.
  4. Add or repair only the required integration on a test copy, using its supported platform artifact. Start the test instance cleanly, list expansions again, and parse a small example before restoring the full message.

Check the result

The relevant registry should contain the intended expansion, and a direct parse should produce the expected value on the renderer’s own instance. Check the visible message afterwards with an ordinary account.

If the test fails

If the integration will not register, restore the previous artifact set and investigate its first startup error. Keep proxy and backend files separate; copying every jar to both instances can introduce unsupported deployments.

Use the expansion author’s compatibility guidance rather than treating similarly named PlaceholderAPI and MiniPlaceholders downloads as interchangeable.

References and related help

Check the official MiniPlaceholders documentation against your installed release before using a command or setting from another version.

Check a MiniPlaceholders relational tag from two viewpoints

Player relationships can depend on who views the message. A single parse for one account cannot establish that the second account will see the intended relationship or visibility state.

Prepare the test

Choose the correct execution platform before testing a tag. A proxy and a backend can have different expansions, audiences and permissions even when the same player appears on both.

Make the change

  1. Choose two test accounts with a known relationship and a harmless sample value. Record which account acts as viewer and which acts as target before issuing any comparison.
  2. Use the documented relational parsing command for the installed platform. Consult its help for argument order, then run the same tag with the two identities in opposite positions.
  3. Compare both outputs with the relationship provider. Keep a normal parse result separately so you can distinguish a missing expansion from a destination that supplies only one identity.
  4. Put the tested tag into one destination documented to support relational placeholders. Ask each player to view the other through the actual feature rather than relying on an administrator’s preview.

Check the result

Both directions should follow the provider’s relationship rules and the intended visibility policy. Record the viewer, target and result together; an unlabeled screenshot can reverse the meaning of the test.

If the test fails

If only the destination fails, return it to the previous text and check its relational support. Do not grant additional staff permissions or change friendship or team data simply to make a display look correct.

Private team or vanish information deserves a separate ordinary-player check before a public rollout.

References and related help

Check the official MiniPlaceholders documentation against your installed release before using a command or setting from another version.

Choose MiniPlaceholders or percent-style placeholders for one field

A plugin can support MiniMessage formatting without automatically supporting every placeholder system. Check the exact field’s integration documentation before converting all of its text to another syntax.

Prepare the test

Choose the correct execution platform before testing a tag. A proxy and a backend can have different expansions, audiences and permissions even when the same player appears on both.

Make the change

  1. Copy the original field into a local note. Separate formatting tags, MiniPlaceholders tags and percent-style expressions so you can identify which parser should handle each part.
  2. Check the destination plugin’s documented support and required integrations. Verify its own version and the platform where it runs before interpreting a raw tag as a missing expansion.
  3. Test one supported value with minimal formatting in a private copy of that field. Compare a direct MiniPlaceholders parse with the destination output, keeping the same test player context.
  4. Add formatting back in small steps after the value resolves. If the plugin offers different configuration paths for different parsers, select one documented route instead of nesting syntax by guesswork.

Check the result

The destination should show the intended value and formatting without literal tags or percent tokens. Test both a populated result and an empty result because an empty string can conceal a parsing failure.

If the test fails

Restore the original field when the destination does not support the chosen system. Use its supported integration or ask the maintainer about that exact field rather than replacing the whole text stack.

Keep player-entered text outside any path that treats it as trusted formatting or command content.

References and related help

Check the official MiniPlaceholders documentation against your installed release before using a command or setting from another version.

Verify a MiniPlaceholders tag after a server transfer

A player can switch backend servers while a proxy display remains active. Compare the value at each stage to determine whether the display, expansion or provider still refers to the old location.

Prepare the test

Choose the correct execution platform before testing a tag. A proxy and a backend can have different expansions, audiences and permissions even when the same player appears on both.

Make the change

  1. Choose a test account and a tag whose value should change between two test backends. Record the expected value on each server and avoid changing unrelated display settings during the trial.
  2. Parse the tag on the renderer’s instance before the switch. Transfer the player using your normal supported route, then repeat the parse and capture the visible display after its documented refresh interval.
  3. Compare the provider’s own current server or state with the parse output. If parsing has updated but the display has not, inspect the display’s refresh or cache behaviour.
  4. Adjust only a documented refresh control on a staging copy. Repeat the transfer in both directions and include a disconnect and rejoin to separate transfer-specific state from initial login behaviour.

Check the result

The displayed value should match the player’s current context within the delay you accept. Record that delay instead of assuming every integration updates in the same tick as the transfer.

If the test fails

If the change introduces excessive refresh work or inconsistent values, restore the previous interval and collect the parse-versus-display timeline for the relevant maintainer. Do not reset player identity data to repair a cached label.

Backend permission checks and proxy permission checks may differ; compare the same audience on the instance that owns the display.

References and related help

Check the official MiniPlaceholders documentation against your installed release before using a command or setting from another version.

Diagnose a MiniPlaceholders tag that breaks only for one rank

A tag can fail for one rank while remaining correct for staff. Compare the provider’s data and the destination’s access checks before changing rank inheritance or granting broad permissions.

Prepare the test

Choose the correct execution platform before testing a tag. A proxy and a backend can have different expansions, audiences and permissions even when the same player appears on both.

Make the change

  1. Pick two ordinary test accounts with different intended ranks. Copy the exact tag and record whether each account can use the destination feature independently of the tag’s output.
  2. Parse the tag with each named audience through the installed platform’s documented command. Compare the result with the data provider’s own rank or metadata value for the same account.
  3. Check the destination plugin’s permission requirements separately. A denied menu opening and an unresolved text value are different failures, even when the player reports them together.
  4. Apply the smallest documented permission or metadata correction to the test rank. Repeat the named-audience parse and actual destination test without operator status or a wildcard permission.

Check the result

Both accounts should receive the values and access their roles permit. Confirm that the restricted account still cannot use administrative features after the display starts working.

If the test fails

Remove the temporary test permission if it did not address the failing layer. Restore the previous metadata value if the correction affected another feature, and preserve the comparison results for support.

An administrator preview can bypass destination restrictions. Keep ordinary-player evidence in the final test notes rather than relying on a staff screenshot.

References and related help

Check the official MiniPlaceholders documentation against your installed release before using a command or setting from another version.