How to edit hreflang in Thirty bees

[Smile]

After migrating there appeared a small issue with the hreflang.  My custom hreflang module makes it easy to manage those thing:

<link rel="canonical" href="https://website.nl" />

<!-- hreflang -->

               <link rel="alternate" hreflang="nl-be" href="https://website.be/" />

               <link rel="alternate" hreflang="nl-nl" href="https://website.nl/" />

<!-- hreflang -->

But now I see that TB is adding free of charge some wrong hreflang code.

<link rel="alternate" href="https://website.nl/" hreflang="nl-NL">

<link rel="alternate" href="https://website.nl/" hreflang="x-default">

<link rel="alternate" href="https://website.nl/" hreflang="nl-BE">

<link rel="alternate" href="https://website.nl/" hreflang="fr-FR">

Where can I manage this code or disable it?

Edited February 15, 2019 by Smile

[wakabayashi]

Have you installed these languages?

I have just checked my own site and got:

<link rel="alternate" href="https://www.spielezar.ch/" hreflang="de-de">
<link rel="alternate" href="https://www.spielezar.ch/" hreflang="x-default">

This is correct for my site, but I have only one language installed... 

These meta tags are probably hardcoded in a php file... I guess it would be better to find the reason, why tb adds the wrong one, than to just remove them. That would help other people as well 🙂

[Smile]

The issue is that those 2 languages are only assigned to a different multistore, the Belgium store:

 

<link rel="alternate" href="https://imkershop.nl/" hreflang="nl-BE">

<link rel="alternate" href="https://imkershop.nl/" hreflang="fr-FR">

 

What I would expect and would work as it should:

<link rel="alternate" href="https://website.nl/" hreflang="nl-NL"> (as currently)

<link rel="alternate" href="https://website.nl/" hreflang="x-default"> (ok, optional...)

<link rel="alternate" href="https://website.BE/" hreflang="nl-BE"> (should be other store url)

<link rel="alternate" href="https://website.BE/" hreflang="fr-FR"> (should be other store url)

 

So currently hreflang does not take into account where they are enabled and where not.... They point to sites where the language even does not exists.... I have a great module to manage this by hand and as it is SEO very important can we agree that its a bug that needs to be fixing a.s.a.p.? Or make the use of hreflang in TB possible to switch off so one can use it own module....

[datakick]

5 minutes ago, Smile said:

So currently hreflang does not take into account where they are enabled and where not.... They point to sites where the language even does not exists.... I have a great module to manage this by hand and as it is SEO very important can we agree that its a bug that needs to be fixing a.s.a.p.? Or make the use of hreflang in TB possible to switch off so one can use it own module....

It is a bug, but it's also very specific. You need to have multistore enabled, and distinct set of languages used by each stores. With this configuration, tb will indeed emit alt links for languages used in other stores. This should be fixed.

Should thirtybees emit alt link for different store? That's questionable. Probably not, imho. While it would make sense for your specific use case, when you use multistore as a language selector, it would not work in general. Especially when stores have their own products. 

I also agree that there should be a switch to turn off this feature, and a hook to alter alt links just before they get rendered to the html.

[datakick]

Tracked here: https://github.com/thirtybees/thirtybees/issues/848

[Smile]

@datakick Would you be interested to add a switch to the core? And if so what would be the time to implement it and get it working? I am happy to sponsor it!

[datakick]

The fix for this, including new back office switch, is scheduled for the next release. @Smile there's no need to sponsor individual fixes, especially when they are trivial 🙂 But feel free to join patreon program (if you haven't already), that's always appreciated! 

[Smile]

I'm already on patreon, but system is not so handy for business users 😉 Thank you for the fix implemented already...

Edited February 15, 2019 by Smile

[Smile]

But did you make the switch as well in the FrontController.php? If so where is it located in BO? I updated the file already...

[datakick]

2 minutes ago, Smile said:

But did you make the switch as well in the FrontController.php? If so where is it located in BO? I updated the file already...

There are multiple commits [ 1 , 2 , 3 ]related to this, you'll need all 3. Then you get this:

 

[Smile]

Found it thanks so much!

[datakick]

21 minutes ago, Smile said:

I'm already on patreon, but system is not so handy for business users 😉 

I believe @lesley is planning to move away from patreon to some different solution.

What exactly is not 'handy for business user' ?

[Smile]

Paypal, and they have no invoices! Anyhow I now doubled my patreon 😉

 

I can not find the file configuration.xml in the current installation. I think it is only used with new installations...? 

I added the changes to the first to files....

 

[ThirtyBeesException]

Call to undefined method Configuration::getWithDefault()
at line 133 in file controllers/admin/AdminMetaController.php

