Rick Curran

@inmoeduca I did have a problem with attachments not being sent, but in this case it turned out to be some other code I had in place which was affecting the posted data of the forms, so it doesn’t seem like an issue with the plugin itself. I was able to comment out the code causing the issue as it was no longer needed for the website. This code previously used to work, so something has changed either with WordPress itself or with this plugin, so at some point I may need to look into it further, but for now I have resolved my issue by removing the problematic code.

In my case I used PHP error_log calls to take a look at the data being submitted to the form in order to see what was being submitted, so if you know your way around PHP a bit you could try something similar to see what is actually getting submitted in the form.

@inmoeduca Sorry, is the issue that the attachment is not coming through with the email that’s being sent? If so I’m also trying to debug a similar issue so I was looking here in the forums to see if anyone else is having the same issue.

Thanks!

@saxpaolo In your function you get the array for form data using:

$form_data = $submission->get_posted_data();

But in then it looks like you’re trying to get the value of a text field in this line:

$text = isset($data['contact-form--message']) ? $data['contact-form--message'] : "";

Shouldn’t that be $form_data['contact-form--message'] rather than $data?

I want to say that I am also experiencing this issue an a site. I am struggling to consistently reproduce the issue on test pages, however on the page the issue is occurring it has resulted in loss of most of the saved block data, with almost 70 Services blocks columns in that page it is a significant bit of data loss.

@cookieyesteam Thank you for directing me to that thread, I have now been able to migrate from the legacy version.

The only minor issue I encountered is with the markup for the main Cookie Notice text, the “Cookie Policy” link text is rendered within the paragraph of the Cookie Notice text. This prevented me from styling the banner in the same way as I had it working pre-migration, previously I had the “Cookie Policy” link rendered more as a button below the main text, but this was not so easy to do as it would be if this link was outside the paragraph of text. However, with the main focus to get the cookie banner keyboard accessible I have just gone with a simpler layout.

Thanks again for point me to the migration process.

<EDIT> Sorry, I had mistakenly referenced an older support thread I had thought related to this but I was mistaken.

• This reply was modified 11 months, 4 weeks ago by Rick Curran.

@iqcomputing Great, thanks for the response, much appreciated!

@iqcomputing Ah ok, thanks for making this work for V2, in this case my client only wanted reCaptcha on one form and also wanted the visible “I’m not a robot” checkbox to be visible as well!

One thing to note about the wording in the settings in the “reCaptcha Version” panel, the first sentence does give the impression that you can use either version of Recaptcha but that you still need to use the [recaptcha] shortcode:

Select the version of reCaptcha you would like to use. You will still need to use the?[recaptcha]?shortcode tag in your Contact Form 7 forms.

Is this not correct? It does make sense that V3 would apply to all forms, if using the default reCaptcha V3 (and therefore applied to all forms) then it would seem like there’s no need to use this plugin at all?

@maximeschoeni Thanks, that seems to be working correctly! The nav menu items are left untouched but get_permalink and also paginate_links links are keeping the language string in them still.

Thanks again for that code, I’d tried to figure out which action or filter I might be able to use but I didn’t come across that pre_wp_nav_menu filter.

@maximeschoeni Sorry to chase this again, but just to say that I have tried the code example you suggested and it does almost do what I need. The only issue is that it also removes the language string (e.g. ‘es’) from any?get_the_permalink?calls within the page. I was wondering if there was a way to specifically target only the links generated within?wp_nav_menu? Thanks again for your help!

@maximeschoeni I have tried the code you’ve suggested and it almost works for what I’m trying to do, however it also removes the language string (e.g. ‘es’) from any get_the_permalink calls within the page. Is there a way to specifically target only the links generated within wp_nav_menu?

@maximeschoeni Thanks for the reply! I basically just want all menus in the site to just stay to the default language and never insert “/es/” into any of the urls. So not just links to the homepage but any link generated within a wp_nav_menu. Is this possible?

@ohhcee Yep, something like that could work.

I was keen to find something that can do a test using JavaScript as well, CF7 does fallback to regular form submission if JavaScript is not available for some reason but there is a chance that a JS error could cause the form not to be submitted.

However, the error that originally prompted this question was a backend issue, so any contact form submission failure would have been noticed if I’d had any way to track it.

@ohhcee No, I’ve not really looked into it since I posted this question. Let me know if you come across anything, I would still like to find a way to monitor this.

https://github.com/voceconnect/multi-post-thumbnails/pull/154