Polylang With the time, more and more plugins and themes intend to be multilingual compatible. As WPML is the most widely used plugin, they implement this multilingual compatibility on top of WPML.
What’s fine is that Polylang mimics WPML by implementing the WPML documented API and the language configuration file wpml-config.xml. This is very interesting for themes and plugins developpers as they can hit two targets with one bullet. For example, WordPress SEO or the theme Responsive are compatible with Polylang through the WPML compatibility mode. Good ! So why this fatal error with some other themes and plugins?
Frequently, themes and plugins detect the presence of WPML by testing a documented constant or function. For example:
if ( defined( 'ICL_LANGUAGE_CODE' ) ) {
// do something with WPML functions
}
If the plugin or theme uses only documented WPML API functions, there should be no issue as Polylang provides these functions. But if the plugin or the theme then makes usage of WPML internal function like the code below
if ( defined( 'ICL_LANGUAGE_CODE' ) ) {
global $sitepress;
$lang = $sitepress->get_default_language(); // wrong as no test is made to see if the object exists
}
Polylang users will experience an ugly Fatal error: Call to a member function get_default_language() on a non-object in…
What are the fixes?
For plugins and themes developers, there are two ways. The easiest is of course to test some statement which is unique to WPML (so not documented constants and API functions, but the for example the $sitepress object you intend to use). Doing this, the theme or plugin will support only WPML and won’t take profit of Polylang, but at least, the fatal error will disappear.
But the smartest way is of course to make the theme or plugin compatible with Polylang, by using the Polylang API to replace WPML internal functions.
And for users who just want things to work? The best is to ask for support to author of the theme or plugin which provoques the fatal error. Maybe he will modify his code either to just suppress the error, or to add full compatibility with Polylang.
Waiting for this, there is a way to disable the WPML compatibility mode of Polylang. You can insert:
define( 'PLL_WPML_COMPAT', false );
in your wp-config.php or in wp-content/polylang/pll-config.php. With the latest, you have to create both the directory and the file. Be aware however that this will disable the WPML compatibility mode for your theme and all plugins, not only the one causing the fatal error.
Picture illustrating the article by Gerd Altmann and licensed under CC0 Public Domain.