geertvanderheide

I posted this here but I also contacted Tussendoor Support. So this issue is already fixed by your support team. Thank you for the assistance.

I’m experiencing the same problem as well. The In3 logo shows up in some browsers but not others. Safari on Mac is a problem, and some mobile browsers, too. Really hoping this will be fixed soon.

Very good to hear that this change is planned. I’ve commented out the relevant lines in the meantime. Thread resolved.

I’ve tried the plugin again, and it’s working well for me now. Thank you for offering this plugin, and for fixing this issue.

Thanks for your reply. I went through the dropdown again and I found the brand taxonomy. It now works perfectly.

Thank you, I’ve created an issue on GitHub to request this feature.

Glad I could help ?

You can use the do_shortcode function:

// Place this in header.php in your theme at the desired position, then style with style.css
echo do_shortcode( '[example-shortcode maybe_a_parameter="91" or_even_two="true"]' );

Thank you for your reply! With your example I was able to make it work.

Just a tip for the future: you might want to consider implementing a custom Javascript event like “ahbFormReady” or similar, then firing it when the form is fully loaded and ready, so that setTimeout checks are no longer necessary. It’s not a huge thing, but it could make things even better.

Installed and tested: everything works again! Thank you for the very quick turn-around on this. Excellent support!

I’m experiencing the same problem. I’m using Theme My Login and this TFA plugin.
Using free version 1.4.7, so no trusted devices. Through TML I’ve activated the option to only allow the e-mail address + password (not username). The username is different from the e-mail address and is not in e-mail format, and user name is not used to login as stated so it should be irrelevant. I can just input anything or nothing into the verification field after that. It logs me in regardless.

Addition info: using Google Authenticator 5.0, which seems to be set up correctly. The code shown on the profile matches the one in Google Authenticator. I’ve also tried disabling TFA, then removing the item in Google Authenticator, re-scanning the QR code and then re-enabling TFA. Re-activating works in and of itself, but doesn’t solve the issue. The verification field is asked, but I can input any code or nothing at all and still log in.

This is an urgent problem and I don’t see anything on my end that could be causing it. It’s supposed to work and it doesn’t. Could you do some testing and report back?

• This reply was modified 5 years, 9 months ago by geertvanderheide.
• This reply was modified 5 years, 9 months ago by geertvanderheide.
• This reply was modified 5 years, 9 months ago by geertvanderheide.

@southscot-gaz: If you’re seeing a green message after submitting a form, then the message should be sent. If you are seeing the (default orange) message “There was an error trying to send your message. Please try again later” then the submission was marked as spam and in those cases, nothing is sent.

If reCAPTCHA is the only spam protection you use, then that’s what’s marking your submissions as spam. There seems to be an issue with CF7 5.1.1 right now where all submissions are marked as spam, and you may be having this issue.

Make sure you’re using reCAPTCHA v3 keys – they’re different from v2 keys and you need to create a new v3 set in the reCAPTCHA console to work with CF 5.1+.

Also make sure your theme has a call to wp_footer() at the bottom of every page (usually in footer.php), so that scripts can be properly loaded.

For me though, I’ve followed these instructions and still every message anyone tries to send is marked as spam. You may be having the same issue, and if the above doesn’t help then you may have to disable reCAPTCHA until another CF7 update comes out.

I’m not sure how to solve this for multi-site, or why the cookie domain doesn’t just work out of the box for you like it does for others.

Here are some things you can try though, from others with this isssue:

https://danielbachhuber.com/2016/07/07/fixing-cookie_domain-for-mapped-domains-on-multisite/

https://wordpress.stackexchange.com/questions/259839/cookies-in-multisite-where-network-sites-have-their-own-domain-name

I’d suggest trying some of the snippets provided in those links, and removing them again if they don’t work. Remember to delete cookies often when testing, and if you are using a caching plugin it may also be involved (maybe try with it disabled). If nothing works then it may be an issue with your hosting configuration, in which case I’d ask your host about it.

Unless the author of this plugin has any more suggestions. I’m out of ideas – good luck!

• This reply was modified 5 years, 11 months ago by geertvanderheide.

Hey @joelschmid,

That’s not the specific problem I’ve run into. On the sites I’m using, the cookie always has the base domain set correctly, without a path, so that it applies to all pages of the site. Weird how that doesn’t seem to be happening for you.

Looking at the code for this cookie plugin, it looks like it’ll use a constant for the cookie domain if it’s set. So please try adding this to your wp-config.php:

define( 'COOKIE_DOMAIN', 'yourdomain.com' );

Replacing ‘yourdomain.com’ with your own of course. I never had to do this, but it might help in your case. If your project is a WordPress multi-site then this will not work, but for a normal single site it may help.

• This reply was modified 5 years, 11 months ago by geertvanderheide.

Update: Problem solved. Turns out I just forgot that I removed the plugin’s own stylesheet through my functions.php, and that stylesheet was hiding the notice when needed. Now I just hide it through my own stylesheet and everything works fine.

So for anyone else: if you remove the plugin’s stylesheet for optimization or to put the styles in your own stylesheet, then be sure to show / hide the notice using the css body classes that the plugin sets.