Development of Polylang version 0.8

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.

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.

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

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

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

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 ??

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

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

Maybe the tagline field had to something about it…

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.

@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: https://db.tt/CAdnwyrT

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 …