User tests: Successful: Unsuccessful:
Pull Request for Issue #11165.
This PR adds a new option to the language filter plugin where the user can select the redirect HTTP status code. The default value for this option is a "302 Found" redirect.
This means, that by default all language filter redirects will be a 302 redirect, users can now change the redirect code in the language filter plugin options.
This will allow greater flexibility for those who want to change the redirect code, a similiar option exists in com_redirect.
See https://tools.ietf.org/html/rfc7231#section-6.4 (300 to 307 redirects) and https://tools.ietf.org/html/rfc7238 (308 redirect)
Status | New | ⇒ | Pending |
Labels |
Added:
?
?
|
@infograf768 Imho, it's stupid to allow the user selecting redirect values which are wrong.
Also I think it's stupid to allow selecting cacheable redirects (301, ...) and at the same time disable cache. There is no point using 301 then to begin with.
Imho, we should not allow the user to make that decision. It just adds possible wrong configurations.
The only potentially correct redirects are 302 and 303. 302 seems to be what Google does and thus I would use that and hardcode it.
Instead look at the reasons why you want to use 301 to begin with and debunk that rumor about duplicate content...
Also I think it's stupid to allow selecting cacheable redirects (301, ...) and at the same time disable cache. There is no point using 301 then to begin with.
IMHO, what you are saying is the same thing as saying that adding caching HTTP headers to a "200 Ok" is stupid because "200 Ok" is not cached by default.
Yes, 301/308 codes are cached by default. that doesn't means the HTTP protocol does not allows to disable the cache in those redirects.
A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
Reference: https://tools.ietf.org/html/rfc7231#section-6.4.2
As you can see HTTP protocol specification allows that behaviour.
If it should be used in this context is another question. I used because the way the language filter is contructed you need to not cache the 301/308 redirects.
Instead look at the reasons why you want to use 301 to begin with and debunk that rumor about duplicate content...
I'm not a SEO expert to do that analysis, but it seems joomla 301 redirect for this already has an history here: added in #5135, then removed in #5140, and readded in #8894.
Anyway this PR is my proposal to solve the issue (make 302 default) and give users the ability to change the code if they want.
If you propose to just change to 302, please make a PR for that.
Also, i have no problems in closing this if mantainers decide to just hardcode the 302.
IMHO, what you are saying is the same thing as saying that adding caching HTTP headers to a "200 Ok" is stupid because "200 Ok" is not cached by default.
Not exactly the same, because with redirects we have the choice between cached redirects and uncached. Just select the proper one for the usecase. "301 Moved Permanently" just isn't the correct one if you have to disable caching at the same time.
Yes, you can do that and some do, but this doesn't mean it's the correct thing to do.
I'm not a SEO expert to do that analysis, but it seems joomla 301 redirect for this already has an history here: added in #5135, then removed in #5140, and readded in #8894.
I'm also no SEO expert, but I have read a bit about the duplicate content issue where this whole 301 idea seems to stem from. If that is debunked, the need for a customisable redirect goes away as well.
But main point is that it's just not logical to use a 301 in that context because we don't move something permanent. The fact that we want to disable caching (as we have issues when it's enabled) just proves that fact. Just using 302 or even the default 303 would solve all issues without adding any to my knowledge.
@Bakual sincerely, please do not misunderstand me. i understand the logic in your point, but i have some doubts on this because of my lack of SEO knowledge.
IMHO the most correct solution would be to have redirect codes according to the redirect type:
/defaultlang*
to /*
(remove language code is set to Yes)
IMO should be a 301.
/*
to /defaultlang*
(remove language code is set to No)
This is where i have most doubts. Should it be a non cachable 301 or a 302 (or 303)?
/*
can also redirect to /otherlang*
(cookie language based redirect) and in this case it should be a 302 (or 303)/*
to /otherlang*
(cookie language based redirect)
IMO should be a 302.
So, IMO neither a full non cached 301 or a full 302 (or 303) are totally correct implementations.
So if we don't want to give the user the ability to change the code (like this PR does) joomla should adjust the redirects according to the redirect type. And still a decision is needed in which one is the most correct to be used in th /*
to /defaultlang*
case. Should be a non cachable 301 or a 302 (or 303)?
With that said, i leave that decision to the mantainers.
Again, 301 is meant if an address has been moved permanently to another location, meaning the origin address doesn't exist anymore and shouldn't be used. Clients are expected to update their stored links. A podcast reader for example would update the stored URL of the podcast and follow the new address from this point onwards.
In our case, the origin URL is still perfectly valid and in fact no redirect would be needed from a technical view. We just redirect to have some nicer URL. Thus I don't think a 301 is appropriate.
But most important, a 302 should work fine in this case as well. So I don't see a reason to add multiple lines of code just to have a 301 (with disabled caching) that adds no value.
If Joomla's behavior is to redirect /defaultlang*
to /*
when remove language code is set to Yes that to me warrants a 301 redirect because you've configured the site to not use URLs with the language code for your default language. https://www.joomla.org/3/en/*
redirects to https://www.joomla.org/3/*
so to me it's correct that all the en
routes have a 301 to the non-coded routes. On the reverse of that http://resources.joomla.org/{non-language-code-segments}
redirects to http://resources.joomla.org/en/{non-language-code-segments}
so again I would expect 301s here. For these default conditions, the site owner has stated that there is NOT "real" content at the redirected pages.
For the other cases, consult a SEO expert
this code will do this:
/defaultlang*
to/*
(remove language code is set to Yes) = 301/*
to/defaultlang*
(remove language code is set to No) = 301 (not cached)/*
to/otherlang*
(cookie language based redirect) = 302
// Set redirect HTTP code to "302 Found".
$redirectHttpCode = 302;
// If selected language is the default language redirect code is "301 Moved Permanently".
if ($lang_code === $this->default_lang)
{
$redirectHttpCode = 301;
// If configured to always use a sef prefix for default language we cannot cache this redirect in browser.
// 301 is cachable by default so we need to force to not cache it in browsers.
if ((int) $this->params->get('remove_default_prefix', 0) === 0)
{
$this->app->setHeader('Expires', 'Wed, 17 Aug 2005 00:00:00 GMT', true);
$this->app->setHeader('Last-Modified', gmdate('D, d M Y H:i:s') . ' GMT', true);
$this->app->setHeader('Cache-Control', 'no-store, no-cache, must-revalidate, post-check=0, pre-check=0', false);
$this->app->setHeader('Pragma', 'no-cache');
$this->app->sendHeaders();
}
}
// Redirect to language.
$this->app->redirect($redirectUri, $redirectHttpCode);
Now, it's up to the mantainers to decide which way to go.
My vote to your last comment:
/defaultlang* to /* (remove language code is set to Yes) = 301
/* to /defaultlang* (remove language code is set to No) = 301
/* to /otherlang* (cookie language based redirect) = 302
about if suggested code does the above will need to test first
my vote goes to that too.
Note: if decided to go that way i will make a new PR for that and close this one.
From what i read nobody said that the following should be 301, so we have a minimum agreement for it (and users will open new issues in the future about something that everybody agrees it is wrong to use 310):
/* to /otherlang* (cookie language based redirect) = 302
And since there was no agreement for this, you can leave it unchanged:
/defaultlang* to /* (remove language code is set to Yes) = 301
/* to /defaultlang* (remove language code is set to No) = 301
so i think it is good to make your PR now that everything is fresh in everybody mind,
Status | Pending | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2016-07-19 17:11:30 |
Closed_By | ⇒ | andrepereiradasilva |
@Bakual
would you be satified with this?