Development of Polylang version 0.8

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.

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

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.

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

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.

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.

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.

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.

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

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 !

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.

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

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.

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.

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.