Hello!
I'm assuming here, that PS only checks the name of a Block with meta-autoset: false. My players are able to customize the names of items/blocks via Anvils, and doing so lets them create PS field blocks by simply setting the title.

Can you please add a config option to check the LORE of a block before setting it as a field block? Fortunately not many of my players have figured this out yet...

I did, but we also have a plugin that allows players to colour names via Anvil. Partly for variety and customization. The issue here is many custom gear/tools on our server have custom names, which break when players try to rename them. The other issue is loot blocks with different lore, for instance an 'inactive' PS field that must be recrafted or cooked in a furnace to activate it.

The only thing I can think of the avoid this is using the Section Symbol (U+00A7 §) in coloured names for PS fields, instead of &. This might work using PS, but it would break using other plugins (Craftbook for recipes, CrateRoulette for random rewards, and EasyKits for kits containing fields.

Originally I thought PS checked both title and lore, or I would have mentioned this sooner.

Hi Omanoctoa.
§? make sure you save your other configs that break O.o when use §
instead of & as utf-8 or § will scramble up into some wierd symbol?

Maybe I read you wrong but I dont know any minecraft plugin that dont recognise § as & for color tag?

You could also try &5&r&7Block Name&r for example prefix and suffix with &r
Players would have a hard time with the &r prefix suffix and blank &5
They would just rename it as &7Block Name as &r &5 would be hidden.

Some time ago you could paste § twice into an anvil renaming box and it would unscramble
any hidden text in the item name showing the exact tags, if you have that issue on your anvils
you have no option but to use § as & can be typed into an anvil. Players that have /give
cannot give a § tagged item and again would not know there was a hidden &5 plus &r prefix suffix.

From the console
give Omanoctoa 1 1 name:&4Stone
give Omanoctoa 1 1 name:§4Stone
The items stack.

give Omanoctoa 1 1 name:§5§r§4Stone§r
Looks exactly like the above 2 but does not stack with them.

Backup your configs for custom stuff that has & as a color tag spammed in it, including pstones config.
Copy them. Open in notepad++
After a quick check to see if any other piece of config code is not using a & that you need to stay a &
find replace & with §. save all, upload and restart or /reload pluginname

If any of your items break or config has a fit because you changed & to § I will eat several humble pies in surprise... You name the flavor. Deal? :D Can players replicate the new pstones in Anvil? That would be quite special magic if they can.

Custom smelts that were done with & should stack fine with new §
triggers like holding-item 1 name:"&3Cyanara&symbol!" triggers should still work np.

Alternatively use blocks that players cannot easily get, or at all, in game.
97:5 Chiseled Stone Brick Monster Egg(minecraft:monster_egg) for example.
These are in the game in strongholds sometimes but cannot be silk touched as a 97:5
they drop as a 98:3

or make a facepalmable tedious long name such as
§a§lR§e§le§a§lg§e§lr§a§lo§e§lw§a§lt§e§lh §a§lS§e§lt§a§lo§e§ln§a§le§r

If your players cannot type unicode symbols into chat put some in the Pstone item's name. ⇨

If you have a plugin that can do something like ...
When player right clicks on block type
check inventory for certain item and if they have it do
something, anything.. including cancel the right click event?
Make it so! Any time someone tries to use an anvil while
holding that item it would cancel but then I guess someone else could just
drop a block at thier feet and it would bypass that on click trigger hrmm.

New Flag btw for lore/named pstones that have sneak place.
sneak-to-place: true
sneak-to-place-only: true#prevents accidental not sneaking placement. \o/ ya disco dancer! YES!
Good luck ey <3

I've tried a few of those ideas before and they solve the issue. I just figured checking a block's lore would make sense too, and would save having to resort to tedious and redundant use of Unicode symbols and colour symbols. :)

I didn't know about that flag though, thankyou for bringing it to my attention!