Here comes a new maintenance release of Polylang and first of all, I would like to thank Cédric Valmary for a brand new translation in Occitan.
Several bugs or conflicts (with Lingotek translation, Jetpack infinite scroll, Yoast SEO and the theme Ambition) were fixed. But the most important change concerns navigation menus. For a while, Polylang conflicts with themes which incorrectly use wp_nav_menu. Hopefully I have found a workaround to detect these themes and fix the issue for most of them.
WordPress 4.3 also introduces several new languages packs. The corresponding languages are thus introduced in the predefined languages list.
Polylang 1.7.9 is a maintenance release focusing on the compatibility with WordPress 4.3 which is planned to be released tomorrow.
Indeed, WordPress 4.3 will introduce several conflicts with earlier versions of Polylang. This mainly concerns the menus and the customizer. This new version aims at fixing these conflicts.
However, the language switcher is not yet compatible with the new customizer menus. There is still some work to be done in WordPress to allow plugins to have menu items with custom forms (as done by Polylang for the language switcher). Of course, you can still add a language switcher menu item in Appearance->Menus as usual.
Under the hood, WordPress 4.3 will eliminate all shared taxonomy terms. Not all users have shared terms in the database but for those who have, this impacts Polylang. The compatibility code is there since Polylang 1.7 and the core team helped a lot to make things happen as smoothly as possible, but making a database backup before upgrading to WordPress 4.3 is well recommended.
Finally this version fixes also a conflict with Yoast SEO sitemaps (when using multiple domains) and improves the usage of hreflang in the alternate links added by Polylang in the html head.
Up to now, Polylang users had to manually translate all the content of their website. As announced by Lingotek, you can now use translation services (both machine and professional translations), directly from WordPress + Polylang. To make this happen, you will need to install Lingotek Translation, a free WordPress plugin available in the WordPress repository. Machine translation is free up to 100,000 characters.
I hope that you will enjoy this new possibility.
Three days ago, I released Polylang 1.7.7. I am sorry for the inconvenience I introduced for users running PHP older than 5.4. Polylang 1.7.8 released less than 24 hours later fixed the issue.
Polylang is now available in 40 languages thanks to uskro who provided the Romanian translation and Eiko Toda who provided the Japanese translation. I also would like to thank fxbenard who improved the French translation.
Polylang 1.7.6 stopped flushing rewrite rules at network activation due to an annoying bug in previous versions. Thanks to comments of RavanH in my previous post, I believe that the bug is properly fixed now.
This version also fixes a conflict with WP Super Cache preloading, thanks to ecdltf who reported the conflict and proposed an easy fix, and another conflict with the plugin leadin.
I also tracked changes in the Customizer and fixed a bug in Customizer menus locations introduced by the release of WordPress 4.1. I am sorry for the inconvenience but constant changes in the Customizer make things a bit hard to follow. WordPress 4.3 will introduce Customizer menus which I aim to support. Part of the job has been done by the WordPress core as we got some filters for Polylang to support this new feature. But there is still a lot of work to do to reach that goal.
In the preparation of WordPress 4.3, Polylang does already support formal translations. For example German users can now choose to use the locale ‘de_DE_formal’ instead of ‘de_DE’.
First of all, I’d like to thank Toño Calo for the new Galician translation. Polylang is now available in 38 languages.
My tests are generally done on a multisite installation with Polylang activated per site. I don’t see the point of network activating a plugin such as Polylang in a multisite installation (i.e forcing all sites of the network to be multilingual), but a few users are doing so and my aim is to make Polylang compatible with this use case too.
Thus, following a bug reported in the support forum, I recently network activated Polylang on my usual local test install and noticed that this action broke the rewrite rules of all sites of the network (except the main one)! I noticed the same issue at network de-activation… I had to dive into the WordPress core code to understand what happens.
A best practice is that plugins manipulating rewrite rules (as Polylang does) flush the rewrite rules at plugin activation and de-activation so that the website works correctly both when the plugin is activated or de-activated. If the plugin is network installed, then this *should* be done on all sites of the network. The problem is that in the current state of WordPress (4.2), the rewrite rules array is not cleaned when programmatically switching to a different site, thus creating a big mess in the rewrite rules of all sites. I opened a new ticket for this issue.
Thus, starting from this version, Polylang will stop flushing rules at network activation and de-activation to fix this annoying bug. It means that in this case, you will need to flush the rewrite rules manually on all sites (by visiting the Settings->Permalinks page).
Nevertheless, based on this experience, I would advise to avoid network activating plugins which manipulate rewrite rules. For programmers reading this, it means that we must not play with flush_rewrite_rules and switch_to_blog in the same time.
Polylang is going on its way to a better stability and the list of other fixes is available in the changelog.
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.