Support » Plugin: Polylang » Development of Polylang version 0.8

  • Plugin Author Chouby


    I made available a development version of Polylang v0.8. You can download it here. I recommend to use it for tests only but feedback and bug reports will be appreciated.

    Here are the improvements:
    * Sticky posts are now filtered by language
    * It is now possible to use the language page as home page
    * Add an “About Polylang” metabox on the languages admin page
    * Add the pll_the_languages filter allowing to filter the whole output of the language switcher
    * Add pll_get_post_types & pll_get_taxonomies filters allowing to enable / disable the language filter for post types & taxonomies
    * Add ckb to predefined languages list
    * Completely reworked the string translation storage in the database
    * Bug correction: body class ‘home’ is not set on translated homepage
    * Bug correction: robots.txt is broken when adding the language code to all urls (including default language)
    * Bug correction: bad name for the Czech flag
    * Bug correction: bad language information in rss feed for WP < 3.4
    * Bug correction: signup broken on multisite
    * Bug correction: the translation url is set to self when using a static front page and no page for posts and there is no translation
    * Bug correction: problems with custom post type archive titles

    Please use this topic to report bug on the development version only.

Viewing 15 replies - 16 through 30 (of 35 total)
  • Downloaded 0.8dev7 and going over diff.
    In core.php on line 330, instead of


    it should be

    $query->queried_object = false

    because unset() will delete the property and create notice when accessed in WP core and maybe create even more issues.
    I’ll correct it in local copy, but you should also change it in your code.

    EDIT: Oh, excuse me. I was actually wrong about that unset(). In get_queried_object it actually checks it with isset.

    I have also partially translated Polylang to Latvian and as soon as I get to complete it, I’ll send you the .mo file.

    I was moving code to production sandbox and tried to set default language for existing content in Polylang options screen.
    Got this:

    WordPress database error: [Duplicate entry '41-5' for key 1]
    INSERT INTO wp_dev_term_relationships (object_id, term_taxonomy_id) VALUES (41, 5),(33, 5),(28, 5),(26, 5),(2, 5),(1, 5),(23, 5),(13, 5),(6, 5),(9, 5),(24, 5)

    This is because get_terms('language', array('fields'=>'ids')) return an empty array every time. This in turn happens because, when you insert term relations manually, wp_term_taxonomy.count is not incremented.
    The get_terms query returns only non-empty terms:
    SELECT t.term_id, tt.parent, tt.count FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('language') AND tt.count > 0 ORDER BY ASC

    Solution would be to add the hide_empty option to get_terms in Polylang_Admin::get_untranslated():

    get_terms('language', array('fields'=>'ids','hide_empty'=>0));

    and term count should also be updated after inserting relations to prevent further problems with get_terms:

    $post_count = count($untranslated['posts']); //Note: get_untranslated returns array instead of false - read below
    if($post_count && $lang->term_taxonomy_id){
    	$values = array();
    	foreach ($untranslated['posts'] as $post_id)
    		$values[] = $wpdb->prepare("(%d, %d)", $post_id, $lang->term_taxonomy_id);
    	$wpdb->query("INSERT INTO $wpdb->term_relationships (object_id, term_taxonomy_id) VALUES " . implode(',', $values));
    	$wpdb->update($wpdb->term_taxonomy, array('count'=>$post_count), array( 'term_taxonomy_id' => $lang->term_taxonomy_id ));

    Probably there is a better way to update term counts.

    Polylang_Admin::get_untranslated() should return an array of arrays instead of false:

    return empty($posts) && empty($terms) ? false : array('posts' => $posts, 'terms' => $terms);

    better cast them as arrays:

    return array('posts'=>(array)$posts, 'terms'=>(array)$terms);

    that way it can be passed directly to foreach without warnings like Invalid argument supplied for foreach() in ....

    EDIT: I made this change and realized that there should be more advanced check in admin-form.php so maybe in this case it is easier to check return values in admin.php.

    Plugin Author Chouby


    Generally I *much* prefer using WP functions rather than making direct queries myself. Here however, I believe that I had no other choice since I found no function to set a term to many posts. For bulk edit, WP makes one query per post. It’s what I did before too, but it would not be acceptable in case of hundreds of posts. But I did not studied the WP code carefully enough 🙁

    So I will add:

    wp_update_term_count($lang->term_taxonomy_id, 'language');

    just after the insert query.

    However I do not understand what difference makes the hide_empty option in get_terms.

    Thanks again for your help !

    hide_empty in get_terms adds checking of count field in wp_term_taxonomy table and that is why Polylang was displaying the fill_languages option in settings tab.

    I’ve updated to 0.8 and all seems OK.
    …until I’ll find another edge case bug, which can be encountered only in very special conditions. 🙂

    Plugin Author Chouby


    Although I am sure that there are still bugs, I am quite happy with the level reached with this version… thanks to you !

    Hi Chouby, first of all – GREAT GREAT JOB!

    I updated polylang to 0.8 and found …

    Warning: Invalid argument supplied for foreach() in …../d/wp-content/plugins/polylang/include/base.php on line 253

    All the translated strings are set to the default language…

    And yes my previous version was 0.7.2. When i revert back to it its ok.

    Is there a solution or i should reenter all the strings? Can i help to fix it?

    @andydegroo – if you are from Latvia, please send greetings to your beautiful country, i’ve been there to visit a friend, i liked it very much. Plus accept my admiration for your efforts to help other developers:)

    Regarding the warning; This is due to change in how Polylang stores translated strings in database and another point where returned value should be checked before using, _Chouby_. The plugin should have converted those strings after the new version was activated.
    I’m not at my puter right now and can’t check what is the exact problem. Maybe Chouby will be here later in the evening to help with this.

    Thank you for your kind words. Today I’m visiting the capital – Riga, so I’ll say hello from you to green lady of the freedom monument as I pass by.

    I thought that it’s something like this.

    I’ll stick to 0.72 till Chouby makes something about it.

    If i can help in any way i’ll be around:)

    And about Riga – please do so, i hope you’ll have spring there too soon 🙂

    Andy is right. I had the same error as you. Go to the “Strings translation” tab from the Polylang settings, remove the translations, save and put them in again. I even think, removing the tagline fields only was sufficient.

    Plugin Author Chouby


    Although I already did try to find the reason for this error (did not succeed to reproduce it), I will look further at it.

    However, it is probably better not to revert to 0.7.2 and do as close proposed.

    Is it possible the problem to have something in common with the fact that when i update the plugin it finds the calls of pll_register_string() and throws an error ?
    How can i check whether the plugin exists and call them after that ?

    Luckily a managed to get it working without the error, with some unreproducable combination of database and plugin reverting, function call removing and updating …

    During these experiments i received another error “Warning: base64_decode() expects parameter 1 to be string, array given in /www/ on line 341”

    Maybe the tagline field had to something about it…

    Plugin Author Chouby


    I really do not understand what is wrong. When upgrading from 0.7.2 to 0.8, Polylang reads the strings as it was done in 0.7.2 and then export it in the 0.8 format which is *mandatory* an array (possibly empty). The error is generated when reading the strings *after* the upgrade process occured. When the error occurs, it would mean that the strings are not stored in an array, so would mean that for some reason, the upgrade did not work (so the strings translations would be lost which, according to close, is not the case).

    Moreover, the only reason I foresee why the upgrade would not occur is the test I introduced to know if the base64_decode has not been deactivated (I learned after the release of 0.7 that some hosts deactivate this function and so that Polylang older than 0.8 would produce an ugly error in such case).

    @andydegroo: I could introduce an additional test to check that my option is an array which would remove this ugly message. But it would hide the problem which is hidden behind which is no more desirable.

    @ close: I reviewed my code for the tagline and do not see what difference with other strings could create a specific error.

    @ivomasterche: what is this error with pll_register_string ? Did you wrote yourself some code using this function ? It may help to know more… The base4_decode error is most probably due to revert (your strings were updated to the new format and so became unreadable in 0.7.2 and leads to this expected error).

    It seems that just saving the translations in the strings translation page should solve the error. I don’t like keeping things like that, but since I did not succeed to reproduce and did not find what could create the error in the code, I have currently nothing more acceptable to propose 🙁

    I use the function to declare the strings.
    I have some 20 lines like this in my funcion.php:
    pll_register_string(“We’re_hiring!”, “We’re hiring!”);

    When i tried to update the plugin through the wordpress control panel i got the usual PHP error for missing function declaration. The plugin is not activated and, i don’t have access to the contol panel. I had to remove the calls of the function from the functions.php file, then i have access to the control panel, activate the plugin and put the
    pll_register_string(“…”,”…”); lines again.


    When upgrading from 0.7.2 to 0.8, Polylang reads the strings as it was done in 0.7.2 and then export it in the 0.8 format

    Here’s your problem:

    version_compare('0.8', '0.8dev1', '<') == FALSE;

    @ivomasterche: Try wrapping those function calls like:

        pll_register_string("We're_hiring!", "We're hiring!");

    That should solve your problem. And it’s not needed to call pll_register_string on every request. You can add is_admin() check, so they are registered only in admin. After strings have been registered for first time, they are loaded every time Polylang loads.

    On a sidenote – an image taken specially for @ivomasterche:

    Thank you AndyDeGroo.

    Chouby, isn’t it going to be nice to have this string adding in the control panel? With some simple form or with adding some functionality to the current string translations form for inserting and removing strings ?
    If you think that it won’t make the plugin too complicated … It’s already the best working one …

Viewing 15 replies - 16 through 30 (of 35 total)
  • The topic ‘Development of Polylang version 0.8’ is closed to new replies.