Conflict with woocommerce simple auction plugin

Hi!

You are perfectly right. The plugin is using a function without testing for its existence.

In Polylang, the function icl_object_id does exist (as part of the WPML compatibility mode and because it’s a documented WPML API function) but $sitepress->get_default_language() does not exist (as it is an internal function of WPML). That’s why you get the fatal error.

Without working too much on it, this should be a fix:

global $sitepress;

if (function_exists('icl_object_id') && function_exists('pll_default_language')) { // Polylang with use of WPML compatibility mode
	$id = icl_object_id($this->id,'product',false, pll_default_language());
}
elseif (function_exists('icl_object_id') && method_exists($sitepress, 'get_default_language')) { // WPML
	$id = icl_object_id($this->id,'product',false, $sitepress->get_default_language());
}
else {
	$id = $this->id;
}

Thanks a lot! I will give it a try this weekend, and get back here with the results!

Well… I changed now one part of the plugin for all evidence regarding “get_default_language” and “get_current_language”, seems so far so good.

But now I stumble over the next problem caused by:

$orginalid = $sitepress->get_original_element_id($product_id,'post_product');

It seems like there are many direct references to WPML functionality – changing it all might be quite some effort…

Is there some list of all WPML compatibility that polylang offers, i.e. like using “pll_default_language” instead of “get_default_language”?

But honestly, the more I think and learn about it, the more I believe to understand also their position. They cannot analyze and support all plugins offering multi language support. Like e.g. to use “pll_default_language()” they can only know once they analysed polylang. They could check if the function “$sitepress->get_default_language()” exists instead of just using it, but then again, they would know what to do instead of its usage only after further investigation.

Or are there completely “official”, i.e. documented ways for really all WPML functionality, that would work also with polylang without any knowledge of polylang, and therefore no specific adaptations?

Thanks in any case for pointing me to the right direction, learning…

Hi!

Yes I also understand other plugins authors. We have to make choices. Here it seems that the WPML integration does use pretty much internal functions. So unless they want to be compatible with Polylang too, it will probably be tricky for you to use Polylang.

To be honest, this is the first time I see this function get_original_element_id and I am not sure of what it is doing. I checked but it did not exist in the latest free version of WPML (2.0.4.1).

Here is the link of WPML functions supported by Polylang: https://polylang.wordpress.com/documentation/documentation-for-developers/compatibility-with-the-wpml-api/
also Polylang supports the wpml-config.xml file: https://polylang.wordpress.com/documentation/documentation-for-developers/the-wpml-language-configuration-file/
And the link to Polylang API: https://polylang.wordpress.com/documentation/documentation-for-developers/functions-reference/

Thanks a lot Chouby – with that my decision is clear, I will (have to) go for WPML, at least for the moment. Anything else would be too much effort.

Still I hope you will stay successful with polylang – please keep up your good work and support, really appreciated (and sadly not common).

Good-Bye donation is on the way!

And it is even more uncommon to receive a donation from someone who finally can’t use the plugin. Thank you ??