Category Archives: Polylang versions

Polylang 1.8.1

Polylang 1.8.1 is a maintenance release. The main goal is to fix a regression introduced in version 1.8 concerning secondary queries with translatable post types and non translatable taxonomies. It also fixes a few other minor bugs that I noticed while testing during the last week.

Facebook and WordPress introduced a lot of new locales during the past year. I updated accordingly the mapping between these locales used for Opengraph support when Polylang is used in conjunction with Yoast SEO or Jetpack.

Three new translations have been moved to languages packs (ca, de_DE and pt_BR). And a brand new translation was created (es_CL). Today, already 16 languages packs are available for Polylang. 27 older translations are still supplied with the plugin. Thanks a lot to the translators and translation editors for their work.

Advertisements

Polylang 1.8

After almost two months of beta tests, Polylang 1.8 has just been released.

As described in an earlier post, the most visible changes are in the plugin settings pages which have been totally revamped.

You are now able to choose your own flags for the languages, directly from the admin screen when adding or editing a language. The default language is now identified in the languages list table and can be modified directly in the table.

Since the last update, six new WordPress languages packs (ary, bn_BD, en_ZA, es_AR, fr_BE, fr_CA) have been created. These languages found their place in the predefined list.

The settings are now arranged in modules. One late change not earlier described is a new option to allow Polylang data not to be deleted when the plugin is uninstalled. If you want to delete all Polylang data when using the red “Delete” link in the plugins list table, you now have to check this option in the Tools module of Polylang settings. This option is unchecked by default.

The hreflang html tag now contains the locale instead of the ISO-639-1 language code. This will allow users having several variants of the same ISO-639-1 language to have valid W3C locales in the hreflang tags. Polylang also works around an issue in WordPress for non W3C valid locales (ex: de_DE_formal).

I also worked on the compatibility with Jetpack Related Posts, Duplicate Post, and worked around a bug in Nextgen Gallery preventing both plugins to work together.

Other less visible improvements and bug fixes are described in the changelog. Developpers having a plugin or a theme interacting directly with the PLL_Model class instead of the Polylang API should read the post dedicated to internal changes.

Last but not least, twelve translations are now taking profit of the plugins languages packs (automatically updated by the built in functionnality of WordPress): Albanian, Danish, Duch, French, Greek, Galician, Italian, Japanese, Portuguese, Romanian, Slovak and Swedish. Thanks a lot to the translators and translations editors!

Polylang 1.7.12 and WordPress 4.4

I spent the past few weeks to test Polylang with the beta versions of WordPress 4.4. As a consequence of a change in taxonomies, Polylang 1.7.11 and older versions will not work with this future version of WordPress. Polylang 1.7.12 aims to fix this situation as well as a few other conflicts.

This release is also an opportunity to add the near complete translation in Moroccan Arabic, coming from the Translating WordPress project and update translations which have been significantly improved by this project (French, Indonesian and Portuguese). I did not included the translation in Albanian but it will be automatically downloaded as language pack.

Polylang 1.7.10

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 and WordPress 4.3

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.

Polylang 1.7.8

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’.

Polylang 1.7.6 and multisite

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.