Jump to content
thirty bees forum
  • 0

How to edit hreflang in Thirty bees

Smile

Asked by Smile,

 Share

Question

Smile Contributor

Smile

Posted
Posted (edited)

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 by Smile
Link to comment
Share on other sites

27 answers to this question

Recommended Posts

  • 1
wakabayashi Community Regular

wakabayashi

Posted
Posted

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 🙂

Link to comment
Share on other sites
  • 0
Smile Contributor

Smile

Posted
  • Author
Posted

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

Link to comment
Share on other sites
  • 0
datakick Experienced

datakick

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

Link to comment
Share on other sites
  • 0
Smile Contributor

Smile

Posted
  • Author
Posted

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]

 

 

 

Link to comment
Share on other sites
  • 0
datakick Experienced

datakick

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

Link to comment
Share on other sites
  • 0
Smile Contributor

Smile

Posted
  • Author
Posted
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 ?

Link to comment
Share on other sites
  • 0
Traumflug Newbie

Traumflug

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

  • Like 1
Link to comment
Share on other sites
  • 0
Smile Contributor

Smile

Posted
  • Author
Posted

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

Link to comment
Share on other sites
  • 0
Smile Contributor

Smile

Posted
  • Author
Posted
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. 

Link to comment
Share on other sites
  • 0
datakick Experienced

datakick

Posted
Posted

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.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to question listing
×
×
  • Create New...