worldguard bug

[Sneyzi]

Describe the bug
The plugin forcefully cancels the BlockPlaceEvent at the beginning of SkullBlockListener#onSkullPlace when WorldGuardHook.isAllowedPlace(...) returns false. This makes it impossible for other plugins to override or conditionally allow the placement later in the event pipeline, even if they use event.setCancelled(false) on higher priorities.

This behavior conflicts with any plugin trying to integrate or cooperate with WorldGuard, such as custom protection systems, donor privileges, or placement limit systems.

To Reproduce

1. Set up a server with WorldGuard and Skulls.
2. Deny building in a region using WorldGuard.
3. Create or install a plugin that listens to BlockPlaceEvent at EventPriority.HIGHEST or MONITOR, and uses event.setCancelled(false) or event.setResult(Event.Result.ALLOW) if certain conditions are met.
4. Attempt to place a skull from the Skulls plugin in the region.
5. The placement is still blocked due to Skulls plugin cancelling early — even though WorldGuard would have been overridden by another plugin.

Expected behavior

• The plugin should not cancel the event before checking if the item is a skull from this plugin.
• Ideally, the WorldGuard check should happen after confirming the item has Skulls:ID tag, and only for plugin skulls.
• Even without this check, WorldGuard still blocks placement, so this logic is redundant and unnecessarily blocks compatibility with other plugins.

Suggested Fix
Change this:

if (!WorldGuardHook.isAllowedPlace(event.getPlayer(), event.getBlock())) {
    event.setBuild(false);
    event.setCancelled(true);
    return;
}

To something like:

final ItemStack item = PlayerUtil.getHand(event.getPlayer());
if (item == null || item.getType() == CompMaterial.AIR.parseMaterial() || item.getAmount() == 0) return;

if (!NBT.get(item, nbt -> (boolean) nbt.hasTag("Skulls:ID"))) {
    return;
}

// Only cancel if it's a plugin skull
if (!WorldGuardHook.isAllowedPlace(event.getPlayer(), event.getBlock())) {
    event.setBuild(false);
    event.setCancelled(true);
    return;
}

Or better yet — remove the WorldGuard check entirely, and let WorldGuard manage protection on its own.

Screenshots
N/A

Server Information

• Server: Paper 1.21.4
• Plugin Version: 3.25.0
• Other Plugins: custom plugin with WorldGuard support

Additional context

• This issue causes incompatibility with any plugin trying to override WorldGuard behavior.
• The current check is redundant, since WorldGuard handles placement restrictions internally.
• By removing or deferring this check, the plugin becomes more modular and compatible with other server setups.

[Sneyzi]

sorry, duplicate of this issue but more detailed