robrandell

Hi,
OK, no problem. Thanks for checking and quick response.

Thanks,
Rob
—

I had same issue with the page editor crashing with a CF7 block. Relayed the information needed in a later thread. Rolling back to v5.5.3 and using the default shortcode block solved the issue for me. Thanks.

I’m seeing the same issue also. On first load of the editor, the block states it has an error and cannot be displayed. Delete the block, reinsert the block and reselect the contact form then save. Come out of the page, then back in, white screen of death.

Create a new page, insert block, publish. Go back into the page, the block states it has an error and cannot be displayed. Replace block and resave. Come back out then into the page again, white screen with the same error.

Create a new page, insert CF7 block only, publish. Go back into page editor, white screen. Same error.

TypeError: Cannot read properties of undefined (reading '0').

This error only occurs within the admin backend of the website, the frontend appears to be unaffected as the form displays.

Deactivated all plugins, I can reopen the page for editing. Reactivate all plugins except Contact Form 7 and I can reopen the page for editing with no errors logged in the console. Seems to be a error within the CF7 plugin.

WP v5.8.3
Ngnix hosting
Custom theme (with custom blocks)
PHP v7.4

Plugins used:
– Admin Menu Tree Page View Version 2.7.6
– Advanced Custom Fields Version 5.11.4
– Contact Form 7 Version 5.5.4
– Honeypot for Contact Form 7 Version 2.1
– ReCaptcha v2 for Contact Form 7 Version 1.3.7
– Redirection Version 5.2.2
– Simple Custom Post Order Version 2.5.6
– Simple History Version 3.1.1
– Yoast SEO Version 18.0

This has occurred on a staging and a live version of the website. I can confirm that on a local copy, the plugin functions correctly. Rolled back to v5.5.3 and the issue still persists but deactivating the plugin resolves it again. Attempted to use the default ‘Shortcode’ block instead of the ‘Contact Form 7’ block, same issue with v5.5.4.

However, rolling back to v5.5.3 and using the default ‘shortcode’ block appears to completely solve the issue, at least for me. I can reopen the page again with all plugins activated.

Hope this information proves useful.

Thanks,
Rob
—

Thanks. I knew I was staring at it for too long.
The other problem was the $post->ID was a null object, so I switched it to get the meta data of the submission, specifically the container_post_id. Final code below if it helps anyone else.

function add_jobmanager_recipient($cf7)
{
    $submission = WPCF7_Submission::get_instance();

    if ($submission) {
        $data = $submission->get_posted_data();
        $cc_email = get_field(
            'job_contact_email_address',
            $submission->get_meta('container_post_id')
        );

        if (empty($data) || empty($cc_email)) {
            return;
        }

        $mail = $cf7->get_properties();
        $mail['mail']['additional_headers'] .= "\r\nCc: $cc_email";

        $cf7->set_properties($mail);
    }
    return $cf7;
}
add_filter('wpcf7_before_send_mail', 'add_jobmanager_recipient', 10, 1);

Thanks,
Rob
—

Figured out the blank email issue. There is two forms on the website and a check for the id for the form being used. That method for retrieving the id has been updated. The system didn’t know which form was being used so the hook applied to both and not just the one form as intended.

$wpcf7 = WPCF7_ContactForm::get_current();
$form_id = $wpcf7->id();

Thanks tonydjukic. I have rolled back to v5.3.2 and will see how that fares.

The latest plugin was causing issue on another site in development flagging up the wp classes not being found and the api-fetch not working, deactivated the plugin and the errors ceased. So, rolled that one back too.

Thanks,
Rob
—

Hi,
I too use this hook for the same purpose but it still appears to be working. Does the external database not send a response back from the post request? There does appear to be some issue with v5.4 too so perhaps rollback the plugin to see if it fixes it.

Thanks,
Rob
—

I am also have the same issue, using Google reCaptcha v2, we are getting the occasional blank submission. I asked the website host to look into it, this is what they came back with below. The website handles the request using the ‘wpcf7_before_send_mail’ hook and this function further checks for blank fields and sends the data to a CRM API.

When we check the IP (23.94.28.28) against Abuseipdb.org, it looks like this IP has been known to spam contact forms before. We’ve gone ahead and blocked it from accessing your server going forward.

It looks like this is a malformed request, as it’s getting a 404 on the site but CF7 seems to still be “listening” for the submission (which the spammers are probably aware of) and still processes the POST data despite not handling a response.

We recommend checking with the CF7 folks to see if there is a remedy for that behavior.

If you are using the standard ‘wpcf7_before_send_mail’ hook to process the submission data, the submitted values are wrapped within an array and you can return the value simply be referencing the zero key, i.e. $posted_data[‘fieldname’][0]. I am unsure if this applies to checkbox groups in the same way, it seems to work for all other form fields though. You could try $posted_data[‘checkboxgroup’], $posted_data[‘checkboxgroup’][‘checkboxvalue’] or $posted_data[‘checkboxgroup’][‘checkboxvalue’][0] and see if that helps.

Thanks.

• This reply was modified 4 years, 1 month ago by robrandell.
• This reply was modified 4 years, 1 month ago by robrandell.

You will need jQuery/JS to add the ‘selected’ attribute to the dropdown so the correct option is selected dependant on the page being viewed. It may well need another hidden field to be populated with that value on the page load so the JS can get that value then apply the change to the dropdown.

.pid is the class of the hidden field or hidden HTML element with the value required.
.interestedin is the class of the dropdown.

if( $( '.pid' ).length > 0 && $( '.interestedin' ).length > 0 ) {
    var id = parseInt( $( '.pid' ).text() );
        $( '.interestedin > option' ).each( function() {
            if( id === parseInt( this.value ) ) {
                $( this ).attr( 'selected', 'selected' );
            }
        });
    }

Either that or simply strip the dropdown out altogether and have the field auto populate with the correct value when the page loads and prevent the user of changing it, i.e. disable the field.

Hi,
I have the same issue.

$posted_data = $submission->get_posted_data();
$post_title = array(‘post_title’ => $posted_data[ ‘yourtitle’ ], …)

The above used to return ‘Mr’, ‘Mrs’, etc. It now returns ‘array’ after the update. The dropdown values are used for routing custom emails to various recipients and this process is now broken. I can confirm that single text fields seem unaffected.

EDIT: It appears that the dropdown value are now returned wrapped within array, the selected value is simply at the zero key, ie. $posted_data[‘yourtitle’][0].

Thanks.

• This reply was modified 4 years, 5 months ago by robrandell.
• This reply was modified 4 years, 5 months ago by robrandell.

I have the same issue. I have noticed an earlier post with the same issue saying that the job must go through a validation process with Indeed before the button can appear. But the moment, the Chrome broswer returns an error ‘Failed to execute ‘postMessage’ on ‘DOMWindow’: The target origin provided (‘https://apply.indeed.com’) does not match the recipient window’s origin https://stpiusx.co.uk/’).

The full link for example is https://stpiusx.co.uk/indeed-jobs/0ebc7325c6e128d9bfe9/administration-assistant/.