PlaceholderAPI tasks

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

Compare a PlaceholderAPI result for two different players

A balance or rank line can look correct for staff while showing another value for players. Compare the same expression with explicit player context before changing the display plugin or editing anyone’s account data.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Choose two connected test players with a known difference, such as different ranks. Write down the exact expression from the affected display, including its percent signs, rather than retyping a similar placeholder.
  2. Use the documented papi parse command with each player name and the same expression. In game, commands start with a slash; the server console normally expects the command without that slash.
  3. Compare the parsed output with the underlying permission or economy provider. If both players return the same value, check what that expression measures before assuming the provider has lost their records.
  4. Put the verified expression into one private menu or scoreboard line. Refresh that display using its supported method, then ask both players to observe the same line while remaining connected.

Check the result

Success means the raw parse and the visible display agree for each test identity. Keep screenshots of the two results without showing balances or ranks belonging to uninvolved players. Record which account produced each result.

If the test fails

If direct parsing works but the display differs, restore the previous display line and investigate that plugin’s audience or refresh settings. Do not replace player files or reset economy records to repair a presentation problem.

Console parsing needs a named player when the expression uses player data. A console-only or null-audience test can produce an empty result without proving that the expansion has failed.

References and related help

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

Test which PlaceholderAPI expressions need a player context

A scheduled announcement may run without a player even though the same text works in chat. Find which parts need an online identity before changing the whole announcement or granting more permissions.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Copy the announcement into a private note and separate fixed text from each expression. Pick one known server-wide value and one player-specific value to avoid debugging a long mixed message.
  2. Parse the server-wide expression with the documented --null context. Parse the player expression with an explicit connected test player. Compare results without broadcasting the message to everyone online.
  3. Check how the announcement plugin supplies context to PlaceholderAPI. A global timer cannot infer whose balance or rank you meant; choose a server-wide expression or a genuinely per-player delivery feature.
  4. Update one announcement only, preserving its previous text and schedule. Observe a scheduled run and a manually triggered run because a manual command may have a sender that the timer lacks.

Check the result

The scheduled output should contain a sensible value without exposing one player’s data to the server. Verify a later timer run rather than treating an administrator’s immediate preview as the complete test.

If the test fails

Restore the previous announcement if the scheduled path remains blank. Gather the exact expression, parser context and announcement plugin version, then investigate the integration instead of downloading unrelated expansions or changing player records.

Keep private values out of global messages. A successful named-player parse demonstrates that one player’s data resolves; it does not make that value appropriate for a public scheduled announcement.

References and related help

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

Identify a built-in PlaceholderAPI expansion before downloading another

Some plugins register their own expressions with PlaceholderAPI. Downloading a similarly named expansion can add confusion without repairing the original integration. Identify who owns the expression and what is already registered.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Find the affected expression in its author’s documentation. Note whether the author describes an eCloud download or a built-in integration, and record the exact identifier before changing the server.
  2. Compare papi list with the installed list shown by papi ecloud list installed. The registered list can include integrations supplied by another plugin, so a difference between these lists is not itself an error.
  3. Check the startup log for the owning plugin and its integration registration. A plugin that failed earlier may leave its expressions unavailable even though PlaceholderAPI itself started without a warning.
  4. Follow the owner’s documented dependency route on a staging copy. Add an eCloud expansion only when the documentation calls for it; otherwise repair the owning plugin’s actual startup failure.

Check the result

The intended identifier should register once and produce a value in a direct parse for a connected test account. Check the consuming display afterwards, since its configuration can still contain a misspelled expression.

If the test fails

If an added expansion did not help, remove only that test addition through the supported management method after recording its filename. Preserve the owning plugin’s data and previous expansion set while you investigate the first startup error.

A download catalogue and an active registry answer different questions. Use both as evidence, and avoid treating an absent eCloud entry as proof that a built-in integration is missing.

References and related help

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

Pin one PlaceholderAPI expansion update for a staging test

An expansion update can change an expression’s output while the menu or scoreboard stays the same. Test one expansion release against recorded values before replacing several integrations during the same maintenance window.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. List the target expansion’s information and note its current version. Save its original jar and any related settings, then make a staging copy with separate credentials for external integrations.
  2. Use papi ecloud info with the expansion name and requested version to check the release details. The documented download command accepts a version argument; confirm that release exists before selecting it.
  3. Download only the selected release on the test server and follow PlaceholderAPI’s documented registration or reload procedure. Do not use a general server reload to substitute for a plugin’s supported update path.
  4. Parse a small recorded set of expressions: a populated value, an empty value and a player with different permissions. Compare formatting, number types and error messages before testing the consuming display.

Check the result

Approve the update when the expressions retain the meaning your displays expect and the log shows no repeated registration failures. Record the tested expansion version beside the server and provider versions for the next update.

If the test fails

If output changes break a display, restore the previous expansion jar and matching settings using a controlled stop and start where appropriate. Keep the new file separately for investigation rather than repeatedly swapping versions during live play.

Treat an expansion and its data provider as a pair. A newer expansion cannot make an unsupported provider version compatible, and a successful download does not prove that the integration works.

References and related help

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

Check a relational PlaceholderAPI value in both directions