128.                 'title'      => $this->l('Emit SEO fields') ,
129.                 'hint'       => $this->l('Enable this option to include metadata for canonical url, hreflang, and next/prev page'),
130.                 'validation' => 'isBool',
131.                 'cast'       => 'intval',
132.                 'type'       => 'bool',
133.                 'value'      => Tools::isSubmit('TB_EMIT_SEO_FIELDS') ? (int)Tools::getValue('TB_EMIT_SEO_FIELDS') : Configuration::getWithDefault('TB_EMIT_SEO_FIELDS', true),
134.                 'auto_value' => false,
135.             ]
136.         ];
137. 
138.         $urlDescription = '';

    AdminMetaControllerCore->__construct - [line 125 - classes/controller/Controller.php] - [2 Arguments]
    ControllerCore::getController - [line 829 - classes/Dispatcher.php] - [1 Arguments]
    DispatcherCore->dispatch - [line 63 - admin/index.php]

 

 

 

[Traumflug]

What's the point of this switch? It's hardly imaginable a merchant does not want SEO fields.

[datakick]

9 minutes ago, Traumflug said:

What's the point of this switch? It's hardly imaginable a merchant does not want SEO fields.

Third party modules, mostly. Since ps16 does not have this, there already exists many modules that implements this functionality, and then some. It makes sense for some merchants to turn the default implementation off, and use this 'advanced module' implementation instead.

Anyway, I think it's a good strategy to have features hidden behind a switch (and they already usually are).

[Smile]

12 minutes ago, Traumflug said:

What's the point of this switch? It's hardly imaginable a merchant does not want SEO fields.

The current implementation is not advanced enough for multistore with multiple languages switched on and off depending on the stores. Very useful.

 

 

One of you knows the location of  configuration.xml ?

[toplakd]

30 minutes ago, datakick said:

What exactly is not 'handy for business user' ?

You can not support thirty bees on patreon out of european union without paying unneeded VAT if you have valid Tax number.

[Traumflug]

7 minutes ago, Smile said:

The current implementation is not advanced enough for multistore with multiple languages switched on and off depending on the stores. Very useful.

It'd be better to advance the implementation rather than adding more pain to merchants. Setting up a shop with thirty bees* is pretty complex already and burdening merchants with even more complexity, like additional switches to consider, is counterproductive.

 

* This probably applies to our fellow competitors as well, thirty bees should be better than these.

[Smile]

Truly I think making it advanced is an option but as there is so much to do in TB that this is the best option for now. 

I have a whole module to manage the hreflangs, to implement this would be great but not so easy. Also it would make things not more easy for starting merchants. But who said that running an online shop is easy? And what user base has TB in focus? Mini shops or serious users who know their SEO....

[Traumflug]

4 minutes ago, Smile said:

And what user base has TB in focus?

Those who want to run a shop and sell goods rather than wrestle with technical details of the shop software.

[Smile]

Just now, Traumflug said:

Those who want to run a shop and sell goods rather than wrestle with technical details of the shop software.

Go to lightspeed 😉 I would say. Running your own instal is always a technical challenge. No matter the system TB, PS, Wordpress, Drupal, you name it. 

[Smile]

Can someone explain to me where to add the third change in a installation?

[Traumflug]

10 minutes ago, Smile said:

Running your own instal is always a technical challenge.

Maybe it's disappointing to some of you, but thirty bees is going to make running a shop easier, not harder.

[datakick]

It's simply not possible to implement feature like this and cover needs of every merchants. 

The default implementation is pretty solid, and meets the requirements of almost everybody. But then there are few use cases when it doesn't. 

I know about two already:

- multistore / one store per language setup -- if we wanted to support this in the core then it would actually require quite complex configuration page, and that would definitely not make things easier to setup... and no, it's not really possible to resolve this automagically / algorithmically. Some user input is required here

- custom canonical links / relations between different products - I remember there was some thread asking about this recently. Somebody wanted to group similar products under one canonical product umbrella to avoid duplicate content penalisation. Again, if we wanted to have this in core, it would require quite an extensive config page  

And I'm sure there are other scenarios when the default implementation just doesn't work out of the box. But what's worse, it actually blocks merchants from implementing alternative. When you install any seo module, you will get conflicting metadata in html markup, and that can actually hurt from the seo perspective. That's why it's definitely good to have an option to disable this default implementation.

[Traumflug]

44 minutes ago, datakick said:

But what's worse, it actually blocks merchants from implementing alternative.

For tweaking default behavior there's the well established hooks mechanism.

[toplakd]

1 hour ago, Traumflug said:

but thirty bees is going to make running a shop easier, not harder

and less time spent administrating the orders as everything runs so smooth and fast in back office.