I may be going blind but I can’t find anywhere in the docs where it details how to remove the user fields from an entry - I have a form within a login area and I absolutely cannot track the user through the form submission. I’ve managed to turn off the IP under personal data but am I missing something??
Are you referring to the user login in the entry info metabox? https://d.pr/i/QYe0XX
That isn’t stored in the entry. Out of the box the entry only records the ID of the logged in user in the created_by property. That ID is then used to retrieve the user login to be displayed in the metabox.
There isn’t a way to prevent the ID being saved for logged in users but you could delete it as the submission is completing e.g.
add_action( 'gform_after_submission', function ( $entry ) {
GFAPI::update_entry_property( $entry['id'], 'created_by', '' );
} );
Hi Richard
Thanks for coming back to me, really appreciate any help or tips that you’re able to give me
Yes, it’s that field that I need to either remove or overwrite. I’ve just tested the function that you posted and it doesnt seem to do it. It still shows the username (as you say, from the ID) The DB still shows new entries with created_by being populated by ID. I tried setting the created_by in your function to 0 instead of empty to see if that would work but it doesn’t overwrite with 0
Strange, it’s working with the empty string and 0 on my test site. Perhaps it’s an issue with the code snippet location. If you have added it to the theme functions.php file try moving it to a custom functions plugin.
actually that’s a really good point - I was just being lazy and testing it in the theme - I’ll try that within a custom plugin and see if that works.
It still didn’t work but as it worked on yours I figured I must have a conflict somewhere. I’m using Gravity Forms Encrypted Fields and deactivating that means that the function you’ve provided above works fine! 
I wonder whether I can force the gform_after_submission to run last after everything else has run, including the encryption. I’ll have a play around but if you have any ideas feel free to shout 
I set the priority to 10000 and it still didnt work. I wonder whether the plugin is finding the highest priority and setting itself to a higher priority to force itself to run last. Meh.
Hi Richard
I think I’ve tracked down the issue. The script works fine, but despite setting the highest priority, the Encryption plugin fires last:
2020-06-26 14:17:27.848217 - DEBUG --> customFunc_obscure_user(): prepare to set created_by to 10
2020-06-26 14:17:27.854262 - DEBUG --> customFunc_obscure_user(): done. Set it to 10
2020-06-26 14:17:27.854383 - DEBUG --> customFunc_obscure_user(): all done, moving on
2020-06-26 14:17:27.864633 - DEBUG --> GFAPI::update_entry() - form #2: entry 51 field data encrypted.
2020-06-26 14:17:27.873435 - DEBUG --> GFAPI::update_entry() - form #2: entry 51 field data deleted.
I think they must be storing the entire form entry waiting until everything else has finished and then updating the whole thing including the created_by field from what they stored in memory. I’ve reached out to them for a solution but I did wonder whether it was possible to hook into the created_by entry field and set that manually whilst the form is processing and before they start to capture things for their use?
Update: they said to set priority to
99999991, 2
and when this still didnt work, they said to set it to:
9999999999, 2
Just for people’s reference, (and I have never ever seen a plugin require you to set a priority this high to get round their own priorities before), they first suggested a priority of 99,999,991 (100 million!) and then upped this to 9,999,999,999 which is basically a priority instruction of 10 billion.
It works… which is nice… but really? 
1 Like