Ok upon further digging, it appears that the function you sent me will not fix the issue. The field_value filter only applies to user submitted fields and not the entry properties. Whomp Whomp Whomp (Sad Trombone)
However, there is away to do this, but it requires manipulating the core Zapier Add-on code. This actually may be something you might suggest as a change to the engineers as it’ll make sending the entry_date more flexible to the Zapier API.
The Issue
As stated above, GForms sends the entry_date in a non-valid format to Zapier. Zapier does not recognize this as an actual date and rather just a string, therefore any manipulation of the date format is impossible without first using Regex (which even with my testing failed… although it should have worked).
The Solution
In the sample data that is initially sent to Zapier for testing purposes the format is set properly and is a valid date/time format.
– gravityformszapier/zapier.php line 1302 - 1305 –
'date_created' => array( 'label' => esc_html__( 'Entry Date', 'gravityforms' ), 'sample_value' => gmdate( 'Y-m-d H:i:s' ), ),
Outputs as 2019-10-24 17:20:49
This is the reason the sample data validates in testing mode when building workflows in Zapier.
However, when the data is actually processed the Add On formats the entry_date to be user friendly and not API friendly.
– gravityformszapier/zapier.php line 788 - 790 –
if ( $property_key == 'date_created' || $property_key == 'payment_date' ) {
$value = GFCommon::format_date( $value, false );
}
Outputs as October 24, 2019 at 9:57 am
The easiest method to fix is this is to simply remove lines 788-790. I ran a test with those lines removed and it operated as expected. There really isn’t a reason to format the entry_date that way, it’s useless to the API and is only good if you want to read the date in a clever humany way, machines aren’t humans… yet. lol.
Hopefully you’ll consider making this change, if not I’ll just be sure to tell my team to not update the Add On as to not break the functionality.