• Hello,

    I’m trying to track down a strange issue across multiple plugins…

    TL;DR Is there any reason why a new instance of WPCF7_Validation() wouldn’t recognize a custom tag?

    In ReCaptcha v2 for Contact Form 7 I am creating a custom tag via wpcf7_init

    function iqfix_wpcf7_add_recaptcha_tag() {
    
    	wpcf7_add_form_tag(
    		'recaptcha',
    		'iqfix_wpcf7_recaptcha_form_tag_handler',
    		array( 'display-block' => true )
    	);
    
    }
    add_action( 'wpcf7_init', 'iqfix_wpcf7_add_recaptcha_tag', 20 );

    The creation code works great and as expected.

    Except whenever another plugin Conditional Fields for Contact Form 7 does the following:

    function skip_validation_for_hidden_fields($result, $tags) {
    
    	$invalid_fields = $result->get_invalid_fields();
    	$return_result = new WPCF7_Validation();
    
    	foreach ($invalid_fields as $invalid_field_key => $invalid_field_data) {
    		$return_result->invalidate($invalid_field_key, $invalid_field_data['reason']);
    	}
    
    }
    add_filter( 'wpcf7_validate', 'skip_validation_for_hidden_fields', 2, 2 );

    Some code is removed for simplicity purposes to encapsulate the question better.

    If I error log $invalid_fields, I see that an error exists on submission as it should if the user does not check the ReCaptcha box. Whenever I error log WPCF7_Validation::invalidate() for the $return_result variable though, it doesn’t recognize the ‘recaptcha’ as a tag. In any other case, it does recognize the tag. What happens is that WPCF7_Validation::invalidate() returns early here:

    includes\validation.php LN 27

    if ( empty( $name )
    or ! wpcf7_is_name( $name ) ) {
    	return;
    }

    With the creation of the new instance, it can’t seem to get new WPCF7_FormTag( 'recapthca' ) at this point.

    Is there any reason creating a new instance of WPCF7_Validation() during the wpcf7_validate hook would not recognize custom-created tags?

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Takayuki Miyoshi

    (@takayukister)

    Isn’t it simply that the “Conditional Fields for Contact Form 7” plugin uses the wpcf7_validate filter hook in an improper way? I don’t understand why its filter callback function returns nothing.

    Thread Starter Howdy_McGee

    (@howdy_mcgee)

    Hello,

    My apologies for the confusion; it was late night writing that up. The function does return the newly created validation object at the end of the function call. I missed that when removing their unnecessary code for the above example since their code is a bit lengthy.

    I think I’ve been able to narrow down the root of the issue further.

    WPCF7_Validation::get_invalid_fields() returns a correct array of invalid fields initially. When the above code example loops the invalid fields to pass a $context, the WPCF7_Validation::invalidate() method scans for tags by name:

    $tags = wpcf7_scan_form_tags( array( 'name' => trim( $context ) ) );

    The recaptcha field doesn’t have a field name since only 1 can ever be on a form. It seems like invalidate method cannot find the WPCF7_FormTag because it’s specifically looking for it by name. The strange thing is that if I used ReCaptcha normally, it does process the error message as expected. It does exist in the returned array from WPCF7_Validation::get_invalid_fields() keyed as ‘recaptcha’.

    Should a fallback be in place if a WPCF7_FormTag name is empty to check against the type whenever scanning for tags? This would check the FormTag type against the $cond whenever it finds that the name is empty.

    The alternative is to give the ‘recaptcha’ field a name, but this, unfortunately, won’t apply to backward compatibility, and I’m not sure it makes sense since there can only be 1 in a form. This is what I’ve concluded so far; I’m certainly open to hearing your suggestions on the best course of action.

    Plugin Author Takayuki Miyoshi

    (@takayukister)

    Why don’t you just deactivate the “Conditional Fields for Contact Form 7” plugin? Without it, your custom form-tag works as expected, right?

    Thread Starter Howdy_McGee

    (@howdy_mcgee)

    While deactivating the other plugin would work, it doesn’t appear to be the root of the problem described in my previous reply. From the sound of it, ensuring that the custom tag has a name is the way to go to work around this issue then.

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Custom Tag Not Found’ is closed to new replies.