Here comes a new maintenance release of Polylang. First of all, I would like to thank Maros Kucera for updating the very old Slovak translation.
This version fixes an annoying conflict with WordPress 4.2 and later (ajax error when changing the language of a page). It also fixes some regressions with the WPML compatibility mode.
It aims to improve the user experience when using the quick edit for posts and pages. The parent dropdown list is now filtered by the page language. The same for the suggested tags.
A few other edge cases are fixed too.
Polylang 1.7 has been released a bit more than 3 weeks ago. It was quickly followed by two maintenance releases to fix two annoying regressions. Then it was time to go back to a more usual stabilization process.
For a while now, some users (it seems that all are hosted at GoDaddy) experience a random fatal error:
Fatal error: PLL_Model::_languages_list(): The script tried to execute a method or access a property of an incomplete object. Please ensure that the class definition “PLL_Language” of the object you are trying to operate on was loaded _before_ unserialize() gets called or provide a __autoload() function to load the class definition
As a quick fix, I introduced the option PLL_CACHE_LANGUAGES in Polylang 1.5.3. Of course, having to edit the wp-config.php file is far from ideal, but without more clue, I had nothing better to propose.
Fortunately, captin411 came recently on the support forum with an explanation for this issue as well as a proposed fix. To make a long story short, GoDaddy has a an object cache setup which does not allow WordPress plugins to store PHP objects in a transient, which is exactly what is done by Polylang.
So, starting from Polylang 1.7.3, the languages objects are transformed to arrays before being stored in the transient. Hopefully, this should definitely solve the issue.
Finally, I want to remind you that versions of Polylang older than 1.7 are not compatible with WordPress 4.2.
Polylang 1.7 introduces several important changes. First of all, it breaks the compatibility with old versions of WordPress and Polylang will now require WordPress 3.8 or newer to run smoothly. It also prepares the arrival for WordPress 4.2 which is now in beta stage.
Up to now, when using default (ugly) permalinks, Polylang only offered the possibility to set the language from the content. I have to admit that it does not play nicely with some plugins which request to know the language before the content is known. So, I decided to offer the possibility to set the language from the url even for default permalinks and make this option the default one. This should improve the user experience, especially for Polylang beginners who expect things to work out of the box without tweaking options.
I am always looking for performance improvements. A lot of users are using flags on frontend and it is well known that making one http request per (very small) image is not very optimized. Thus Polylang will now encode the flags directly in the html to save one http request per flag. The technique used is not compatible with Internet Explorer 6 and 7. People wanting to be compatible with these old browsers can get the original images back by adding
in wp-config.php or in wp-content/polylang/pll-config.php. Note that only flags provided with the plugin are encoded.
Polylang 1.7 also introduces a lot of other improvements and fixes which should globally ease the user experience (see the long changelog in readme.txt).
Last but not least… Polylang beginners will be grateful for the new user contributed PDF tutorial with a lot of screenshots 🙂
Polylang 1.6.5 fixes a couple of bugs discovered in the past two weeks but the main goal is to fix a conflict introduced by the release or WordPress SEO 1.7.2 & 1.7.3 yesterday and which impacted users who are setting the language by the content.
For most users, WordPress SEO and Polylang should work correctly together, provided that you use pretty permalinks and don’t set the language from the content (yes, although I like this feature, I must agree that it does not play nice with all plugins).
For what is related to sitemaps, the basic idea of the WPSEO compatibilty code included in Polylang is to mix all languages in the same sitemap. This works great when setting the language from the directory name in url. This is also what is generally done in other compatible sitemap plugins such as XML sitemap and Google News feeds. I like this approach as it eases the task of the website admin.
This should have worked whatever option you choose to set the language (directory name, subdomain or multiple domains), but Joost de Valk and I don’t share the same view and WordPress SEO explicitely removes from the sitemap all the content from subdomains and domains which are not the one defined in your WordPress general settings, thus keeping only the content from the default language 😦
I had thus to work around this and Polylang 1.6.4 introduces a separate sitemap per subdomain or domain when using WordPress SEO (while keeping the unique sitemap in other cases). If you have subdomains and prefer to have only one sitemap, XML sitemap and Google News feeds seems to be currently a better choice.
Polylang 1.6.4 fixes a few other bugs reported by users during the past month.
First of all, I would like to wish all the best for this new year to all of you.
Polylang 1.6.3 has been released a few hours ago. This is a minor version which aims to fix some bugs reported in the past month and to release the new Georgian translation kindly offered by Tours in Georgia.
WordPress 4.1 is planned to be released in two days. Some users are worrying that changes in the way WordPress will manage taxonomies (mainly to avoid shared terms between taxonomies) may affect Polylang. So far and although I did not add any specific code to Polylang, all my tests passed successfully with the WordPress development version.
Nevertheless, I went on improving the stability of Polylang and this new version comes with several bugfixes.
Among these, I reworked a function of the WPML compatibility mode as it was not close enough to the original function. This should improve the compatibility with themes and plugins using the WPML API (especially the theme Avada).