WordPress.org

31. RavanH
    Member
    Posted 1 year ago #
    

    On second thought... using the development version, I notice that the mixed sitemap with all languages in one, in combination with a page as homepage, has the following effect:

    The xml sitemap always starts with the main URL and then starts looping through pages and posts. During this loop, there is a small check to see if the page that is in the loop is not set as front page. If so, that URL is skipped because it will be the same as the main site URL at the start of the xml sitemap. This check is done with
    

    if ($post->ID == get_option('page_on_front'))

    However, in the mixed (un-languaged) sitemap, this check does not work. You can see the effect on http://valentheze.fr/sitemap.xml ... Whether this is actually a problem (different URLs but same content == duplicate content) or not, I'm not sure. On the single-language sitemaps, it does work just fine since the home URL gets translated to the corresponding page URL. See http://valentheze.fr/sitemap.xml?lang=fr (or =nl or =en)

    So now I'm hesitating: use the mixed sitemap and try to fix it, or use the single-language sitemaps and fix it so that the main sitemap redirect to the default language sitemap... Both are viable options. What do you think is best?

    ===

    Two other things I noticed using the Polylang dev version:

    1. The home page redirection seems a bit messed up on http://valentheze.fr/ :
    When I visit the site in a Dutch browser, I get redirected to http://valentheze.fr/nl/ and see a blog page listing latest posts instead of the static home page http://valentheze.fr/welkom/ ... Same for other languages. I do not want this (I did not set a static page as front page for nothing ;) ) so I check the Languages option 'Redirect the language page to the homepage in the right language'. I'd make this option default but it has one downside: since it does not actually redirect but instead show the front page content, we've now got a duplicate content issue :(

    Unless I check 'Hide URL language information for the default language'...

    2. Next, still with the 'Hide URL language information for the default language' option unchecked, I browse to the French homepage. This time, trying to get back to the Dutch homepage via the flags, it turns out I get redirected back to the French homepage!

    Unless, again, I check 'Hide URL language information for the default language'...

    Would it be possible to get rid of these 'language pages' ( /en/ , /fr/ , /nl/ etc. ) completely?

32. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    Par contre, it changes to "fr_FR"... This is not the correct language markup for RSS. It should become "fr". But in principle it works :)

    I will change that.

    I adopted the get_option('home') method in the development version within that code snippet that is meant for verifying the domain ( there are plugins that allow external URLs as permalinks ) so it should work.

    I have also modified my own code so that plugins are not obliged to use get_option('home') instead of home_url(). Because the language filter of the home page will probably break too much plugins. One reported me on the French forum that it breaks the nextgen gallery slideshow :( . So now the filter is active only for themes. And there is an (define) option in the source to deactivate it.

    For now, I did not modify any rewrite rule to support your sitemap. To be honest I don't use a sitemap on my personal site so I am probably not the best guy to advise you on what is the best choice. If I need to do something, just tell me.

    I am aware of all these things broken with the homepage. I just uploaded a new development version which I hope correct them.

    I hope the new option to redirect the language page (automatically created by WP since it is custom taxonomy) to the static front page is now working... Each time I add one option, it doubles the test cases and it start to be tricky to debug :( and not break something else each time I make correction !

33. RavanH
    Member
    Posted 1 year ago #
    

    I understand your frustration. I fear you are running into the limitations of WordPress, as each of the alternative multi-lingual plugin devs have before you... Your approach is different but it does not mean it makes it easier in every aspect. It just means Polylang is getting mature ;)

    In any case, I have decided to try to tackle this in the same way as with qTranslate and xLanguage: different sitemaps for different languages after all... And these different sitemaps each need to get a reference in robots.txt

    To do this, I need a function that will reliably convert the base URL of the sitemap into the correct language URL, depending on Polylang settings.

    I had hoped $polylang->add_language_to_link($url,$language) would be the magic bullet, but it seems that it only handles the pre-pending (with or without /language/) of the language slug. So it is only useful when the option "Add language information to all URL's" is checked but gets me URL's that fail (404) when it is not checked.

    Using add_query_arg('lang', $language->slug, $url) I get the correct query variables for when "Add language information to all URL's" is not checked, but these URL's will fail when it is checked.

    How do I find the Polylang setting, and can I rely on it staying the same in future versions? Or can I ask you to extend your function add_language_to_link to be useful in this case? Something along the lines of:
    

    if ( ADD_LANGUAGE_TO_ALL_OPTION == '1' && $GLOBALS['wp_rewrite']->using_permalinks()) {
    	$base = $this->options['rewrite'] ? '/' : '/language/';
    	$slug = $this->options['default_lang'] == $lang->slug && $this->options['hide_default'] ? '' : $base.$lang->slug;
    	return esc_url(str_replace($this->home, $this->home.$slug, $url));
    } else {
    	return add_query_arg( 'lang', $lang->slug, $url );
    }

    Or does that mess up other operations?

    Will upgrade to the latest dev version soon :)

