In another tread I was told that my solution is valid for sites that have single Complianz installation in a sub-directory, but our case having another Complianz in the root’s site, might not work, because of the way browsers handle cookies.

So, I think there seems to be easy solution for this; either use another cookie controll software, to avoid colsions, or migrate the web to it’s own domain.

Thanks @rogierlankhors. Mine is not a WP multisite installation, but simply 2 Complianz installations, in the root and subdirectory.

With regards to my above stagtement

I solved it by implementing the hook force-empty-cookie-path.php via a mu_plugin…

sorry, thought I had fixed it, but what happend was that I had not reproduced the problem correctly.

Now I have realized that it still fails. Basically, once you set the sub-domain cookies it forces the root site to set the cookies again, and from then on the banner ALWAYS repeats on the sub-domains site. If set first the root cookies and then the sub’s ones, but dont’t refresh the root cookies, the the sub’s banner works correctly

This is no WP multisite intallation, but even though I tested the today’d releases of Complianz 5.2.0 and 5.2.1, but none solved the problem.

Has anybody a similar setup, but fixed it?

With regards to my above stagtement

I solved it by implementing the hook force-empty-cookie-path.php via a mu_plugin…

sorry, thought I had fixed it, but what happend was that I had not reproduced the problem correctly.

Now I have realized that it still fails. Basically, once you set the sub-domain cookies it forces the root site to set the cookies again, and from then on the banner ALWAYS repeats on the sub-domains site. If set first the root cookies and then the sub’s ones, but dont’t refresh the root cookies, the the sub’s banner works correctly

I also tested the today’d releases of Complianz 5.2.0 and 5.2.1, but none solved the problem.

Has anybody a similar setup, but fixed it?

I have managed to reproduce the problem in a systematic way and in any browser, even incognito, and solved it.

This happens because we have the site implemented in a sub-directory of the main web.

If I delete my main-site cookies, the repetitive requests stop in the sub-directorie’s site and, as soon as I put them back, the banner returns with every page refresh. The order of access to the two sites does not have any influence and it only happens in the sub-directorie’s site.

I solved it by implementing the hook force-empty-cookie-path.php via a mu_plugin (Must Use), but forcing the sub-directorie’s path; i.e return ‘/mysubdirectory’;.

<?php
/* Force consent cookies on the root or, to choose a subfolder 
* Add subfolder between '' on line 6 e.g. /mysubdirectory/
*/
function my_cookie_path($path) {
    return '/mysubdirectory';
}
add_filter( 'cmplz_cookie_path', 'my_cookie_path'); 

• This reply was modified 3 years, 5 months ago by . Reason: corrected /mysubdirectory
• This reply was modified 3 years, 5 months ago by . Reason: added code

I have managed to reproduce the problem in a systematic way and in any browser, even incognito, and solved it.

This happens because we have the site implemented in a sub-directory of the main web.

If I delete my main-site cookies, the repetitive requests stop in the sub-directorie’s site and, as soon as I put them back, the banner returns with every page refresh. The order of access to the two sites does not have any influence and it only happens in the sub-directorie’s site.

I solved it by implementing the hook force-empty-cookie-path.php via a mu_plugin (Must Use), but forcing the sub-directorie’s path; i.e return ‘/mysubdirectory’;.

<?php
/* Force consent cookies on the root or, to choose a subfolder 
* Add subfolder between '' on line 6 e.g. /mysubdirectory/
*/
function my_cookie_path($path) {
    return '/mysubdirectory';
}
add_filter( 'cmplz_cookie_path', 'my_cookie_path'); 

• This reply was modified 3 years, 5 months ago by . Reason: corrected /mysubdirectory
• This reply was modified 3 years, 5 months ago by . Reason: added code

Looks like the DB was corrupted. I restored it and the forms are there again

Here is explained where the forms are stored – https://contactform7.com/faq/how-can-i-export-import-contact-form-data/ – as custom post (post type: wpcf7_contact_form).

But if I still kept the Database, how comes they are lost?

There is an issue that I had reported a year ago, as it has not been resold yet (I just tested it again 2017/09/27). In summary, after switching language not all fields are updated. But there is a simple workaround; you need to make a complete page refresh (F5) after language switching to see the real values.

I tested it with the following versions:
WordPress 4.8.2
qTranslate-X 3.4.8
Yoast SEO 5.5
Integration: Yoast SEO & qTranslate-X 1.2

Thanks a lot @maorb and @inhouse. I had the same problem and implemented the workarounds you proposed. Works link charm now. Would be nice to know when this is going to be fixed. Any date foreseen?

Sorry about this misunderstanding. The donation was not for getting support, but a thank you for your excellent free plugin. Hence I purchased it again.

I had asked you for an additional donation link for paid support, but understand that you prefer to not go that route.

Independently of the way you support, the problem was caused by an update to CF7 and not WPML. I understand that it may be difficult to find what party is really the source of the problem, but on the WPML forum they seem to believe it is a CF7 problem, although they will be trying to fix it in the future.

Will you be looking into resolving this from your side too?

Andre

B.t.w. I’m using your (EXTRAORDINARY) CF7 plugin on most of my customer sites. It’s strange you do not offer a paid version and only accept the “donation purchase” of $7 for the Wapuloader plugin, which I just got.

I usually prefer to pay for software, in exchange of having access to support and/or additional functions. But I guess you want to keep things simple. If you send me an other donation link, where I can chose an amount I’m happy to do so. Independently of how this issue goes :), as I’m not in a hurry for resolution, given that we can live for some time with the Workaround and prefer installing a thoroughly tested product. ??

André Klein

Hi Takayuki. Thanks for the quick response ??

We need WMPL for the bilingual site. The initial problem (not submitting the SECONDARY language forms) will only appear if WPML is active and most likely was caused by the CF7 update. After applying the workaround given by WMPL support the forms submit gain, but now your other options, i.e. redirecting to any other page, don’t work.

I also tried the legacy option for redirecting :

on_sent_ok: "location.replace('https://www.docpath.com/contactusconfirmpop/?lang=es');"

Here is a capture of the settings, but it won’t work either anymore, in none of the languages. You can test it here: https://www.docpath.com/__ak_test_form/ or in the secondary language https://www.docpath.com/__ak_test_form-es/?lang=es

The legacy option does work in another client with the same CF7 Versión 4.8.1, but those are using qTranslateX for multilingual.

I’m not a programmer, but I suppose that the WPML Workaround deactivates loading of some of your script.

Best would be to have the initial problem solved and support the secondary language submission. Any plans on doing this soon?

The other versions we are using are WP 4.8.1 and the latest WPML Version 3.7.1. Here is a capture of all active plugins, in case there is any other that may interfere. The design we are using is DIVI.

Here you can download the current DIVI funtions.php file. The WPML Workaround is at the very beginning.

• This reply was modified 7 years, 3 months ago by .
• This reply was modified 7 years, 3 months ago by .

Is there any update on this?

I have the same request. I’d like to remove the Google reCAPTCHA field. See also this capture https://screencast.com/t/T1fFmmbRrsW7

I had the same problem (see UPDATE required: Yoast SEO & qTranslate-X with Yoast SEO Version 3.0.7+. Installing Yoast SEO Version 2.3.5 (https://downloads.www.ads-software.com/plugin/wordpress-seo.2.3.5.zip) is a temporary workaround.

You can also simply refresh the screen (F5) after switching languages to retrieve the real values. In my case it worked.

I have just opened the following support topic with more details on the problem that you seem to be facing; Language switcher doesn’t change YOAST SEO meta fields. You may want to confirm there if this is the same problem you have.