Use get_input_type() when checking File Upload and Post Image fields #174
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Gravity Forms is highly extensible and this lets developers build new fields based on the existing fields. When developers do this it requires a unique string to be set for
$gf_field->type
, but in most cases you can maintain the original field's functionality by setting the$gf_field->inputType
back to the original type. This specific feature is how Gravity Forms builds add-ons like Polls and Surveys – which extend the radio and checkbox fields – and how the Custom Field post field works.This PR switches to
get_input_type()
when processing file upload and post image fields. This change will allow Image Hopper (any other fields that extend these two fields) to be correctly processed by Pods on form submission.This change should likely be done for all references to
$gf_field->type
. However, to make this PR easy to test/verify and to prevent any unexpected issues with other fields, I've limited it only to those that referencefileupload
andpost_image
types. I've a bunch of experience testing and implementing this specific change for Gravity Forms, and this modification poses a very low risk of causing an issue. I won't say no risk, because nothing is 100% certain in an ecosystem like WordPress, but I haven't discovered any breaking changes caused by making this switch elsewhere.