Add PlaceholderAPI support

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.

[mdcfe]

This PR cherry-picks commits from #1944. The differences between this PR and #1944 are:

• Performs placeholder replacement in User.sendMessage rather than in a new FormatUtil.tlp method
  • Avoids changes all over the plugin, as implemented in [WIP] Use PlaceholderAPI everywhere (mostly) #1959
• Does not include Adding EssentialsWarpEvent #1921, which is an unrelated change.
• Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

To do:

• Format placeholders in translated messages sent to the log
• Escape placeholders in mail/AFK messages
• Replace placeholders in mail/AFK formats
• Consider supporting "recipient placeholders" in formats, which are left unescaped and only parsed when received by a user?
• Escape unformatted %s in chat format
• Any other broadcast messages

Credits go to @Banbeucmas for the original PR.

Closes#1945, closes#1944, closes#1959, yada yada

[Banbeucmas]

Doesn't include replacing {...} with %...%, as that would be confusing for users when old Essentials placeholders break

While I understand the reason, but it would seem weird if the format contain {} and one contain %% in the same config file on the other hand.

[mdcfe]

@Banbeucmas It's more clear whether a placeholder comes from EssentialsX or PlaceholderAPI if they have different characters surrounding them.

[Banbeucmas]

Essentials placeholder already use uppercase character for most of the time , I think it is safe to just use {} to replace %%.
But again, we can ask whenever an user prefer %% and {} seperately or not - a poll?, I predict there will be an issue around this after the merge sooner or later. (It’s doesn’t sync with the text, so that’s what made it strange, it is reasonable to ask that)

Fixed in 4a6437e

[mdcfe]

@Banbeucmas The Essentials docs and config usually include capitalised tokens, but they are usually case-insensitive when replaced as far as I remember.

Regardless, it would be simpler for PAPI placeholders to work the same in EssentialsX as they do in every single other plugin that supports PAPI (just %%), as users will be able to just drop in the same %% placeholders that they're used to in other plugins. People also won't complain that {} doesn't work outside EssentialsX, reducing support noise.

[Banbeucmas]

I guess that will be how it's goes then. Up to you.

[extendedclip]

Using %<placeholder>% in chat format will cause an IllegalFormatException to be thrown if the placeholder is not parsed or escaped before the server handles formatting the chat message.

[mdcfe]

@extendedclip Thanks for the heads-up. I've added this to the to-do.

[mdcfe]

There are issues with the approach taken in this PR, and for that reason I'm going to close this. #2502 is a better base for this to be implemented on.