Support » Plugin: Hyyan WooCommerce Polylang Integration » language added to the domain/PolyLang switcher

  • Resolved W2014

    (@w2014)


    Hallo, i have a problem with the language switcher, it adds the language to the domain…it has to do with the taxonomies in the polylang settings…how can i solve this? if i disable taxonomies, the product languages disappear…and the links point to the standard frontpage.

    shop.com/?post_type=product&lang=de
    shop-en.com/?post_type=product&lang=en
    shop-it.com/?post_type=product&lang=it

    the right links should be:

    shop.com/?post_type=product&lang=de
    shop.com/?post_type=product&lang=en
    shop.com/?post_type=product&lang=it

    thanx

    The page I need help with: [log in to see the link]

Viewing 15 replies - 1 through 15 (of 16 total)
  • Thread Starter W2014

    (@w2014)

    i know that this has to do with Hyyan WooCommerce Polylang Integration, because when i deactivate the plugin, everything works normal/as expected. The interesting thing is, when i deactivate the HWPI, its functionality, like categories languages, remains. That is crazy.

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    Categories and Languages is Polylang functionality not provided by this plugin.
    This plugin provides a compatibility layer between Polylang and WooCommerce.

    Check your permalinks, set and save permalinks for product in the Settings, Permalinks area.

    Do read the getting started guide on the GitHub wiki.

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    Also check your settings for how the language is supposed to appear in the url.
    The “right links” are not right for front end anyway, it would need to be shop.com/it or it.shop.com depending how you have set this up in Polylang

    Thread Starter W2014

    (@w2014)

    ok…i checked everything, everything is standard, it is a new install… i will still check all the options, but i see now that the plugin is not supporting the woocommerce 3.63, that i have…so this can be an issue…will there be a vrsion in the next period that will support the “new” woocommerce?

    2. you have it in the plugin features and before your plugin i could not see the categories in other languages, that is otherwise a polylang for woocommerce feature, as long as i know:

    [√] Product Translation

    [√] Categories

    • This reply was modified 4 years, 4 months ago by W2014.
    • This reply was modified 4 years, 4 months ago by W2014.
    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    Post Categories is a Polylang feature

    At the moment the only serious issue with 3.6x is with initial translation of variations, with a fix discussed on Github.

    There isn’t enough info in this report for me to tell what happened – you “wrong URL’s look more correct than your “right” urls so why do you think there is a problem? In any case it depends on your Polylang URL settings.

    If you still have a problem after following the getting started guide at:
    https://github.com/hyyan/woo-poly-integration/wiki/Getting-Started

    Then please post an issue with more details on github as there is no support on this forum

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    Do note as per the introduction to this plugin, Polylang URL modifications method “The language is set from content” is not
    supported, clear this in Polylang Settings and save. Set your Settings, Permalinks and save.

    Do make sure you can translate standard posts and post categories before starting on this plugin, this makes sure at least your basic Polylang setup is working.

    Thread Starter W2014

    (@w2014)

    Thanks a lot for the answers, i use the standard: The language is set from the code in the URL. The only issue i have so far it is with the language switcher, that adds -en to the url like this:

    shop-en.com/?post_type=product&lang=en
    instead:
    shop.com/?post_type=product&lang=en and the fact is, when i disable your plugin, it works normal, as soon as i activate it, the link changes.

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    which screen are you talking about?
    are you talking about admin screens?
    Your url on the front end should not normally look like this at all!

    normally the urls would be like eg:
    mysite.com/shop
    mysite.com/myproductcategory
    and translated either
    mysite.com/de/shop
    mysite.com/de/myproductcategorytranslated
    or
    de.mysite.com
    depending on the settings.

    Polylang has no setting called “The language is set from the code in the URL.”
    check /wp-admin/admin.php?page=mlang_settings

    Settings are:

    • The language is set from content – not supported
    • The language is set from the directory name in pretty permalinks
      Example: https://mysite.com/en/my-post/
    • The language is set from the subdomain name in pretty permalinks
      Example: https://en.mysite.com/my-post/
    • The language is set from different domains

    If your problem is specific to the shop page only, it may be because your shop slug is called “shop” and your domain name also contains the word shop, see:
    https://github.com/hyyan/woo-poly-integration/issues/400
    corrected in checked in version of pages.php.

    If you still have issues, raise on github and include the woocommerce status report and the settings from Polylang:
    /wp-admin/admin.php?page=mlang_settings
    and Permalinks /wp-admin/options-permalink.php

    Thread Starter W2014

    (@w2014)

    If your problem is specific to the shop page only, it may be because your shop slug is called “shop” and your domain name also contains the word shop, see:
    https://github.com/hyyan/woo-poly-integration/issues/400
    corrected in checked in version of pages.php.

    that solved the problem…it was the domain name (shop)…now i changed the -> woo-poly-integration/src/Hyyan/WPI/Pages.php and it works as expected.
    but what about updates? is there a long-term solution or do i have to change this on every update?

    the issue is with other integration plugins also…

    Thanks a lot for the great support…and i hope, the plugin will be further developed…

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    This is checked into the master source code for this plugin so it will be included in all future releases

    Thread Starter W2014

    (@w2014)

    for your information, the problematic part from pages.php:

    public function translateShopUrl($url, $language)
        {
            $result = $url;
    
            if (!is_post_type_archive('product')) {
                return $result;
            }
    
            $shopPageID = get_option('woocommerce_shop_page_id');
            $shopPage = get_post($shopPageID);
    
            if ($shopPage) {
                $shopPageTranslatedID = pll_get_post($shopPageID, $language);
                $shopPageTranslation = get_post($shopPageTranslatedID);
    
                // -- start shop domain name issue --
    			//if ($shopPageTranslation) {
                    //$result = str_replace(
                            //$shopPage->post_name, $shopPageTranslation->post_name, $url
                   // );
                //}
                // -- end shop domain name issue --
            }
    
            return $result;
        }
    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    Commenting it out only works if your shop page slug is the same in all languages.

    If your shop in French is shop.com/boutique then you need the code.

    The correct code is the latest checked in one on GitHub

    Thread Starter W2014

    (@w2014)

    i copied the latest pages.php from github now…and still i had to modify it a bit, by deleting the entire block from if ($shopPageTranslation)...(see bellow), otherwise the problem is stil there…it adds -en to the shop-page-domain, or, worse, when i go into the shop from the menu, it adds shop-en(the slug) to the domain link…so it looks like shop-enshop.com…etc…so that now i have from 133:

    133. `public function translateShopUrl($url, $language)
    {
    $result = $url;

    if (!is_post_type_archive(‘product’)) {
    return $result;
    }

    $shopPageID = get_option(‘woocommerce_shop_page_id’);
    $shopPage = get_post($shopPageID);

    if ($shopPage) {
    $shopPageTranslatedID = pll_get_post($shopPageID, $language);
    $shopPageTranslation = get_post($shopPageTranslatedID);

    }

    return $result;
    }`

    so this block must be deleted in my case, so the links work as expected:

    if ($shopPageTranslation) {
    		        		$slug = $shopPage->post_name;
            				if ( $slug != $shopPageTranslation->post_name ) {
            					$result = substr_replace( $url, $shopPageTranslation->post_name, strrpos( $url, $slug ), strlen( $slug ) );
            				}
                }

    if you would like…i can give you in private the links and passwords to the shop, because the shop is not public…so you can see by yourself.

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    There’s a very easy way to test whether your issue is related to github issue 400:

    First restore the release version of the code for this plugin.

    Next, edit your shop page slug, and change the slug to literally any string that is not included in your domain name!!
    for example if your domain name is shopshopshop.com, then changing the slug from “shop” to “shops” would fix the issue 400 problem.

    If you still have a problem after that, then it is a different issue related to your setup.

    If that fixes the problem then I would also be glad if you test the fix, which I have now retested and is still working for the use case in question.

    If you do have an issue with the fix or it is a different issue not related to #400, as I said before please raise on github and include the information requested such as the woocommerce status report and the settings from Polylang:
    /wp-admin/admin.php?page=mlang_settings
    and WordPress Permalinks
    /wp-admin/options-permalink.php

    Plugin Contributor jomo

    (@jonathanmoorebcsorg)

    Hi @w2014 , I thought of another use case: is your “shop” page also set to be the home page?

    in this case the fix above to replace only the last occurrence of ‘shop’ does not work since the page slug ‘shop’ is no longer added to the url when shop is the home page.

    to be clear, the fix for that is to add to the beginning of the function:

    
    if ( is_front_page() ) {
    	return $result;
    }
    

    this is now corrected in the master code:
    https://github.com/hyyan/woo-poly-integration/commit/7ef8ef6924b5750c6f47d7966376bcde156cb53a

Viewing 15 replies - 1 through 15 (of 16 total)
  • The topic ‘language added to the domain/PolyLang switcher’ is closed to new replies.