A relationship expression can produce different output depending on who views whom. Friendship, faction or visibility displays need a deliberate viewer-and-target test rather than a single ordinary player placeholder check.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Choose two consenting test accounts and write down the relationship you expect each to see. Use a harmless pair with no private staff information, and copy the exact relational expression from its documentation.
  2. Use the documented papi parserel command with the first player as the viewer and the second as the comparison target. Repeat with the names reversed while keeping the same expression text.
  3. Compare those results with the provider’s own relationship state. If the output differs by direction, determine whether that is expected before changing groups, teams or protection membership.
  4. Test one display that explicitly supports relational placeholders. Ask both accounts to view each other, and inspect whether the integration supplies both identities rather than parsing a normal single-player string.

Check the result

Both viewers should receive the value their relationship permits, with no leakage of hidden staff or team status. Capture the input order with each result so a later support report does not reverse the evidence.

If the test fails

If direct relational parsing succeeds but the display stays raw, restore the old display text and check that integration’s documented support. Do not replace relational syntax with a guess or grant the viewers elevated permissions to hide the symptom.

A successful ordinary parse does not test the second identity. Keep viewer, target and provider relationship state together in your notes when comparing behaviour after a plugin update.

References and related help

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

Remove an unused PlaceholderAPI expansion without breaking displays

An expansion that looks unused in chat may still supply a shop menu, hologram or staff scoreboard. Build a reference list before retiring it so the cleanup does not leave raw tokens in player-facing text.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Record the expansion’s exact identifier and current jar filename. Search your text configurations for its expression prefix, including disabled menu files and scheduled announcements that run less often than normal gameplay.
  2. Map every match to its owning display or command. Decide whether to remove that line, replace its value, or retain the expansion; do not assume that an infrequently opened staff menu is irrelevant.
  3. On a test copy, use the documented unregister operation with the precise expansion filename when that operation applies. Keep the jar outside the active expansions folder so a restart cannot silently register it again.
  4. Open the affected menus and inspect each listed scoreboard, hologram and announcement. Check an ordinary player and a staff account, including conditional displays that become visible only after a requirement succeeds.

Check the result

Cleanup succeeds when no active configuration depends on the retired identifier and normal displays contain no raw expressions. Restart the test server once to confirm that the remaining registry and displays still agree.

If the test fails

Restore the saved expansion file and supported registration state if a missed dependency appears. Repair the reference list before retrying removal; keep the rollback local to this expansion rather than replacing the whole PlaceholderAPI directory.

Built-in registrations belong to their owning plugin rather than a standalone downloaded file. Do not remove another plugin merely because its integration appears in the registered expansion list.

References and related help

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

Reduce repeated PlaceholderAPI work in a busy scoreboard

A scoreboard can request many values every refresh even when most values rarely change. Measure the display workload before blaming PlaceholderAPI for all server lag or increasing refresh speed to chase stale-looking output.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Create a quiet test window and record the scoreboard’s configured refresh intervals and expressions. Separate fast-changing values, such as a timer, from slow-changing values, such as a rank name or total playtime.
  2. Use a server performance report to identify whether the provider or display appears in the expensive work. Keep the same player count and avoid generating terrain during the comparison so unrelated load does not dominate.
  3. Copy the scoreboard and lengthen the display plugin’s documented interval for the slow-changing lines. Remove one optional expensive expression at a time; do not invent a universal PlaceholderAPI interval setting.
  4. Compare the new report and visible update delay with the baseline. Test after a real rank or balance change so you can judge the delay players experience rather than only observing unchanged values.

Check the result

Keep a change when the display remains understandable and measured work falls under comparable conditions. Record the interval, affected expressions and expected delay so another administrator does not reverse the change as a suspected fault.

If the test fails

Restore the previous scoreboard interval if the delayed information harms gameplay. If the provider still performs expensive queries, investigate that integration with its author using a redacted profile rather than stripping unrelated expressions from every display.

The consuming plugin controls many refresh decisions. Use the CloudExa lag guide for evidence collection, and keep provider version, player count and test duration consistent when comparing results.

References and related help

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

Share a useful PlaceholderAPI support report without player data

A useful report shows which expression failed, which player context you supplied and whether the provider started. A large unreviewed log can disclose player names, network addresses or integration details that support does not need.

Prepare the test

Keep the original placeholder text beside the result during diagnosis. The expansion supplies the data; the scoreboard, menu or chat plugin decides where and how to display that result.

Make the change

  1. Record the server build, PlaceholderAPI version, provider version and affected display plugin. Keep the exact expression in a private note and reproduce the failure with a disposable test identity where the provider permits it.
  2. Capture a direct parse result and the corresponding startup registration messages. Include the first relevant error and its surrounding cause chain, rather than sending hundreds of repeated follow-up exceptions.
  3. If you use papi dump, understand that it uploads environment information to a paste service. Review what the report contains and use a private support route when it includes information you do not want public.
  4. Attach a short reproduction sequence and the expected result. State whether the failure affects one account, all accounts, console-only output or only a particular display; those distinctions narrow the integration path.

Check the result

A reviewer should be able to identify the failing layer from your report without receiving passwords, account balances or a full unredacted player list. Confirm the shared link is the intended report before submitting the ticket.

If the test fails

If a report exposed a secret, restrict or remove access where the service allows it and rotate that secret through its owner. Do not regenerate repeated public dumps as a substitute for collecting a smaller redacted example.

CloudExa support can inspect your hosting service, but the plugin maintainer may need the same version and parse evidence for an upstream bug. Keep that evidence independent of customer credentials.

CloudExa game panel console and logs view for collecting startup and diagnostic evidence
Collect the relevant timestamped log text in the panel, then remove private data before sharing it with support.

References and related help

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