From user perspective, Polylang 1.2 will come with two new major features:
- it will be possible to use the language code as a subdomain. That is you will be able to use en.yoursite.com for English and fr.yoursite.com for French.
- It will be possible to export and import languages and translations using the WordPress export tool and the WordPress Importer plugin.
However, under the hood, Polylang 1.2 is a major rewrite. With the previous releases, the code started to be difficult to maintain. So I completeley modified the plugin structure, splitting it in more classes, before it becomes a total mess.
Also to make the export / import possible, I needed to suppress the use of the termmeta table added by Polylang. Although the WordPress API does allow using this table as if it would be present in all WordPress installations, it is not present and probably won’t be in a near future as ticket #10142 current status is maybelater. So obviously, the content of this table is not exported by the WordPress export tool. And unfortunately this tool does not permit to easily export custom content. So exit the termmeta table and welcome to 3 new (hidden) custom taxonomies. It’s also worth to note that the strings translations were moved from options to custom posts to permit their export and import too.
So… Since a lot of things changed, I likely introduced new bugs (and possibly reintroduced old ones). So I plan for a beta period probably a bit longer than for the previous versions, hoping that volunteers will test and report bugs.
Note on upgrade: since data are stored in a different way, Polylang will need to migrate the data in DB. To prevent any bad things (there are always people who do not backup their DB before upgrading), the old data will not be removed in v1.2 but in a later version. Of course the uninstall process removes all data (both Polylang 1.1.x and 1.2).
Important note for the developpers of plugins and themes supporting Polylang 1.1.x: There is no change in the API. Internal methods such as $polylang->get_languages_list() have likely moved to a sub-object of $polylang – for example, here the new correct call is $polylang->model->get_languages_list(). For such cases backward compatible methods are created using the magic method __call so that nothing should break at update. However a notice will be emitted (with new correct method call indication) if WP_DEBUG is set to true.
There is however one case where things will likely break, that is when a direct SQL query with Polylang data is made. At least all SQL queries to termmeta table will break.
I like themes and plugins supporting Polylang so in any cases, I will gladly help to maintain compatibility.