34. RavanH
    Member
    Posted 1 year ago #
    

    Quick bug report on the 0.8 dev3 release:

    There seems to be something going wrong with the Category language settings... When defining a language for a category, that value does not seem to stick.

    Maybe related: on the Settings > Languages page, Settings tab, the message "There are post, pages, categories ... without language set. Set them to the default language?" (or something like that) does not want to go away.

    Another issue that has been around longer: when adding a new language, the Order value does not stick. The new language will be 0 in order. Editing the language settings will allow the order to be changed...

35. RavanH
    Member
    Posted 1 year ago #
    

    Positive note on the 0.8 dev3 release:

    I absolutely love the home page handling when "Redirect the language page..." is checked. Perfect :)

    Sadly, another strange effect has appeared. See http://valentheze.fr/en/feed/ where somehow all NL post are listed instead of the EN one. But on http://valentheze.fr/fr/feed/, the post are filtered correctly. NL is set as default language but changing it, does not change this effect.

36. RavanH
    Member
    Posted 1 year ago #
    

    Plus: home_url(), get_option('home') and get_bloginfo('url') in my feed template now all return the same base site URL regardless of the language query variable :(

37. RavanH
    Member
    Posted 1 year ago #
    

    Plus: when the option "Hide URL language information for default language" is checked. The RSS feed for the default language is no longer available. Or rather the link in the header changes to /feed/ (without the language info) but the feed remains on /lang/feed/

38. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    I will look if I can modify the function add_language_to_link to make it useful for you. But I am currently focusing on bug hunting.

    Thank you for reporting bugs:
    * bad feeds (bad rewrite rule I introduced in 0.7.2)
    * order of the language (present since introduction of the feature)
    * bad home_url filter (introduced in 0.8dev3)
    These should be corrected in next development version.

    Or rather the link in the header changes to /feed/ (without the language info) but the feed remains on /lang/feed/

    Except If I do not catch what you mean, this is a desired feature. If you hide the default language url, *all* url without language information including feeds will return in the default language.

    Unfortunately, I do not reproduce the issue. with the categories

39. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    I come back on this...

    Par contre, it changes to "fr_FR"... This is not the correct language markup for RSS. It should become "fr".

    Coming back to my code, I saw that the exact output is "fr-FR" with a "-" and not a "_", and more important that this output is not controlled by Polylang but by WordPress. Of course, I could modify this but I fear doing more harm than good if I modify the default way WordPress outputs the language code

40. RavanH
    Member
    Posted 1 year ago #
    

    But I am currently focusing on bug hunting.

    I understand completely :)

    Except If I do not catch what you mean, this is a desired feature. If you hide the default language url, *all* url without language information including feeds will return in the default language.

    Yes, the URL changed after checking the option "Hide URL language information for default language" (as you say, it is the desired behavior) but the problem is that the feed is not there. It is still available on /nl/feed/ (Dutch being the dedault language here) as you can see happening on http://valentheze.fr/feed/ (will leave the option checked for a while) ...

    Coming back to my code, I saw that the exact output is "fr-FR" with a "-" and not a "_", and more important that this output is not controlled by Polylang but by WordPress.

    You are right. Best leave it as it is now then :)

41. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    The feed issue should be solved in the current dev version (0.8dev4). In fact it should be linked with the bad rewrite rules introduced in 0.7.2.

42. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    How do I find the Polylang setting, and can I rely on it staying the same in future versions? Or can I ask you to extend your function add_language_to_link to be useful in this case?

    I came back to my code. Unfortunately I can't easily modify the function add_language_to_link as you propose as it is used in all cases for archives (which always need the language code in the url).

    Polylang settings can be found in:
    

    $options = get_option('polylang');

    I paste below the default values as set in polylang.php
    

    $options['browser'] = 1; // default language for the front page is set by browser preference
    $options['rewrite'] = 1; // remove /language/ in permalinks (was the opposite before 0.7.2)
    $options['hide_default'] = 0; // do not remove URL language information for default language
    $options['force_lang'] = 0; // do not add URL language information when useless
    $options['redirect_lang'] = 0; // do not redirect the language page to the homepage

    I have no plans to modify/remove these options so you can rely on them. Note that you can't rely on them to know if the plugin is activated or not. I destroy them only when *uninstalling*

43. RavanH
    Member
    Posted 1 year ago #
    

    Unfortunately I can't easily modify the function add_language_to_link as you propose as it is used in all cases for archives (which always need the language code in the url).

    I understand... Still, a function that does this would be a nice addition to Polylang's API ;)

    I use isset to check global $polylang to see if the plugin is active. But sadly, I see, the $options variable in that Polylang_Base class is of the protected kind... Any reason for that?

44. RavanH
    Member
    Posted 1 year ago #
    

    Feedback on dev4:

    - All feed languages content behaves correctly now, but...

    - With the option "Hide language info for the default language" checked, the default language feed is still on /ln/feed/ instead of /feed/

    - Good news: got my XML Sitemap Feed plugin to work coherently with all Polylang url related options :) ... except:

    - get_bloginfo('url'), get_option('home') and home_url() all return the base site domain URL instead of being dependant on the lang query variable (as it is for the stable version)

45. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    - With the option "Hide language info for the default language" checked, the default language feed is still on /ln/feed/ instead of /feed/

    Thank you for reporting. I looked back at my rewrite rules and obviously there is still something wrong. I still do not understand why it works on my test site !

    - get_bloginfo('url'), get_option('home') and home_url() all return the base site domain URL instead of being dependant on the lang query variable (as it is for the stable version)

    Sorry for not explaining. Filtering of home url breaks some (a lot of ?) plugins which expect getting the root url of the site. Of course I could claim that they are not well coded and must use home_url('/uri') instead of home_url()./uri but that will not help users...
    So I decided to disable the home_url filter for plugins and enable it only for themes. A few themes will be broken too, so I offer now the possibility to disable the filter completely by setting the constant PLL_FILTER_HOME_URL to false.
    For plugins as yours which need to know the home url in the correct language, I now offer the function pll_home_url()

46. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    I forgot to answer this:

    But sadly, I see, the $options variable in that Polylang_Base class is of the protected kind... Any reason for that?

    I believe in POO one should always protect variables and offer ways to manipulate them (if needed). In this case you can access to this using get_option('polylang')

