WordPress.org

Ready to get started?Download WordPress

Forums

Polylang
Development of Polylang version 0.8 (36 posts)

  1. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    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.

    http://wordpress.org/extend/plugins/polylang/

  2. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    I just updated the development version (0.8dev3 now). It should solve the following issues:

    * Bug correction: problems with custom post type if rewrite slug is different from post_type (thanks to AndyDeGroo)
    * Bug correction: quick edit still breaks translation linking of pages in 0.7.2 (thanks to AndyDeGroo)
    * Improve compatibility with other plugins broken by the home url filter

    Lot of work has been done to correct issues with the home page with some option combinations.

  3. close
    Member
    Posted 2 years ago #

    Warning: Invalid argument supplied for foreach() in ...../d/wp-content/plugins/polylang/include/base.php on line 253 (I sent you a private link to this site before).

  4. AndyDeGroo
    Member
    Posted 2 years ago #

    I'm looking over changes in 0.8dev3 and decided to report one small error in JavaScript which I saw before but didn't want to bother you;
    in core.php on line 410

    if (e[i] == '[object HTMLInputElement]') {

    this statement would fail in older browsers. In particular IE<7 in which Element.toString() would always return '[object]'.

    Instead you should use tagName property to check element type:

    if (e[i].tagName.toUpperCase() == 'INPUT') {

    the toUpperCase() part is just to make sure comparison succeeds.

    I also noticed that you have made few changes to improve performance, like storing taxonomies and post types in polylang object.

  5. AndyDeGroo
    Member
    Posted 2 years ago #

    Strangely enough those notices in post_type_archive_title() are still coming in 0.8dev3.

  6. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    First of all, thank you for testing and reporting bugs.

    @close
    I do not like this. I guess you did update from 0.7.2 (or older) to 0.8dev. Are you using the string translation feature ? If yes, did you loose some (all ?) of them during the upgrade ?

    @AndyDeGroo
    I am a poor js programmer, so I am very glad that you share such corrections with me. I will apply your suggestion.

    I thought I solve the issue with post type archives title. I will look at that again.

  7. close
    Member
    Posted 2 years ago #

    Yes Chouby, I came from 0.7.2 and the strings were still there after update.

    I just deleted the tagline strings (which returned some errors).
    Then I deleted the site title strings and everything is fine, even when I fill in the same strings again. Hope this helps.

  8. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    the strings were still there after update

    Glad to read that. I changed the way these strings are stored in the database and although I tested the upgrade carefully, your bug report made me fear something was wrong.

    I will further look at what happens when deleting a translation.

  9. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    Again I updated the development version (0.8dev4 now). It should solve the following issues:

    * Bug correction: bad rewrite rules for feeds (introduced in 0.7.2)
    * Bug correction: the order is not saved when creating a language
    * Bug correction: the categories list is not updated when adding a new category (ajax broken)

    I improved the home_url filter again.
    I included the improvement in javascript proposed by AndyDeGroo above.

    I introduced two new options (not in UI but the option can be modified in wp-config.php with the 'define' instruction) to disable the home_url (in case it still breaks something) and to disable the metas synchronisation between translation (due to this discussion).

    NB: I disabled the sync process in 0.8dev4 for test purposes but it will be re-enabled by default on final release.

  10. AndyDeGroo
    Member
    Posted 2 years ago #

    @Chouby Have you considered using WordPress plugin trac for bug reports? It's a bit cluttered in reports section as there are many other devs using it, but it would be easier to track reports.

    I have updated to 0.8dev4.
    As for the CPT archive title issue: I still can't get it to show up with wp_title() because get_queried_object() in post_type_archive_title() returns language taxonomy object instead of CPT object. I've been reading code of polylang and still can't track down this bug.

    Another issue is redirect loop when opening home page without language slug. This doesn't happen with language slug in url.
    After some testing and changing options I found out this happens only if hide_default ==0 and rewrite == 0.

  11. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    Yes I may use trac in the future (I have to look how to do first...)

    For CPT archives, I just reproduced it. I will work on it.

    For the redirect loop, could you tell me more ? Are you using a static front page ? What is your permalink structure ? What are the other options of Polylang ?

    Thanks for all the tests you are doing !

  12. AndyDeGroo
    Member
    Posted 2 years ago #

    The permastruct is /%year%/%monthnum%/%postname%/
    option show_on_front => 'posts'
    polylang options when I get redirect loops:

    [browser] => 0
    [rewrite] => 1
    [hide_default] => 0
    [force_lang] => 0
    [default_lang] => lv
    [redirect_lang] => 1

    polylang options when it works as expected:

    [browser] => 0
    [rewrite] => 1
    [hide_default] => 1
    [force_lang] => 0
    [default_lang] => lv
    [redirect_lang] => 1

    It seems that hide_default and force_lang are somehow exclusive because if both are false I get redirect loops on front page. browser and redirect_lang is irrelevant here because changing those didn't fix redirect problem.
    All redirects are to site root / and with status 302 if that is of any help.

    And I'm also getting PHP notices when opening non found pages/posts

    Trying to get property of non-object in [...]wp-includes/category-template.php on line 1082
    Trying to get property of non-object in [...]wp-content/plugins/polylang/include/base.php on line 121

    which must be because option page_for_posts is '0'. maybe you should check for such cases in Polylang_Core::translate_page() or get_post().

    Regarding your coding style - maybe you should not return false or null where object is expected or either check return values before using them. I know that it is easier and takes less code to do it like: $this->get_post_language($post_id)->term_id but it is harder to debug and maintain. And that return ''; in get_post is not nice. I is ok until you turn on WP_DEBUG and have error reporting set to E_ALL (which I always have on development sites).
    No flame intended - just trying to help. :)

    a bit off-topic:
    When I was starting my current project I thought I could go with WPML, as that is what the blog is using now. Then I discovered that WPML is not free anymore, so I looked for alternatives and found Polylang. It was looking promising until I encountered that bug with CPT and the other one with quick edit, but I decided to help out and maybe make it better. After all, that's what opensource is about - making stuff better.

  13. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    I believe that I just catched the CPT archives bug. Will look at your other reports and come back later.

  14. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    Regarding your coding style - maybe you should not return false or null where object is expected or either check return values before using them.

    I try to check return values, but sometimes forget them :( . However, the code starts to be quite big and I am probably not well organised enough to make tests. So for sure, your help is greatly appreciated.

    And that return ''; in get_post is not nice.

    I am 'self made PHP developper' so glad to learn more... What do you advise instead ?

    I is ok until you turn on WP_DEBUG and have error reporting set to E_ALL (which I always have on development sites).

    I have error_reporting set to E_ALL | E_STRICT.

  15. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    A new development version is available (0.8dev7 now). It should solve the following issues:

    * bad rewrite rules (again)
    * problems with custom post type archive (again)
    * Endless redirection as reported by AndyDeGroo
    * Some PHP notices

    And some improvements too:
    * Added 'display_names_as' argument to pll_the_languages
    * Improved the performance when globally setting the default language to all existing content.

  16. AndyDeGroo
    Member
    Posted 2 years ago #

    Those two notices I mentioned above are coming from filter hook option_page_for_posts.
    I think, Polylang_Core->translate_page() should return passed value if it equals zero because there is no post with ID 0. That is also the way filter functions work in WP.

    I highly recommend adding Xdebug to your development toolset, because oftentimes it can help to solve some obscure issues. To get better idea of what's going on configure it to show function params in stack traces. That would be xdebug.collect_params = 4.

    I am 'self made PHP developper' so glad to learn more...

    Me too. I have a graphics design education and PHP is only part of my skill set. Nevertheless I have more than eight years of experience in web development and programming in general.

  17. AndyDeGroo
    Member
    Posted 2 years ago #

    Downloaded 0.8dev7 and going over diff.
    In core.php on line 330, instead of

    unset($query->queried_object)

    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.

  18. AndyDeGroo
    Member
    Posted 2 years ago #

    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 t.name 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.

  19. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    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 !

  20. AndyDeGroo
    Member
    Posted 2 years ago #

    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. :)

  21. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

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

  22. ivomasterche
    Member
    Posted 2 years ago #

    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:)

  23. AndyDeGroo
    Member
    Posted 2 years ago #

    @ivomasterche
    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.

  24. ivomasterche
    Member
    Posted 2 years ago #

    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 :)

  25. close
    Member
    Posted 2 years ago #

    @ivomasterche
    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.

  26. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    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.

  27. ivomasterche
    Member
    Posted 2 years ago #

    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/nonillion.com/www/root/wp-content/plugins/polylang/include/admin.php on line 341"

    Maybe the tagline field had to something about it...

  28. Chouby
    Member
    Plugin Author

    Posted 2 years ago #

    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 :(

  29. ivomasterche
    Member
    Posted 2 years ago #

    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.

  30. AndyDeGroo
    Member
    Posted 2 years ago #

    @Chouby

    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:

    if(function_exists('pll_register_string')){
        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: http://db.tt/CAdnwyrT

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic