Giters

inpsyde / multilingual-press

The multisite-based free open source plugin for your multilingual WordPress websites.

Home Page:https://multilingualpress.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Hreflang outputs on two locations

diedexx opened this issue · comments

commented

Version Information

  • MLP: 2.6

The issue

Hreflang links are in both the http headers as in the <head> section of the page. Only one of both (or a sitemap implementation) is enough for it to work. Outputting those links twice is causing unnecessary overhead (both processing and a larger response) for sites translated in many languages.

Also, there are two filters (mlp_hreflang_http_header and mlp_hreflang_html) which allow for modifications to the hreflang links. I would like to introduce a single filter to alter the data that is turned into the links, so I can easily add the 'x-default' link.

commented

Hey there,

I will only comment on the issue itself, not your current pull request.

Any insights as to what would be better in general?
I mean, HTTP headers get send for any HTTP request. The HTML elements only get rendered for front-end requests (with themes that fire off wp_head - which they should, anyway). What do you prefer? Or would it even make sense, in your opinion, to remove one implementation altogether?

Besides that, introducing a new filter to manipulate translations before they get passed on, to whatever hreflang implementation you have, makes sense to me.

commented

Hi @tfrommen,
I agree with you on that HTTP headers would be more preferable. Not only are they always rendered, they are also included in attachment request (for example when downloading a pdf file).

I've deliberately left both methods enabled just in case anyone relies on one or the other method to be present. I am currently not aware of any direct advantages that the html implementation has over HTTP header, so it makes sense to me to remove or disable the html implementation (in v3.0?).

commented

Having thought about this again, and also having read your last comment, I do think that rendering <link> elements might actually be better.

If the current request will not complete, but the user gets redirected (of course, before any HTML got rendered), the alternate language information wouldn't be of use at all. But still it would be included in the response when choosing HTTP headers.

Does that make sense?

Whatever we decide, I will not actually remove any of the current methods in v2, yes. If we decide to do so, then i will only be for v3.
Introducing the new filter will, of course, happen in both versions. Although the filters will be quite different.

Will review the pull request now.

commented

I tend to lean a bit more towards the HTTP header way. I think it would be better to have the possibility to provide translations for other file formats like pdf and also be able to have them show up in search engines the right way. I'm currently not aware if this is existing functionality in MLP. If there's no such feature or extension, someone might develop it.

I think that having this possibility might be better than trying to save time on redirected requests, since redirects are a fraction of all incoming requests. However, if you want to save some time on those requests, you can set the priority a bit higher for the http_header function, so you give other plugins the chance to redirect on priority 10 before setting the hreflang headers.

On the other hand, I can imagine that Google (who sure likes information) saves and uses all the links it can get, even those in the headers while redirecting. But, I cannot confirm that.