This topic contains 1 reply, has 2 voices, and was last updated by 
m hoksbergen 1 week, 6 days ago.
-
Posts
-
Hi,
This is Ahmed from WPML Compatibility Team.We have checked the issue that was reported after WPML update with Invisible reCaptcha.
Let me quote our dev’s findings:
The problem is more located inside Invisible reCaptcha because in the autoloader functions (we have several) we also have some code to initialize the plugin. When WPML Core starts filtering gettext strings, it also starts calling the autoloader. As Invisible reCaptcha has registered its autoloader functions before WPML, we pass through Invisible reCaptcha autoloader before WPML’s one, and thus we also initialize (too early) some private properties in Invisible reCaptcha (e.g.
\InvisibleReCaptcha\MchLib\Modules\MchModulesController::$arrRegisteredModules).So, in short, Invisible reCaptcha should add a check in
\InvisibleReCaptcha\MchLib\Modules\MchModulesController::autoLoadModulesClassesto callself::setRegisteredModules();only when the require class is coming from his own plugin.A quick workaround to fix this issue is to find this line
sitepress-multilingual-cms/classes/utilities/class-wpml-locale.php:136Replace
$cache = new WPML_WP_Cache( '' );with `require_once WPML_PLUGIN_PATH . ‘/classes/utilities/class-wpml-wp-cache.php’;
$cache = new WPML_WP_Cache( ” );`I can confirm this problem with WPML and invisible recaptha in 2 sites.
The quick workaround is working for me, but better is a fix. Please solve!
Regards Michel
You must be logged in to reply to this topic.