47. RavanH
    Member
    Posted 1 year ago #
    

    I looked back at my rewrite rules and obviously there is still something wrong. I still do not understand why it works on my test site !

    Or has something gone wrong on my site? To upgrade to the dev version, I uninstalled the plugin first and then uploaded the dev version zip via the WP plugin installation routine. I regret that now, since uninstalling the plugin deleted ALL my plugin settings ;( . So had to do a lot of reconfiguration of all posts, pages, widgets, polylang settings and text translations but since that time, I cannot re-apply any language settings to the post categories... Is it possible there did remain some settings in the DB after uninstallation that are now preventing the dev version to work correctly? Or maybe the DB table setup changed?

    For plugins as yours which need to know the home url in the correct language, I now offer the function pll_home_url()

    OK, I see now... Will have to add a new filter then.

48. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    uninstalling the plugin deleted ALL my plugin settings

    I try to make things clean if someone tests the plugin and finally does not want it.

    I cannot re-apply any language settings to the post categories...

    Strange enough... For categories and tags, the language is defined in a table called wp_termmeta. If no other plugin uses this table, the uninstall process deletes it. But it should be recreated at activation (and display an error message if not). Could you check if you have this table in your database ?

49. RavanH
    Member
    Posted 1 year ago #
    

    I have not had time to look at the DB yet (have to install phpMyAdmin or something like it first) but in the mean time I have another question about using static pages as home page:

    Would it be possible to force WordPress to treat these translations of the home page as if they are a static home page as well? I mean, make it assign the class home to the body, or use template home.php if available...

50. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    Yes phpmyadmin is very useful (To be honest, I couldn't have developped this plugin without it).

    For the front page, it should work like you want. The body class is filtered since 0.8 and home.php was already available before.

51. RavanH
    Member
    Posted 1 year ago #
    

    The body class is filtered since 0.8

    Just upgraded and saw the result. Excellent!

    Yes phpmyadmin is very useful

    Hey, using Navicat to connect to the DB on my VPS turns out to be even more practical that a web interface like phpmyadmin ;)

    And it shows me the DB table _termmeta for that site (it's a multi-site setup) is indeed missing. How to recreate it? If I de/reactivate the plugin, will the settings be lost? Or does that only happen on de-installation?

52. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    Settings are lost only at uninstall. Nothing is removed when you de-activate (only rewrite rules are refreshed).

    The activation should create the table if it does not exists. If it does not succeed, the plugin should not be activated displaying the error message "For some reasons, Polylang could not create a table in your database." At least it is what I expect the plugin to do.

    Some information that may be useful for your sitemap plugin:
    I found a bug in V0.8 which leads to 404 error when using %postname% permalink structure in combination with the "add language code to all url" option. So I have to rework my rewrite rules again ! Doing this, I discovered new filters in WP which will allow me to make rewrite rules more robust.

    What will change for you (starting from 0.8.1) is that the language code will no more be automatically added to the sitemap url even when checking the "add language code to all url" option.

    I hop this modification will not be too annoying for you.

53. RavanH
    Member
    Posted 1 year ago #
    

    Yes, de/reactivation did indeed do the trick! Category translations work again :)

    Strange that there was never a warning about the missing DB table...

    What will change for you (starting from 0.8.1) is that the language code will no more be automatically added to the sitemap url even when checking the "add language code to all url" option.

    Hmmm, that's too bad. I'll have to rethink the compatibility functions again... But thanks for the warning ;)

    May I ask which filters you discovered and use for these new rewrites?

54. Chouby
    Member
    Plugin Author
    Posted 1 year ago #
    

    I am sorry. But I believe it will offer better (other) plugins compatibility.

    I used only 'rewrite_rules_array' filter which allows to filter *all* rewrite rules, but it was quite the mess. And leaded to several bugs. In particular, when adding the language code to all urls, Polylang 0.8 and older would break non wp rules...

    I went reading the WP source code and now I use 'post_rewrite_rules', 'root_rewrite_rules', 'page_rewrite_rules'... So it allows me to easily separate rules and to filter them as needed. Doing this, only core rules and those that are added to $wp_rewrite->extra_permastructs are filtered, which should exclude non wp rules :), and exclude your sitemap rules too :(.

    However, I will offer you a way to take profit of the language filter without too much code. You can add a filter to your rewrite function to allow Polylang to filter them (the same way it does for core rewrite rules).

    function rewrite($wp_rewrite) {
    	$feed_rules = array(
    		'sitemap.xml$' => $wp_rewrite->index . '?feed=sitemap',
    		'sitemap-news.xml$' => $wp_rewrite->index . '?feed=sitemap-news',
    	);
    	$feed_rules = apply_filters('xml_sitemap_rewrite_rules', $feed_rules);
    	$wp_rewrite->rules = $feed_rules + $wp_rewrite->rules;
    }

    And then make polylang aware of this filter in your constructor:

    add_filter('pll_rewrite_rules', create_function('$rules', 'return array_merge($rules, array(\'xml_sitemap\'));'));

    I tested it with the development version of 0.8.1 I just uploaded and the development version of xml-sitemap-feed. Seems to work as expected :)

Topic Closed

This topic has been closed to new replies.