Played arround a little bit with the weight. 100 as default, which puts the hidden field behind submit actions, makes Honeypot nearly useless. -1 has for some reason a similar effect. Getting it between name and mail-Field with 2 reduced Spam to 0 (for the moment) and effectively triggering the "trap".
In my opinion this value should be configurable by the user via UI to find out which position fits best and give some flexibility over time to the user and less predictability for bots.
Also (but this is an other issue) the field label should be configurable. Last has at least some effect. I run multilingual sites and I changed the non-english label via translation, which reduced spam at least a little bit. But this may be just a subjektive point of view, so giving the user config-options adds flexibility and the comfort of best fit.
Input → created an issue.
This should fix this with #4. Also warnings from empty/missing data-view-arguments are catched.
Version 2.0.2 is also affected
I also think adding an option in this way keeps combatibility beside it's an ggod enhancement.
Thank you very much.
I'm missing the mode: create hash from given data/field value. Not like curerntly implemented: Hash the items source (row) if empty/setting applied else return data as is.
Usecase would be in combination with Feeds/ Feeds_Tamper:
I have multiple feeds (json im my case):
- Feed 1: Collection of Image URLs (no uuids provided, as actually this is some cases the same feed as e.g. Feed 2)
- Feed 2 to X: Collection of Nodes containing an property "flyer_url" which can be multiple times one out of Feed 1
Images from Feed 1 are created as Media-Entity. As I need some guid later and have none yet the only option is to create one. As PoC the URL is enough for it, but it's an Information not wanted in this way. So hashing it is best. Creating the hash from the full feed-item does not work in this context as stated below.
Reason it does not work:
Feeds 2 to X only contain the original image url. With the same intention in mind, that the full (old) url inside the db is an information without value an the has of it fullfills the perfect need, the same hashing like in Feed 1 comes into it. On Feed2 the hash-value is used to reference to the created Media-Entity via Feed-Element: Element GUID from Feed1. Currently the Hash function will create a hash over the full node entity, which will not map to the hash of the media feed guid
In this context a "Hash-Function" is a function generating a hash and not a function, which only checks if something is empty or creates a hash over a full dataset instead of a single value within this dataset. Also the current implementation "assumes" the given value is already a hash.
Same thing could apply if e.g. your uuids you have to create is a combination lets say of hashed username+email, which for shure should not be used as guuid plaintext.
Maybe you get what's in my mind.
In context of the origin it makes sence^^
Maybee it's an option tho change this to an feature request or discussion.
Implementation of the option "Create Hash from fields value" (Not complete row) analog to "Makes the value a hash of the values of item (row) being tampered."
This a least just a "simple" extension. For my desired and original understood behaviour one has to implement a complete plugin-module, which is a full copy of Hash.php except one line (return $data changed to return md5(serialize($data)); ), which is somehow complete overdose.
Input → created an issue.