Please comment on:

the multiple pages pointing to the same article will have the same rel canonical (and i think this is not desirable in the general case (please comment here))

and also please comment about

• what about article urls generated e.g. by 3rd party plugins that have extra variables, should they get the same rel canonical ?
• what about hashtag, (normally rel canonical does not care about this) are there any plugins that would use it to differentiate the created page ? should we care for it ?

are there any other concerns ?

Google Support re "Use canonical URLs"
https://support.google.com/webmasters/answer/139066?hl=en

what about article urls generated e.g. by 3rd party plugins that have extra variables, should they get the same rel canonical ?

They should get the same base url in which the admin wants to access the page. I would assume this is the one from the menu (and if the Joomla SEF plugin is enabled the canonical should be what it produces for the page). If a menu item doesn't exist then it should fall back to the Category view if one exists. If a 3rd party menu item exists for the page then that should be used.

If 2 or more menu items exist (that create a different url) for the same article then we run into problems. In reality the admin shouldn't have done this (or used a menu alias) but maybe he had his reasons. The only way around this issue that I can see is have some sort of toggle or rank on the menu item to indicate which one should be used for canonical links.

If a visitor is on the article page and say changes the sort order of the comments for the page ( example 3rd party component) which then adds new variables to the url, the canonical for this page should always be the base url as defined in the menu (as we are assuming this is the one the admin wants).

what about hashtag, (normally rel canonical does not care about this) are there any plugins that would use it to differentiate the created page ? should we care for it ?

What ever is defined in the menu structure should be the canonical of the page. I wouldn't include a hashtag myself but maybe someone else has a reason...

Just to clarify:
This is not a fix but a new feature for Joomla! as we only used the canonical until now to redirect (via the sef plugin) to a site which would have the exact same structure but a different domain.

@infograf768 wow I did not realize that and I know I am not the only one. A number of component developers I know think canonical links are just broken in Joomla.

In the site domain I just list my 1 domain and assumed it would work as I have described above. A more informative tooltip needs to be added but then again hopefully we can get canonical links working as they should with this pull request (if so the tooltip should be changed anyways).

Thinking more on the issue I still see it as a bug since Joomla produces different canonical links for the same page. It may use the preferred domain but you can still get different canonical links for the same page.

Look at Google's resource on the subject
https://support.google.com/webmasters/answer/139066?hl=en

@ggppdk I am going to try again tomorrow morning added the 2 pull requests to my site to see if I can get the canonical links working as you described (and as they should). I'll update you once complete.

@infograf768

This is not a fix but a new feature for Joomla! as we only used the canonical until now to redirect (via the sef plugin) to a site which would have the exact same structure but a different domain.

It is a bug fix (propably rarely needed) because
e.g. for
http://localhost/component/content/article?id=72:popular-tags

1. Without adding the domain we have no rel-canonical added

aka rel-canonical is implied to be same as current URL
http://localhost/component/content/article?id=72:popular-tags

2. Adding domain to be www.somedomain.com then rel-canonical is added as:

http://www.somedomain.com/component/content/article?id=72:popular-tags

so it is wrong in both cases, only thing corrected by SEF plugin is the domain, which continues to work after this PR is added

to use rel-canonical for redirecting to same structure at the expense of having a wrong canonical is not worth it ?

@eSilverStrike
Please test with latest staging
-- the other PR for maintaing current menu was already merged
so you only need to use latest staging + patch tester component and apply only this PR

I still think it is a new feature, but I like it and it works here !
Any way to also get it for category?

If this code would get an option to disable canonicals in view.html.php or if it would become part of a separate plugin that we can disable / extend / exchange it would be OK for me. But please don't add again (we had this already in Joomla) more or less wrong/misleading or unnecessary canonicals without any chance to get rid of them without an additional "killer" plugin.

@ReLater

If this code would get an option to disable canonicals in view.html.php or if it would become part of a separate plugin that we can disable / extend / exchange it would be OK for me. But please don't add again (we had this already in Joomla) more or less wrong/misleading or unnecessary canonicals without any chance to get rid of them without an additional "killer" plugin.

i had made several postings to related issues

• asking for rel canonical not to be added by the SEF plugin, (which in several cases it was wrong)
• and instead leave the responsibility for this to the component views !!!

Finally it was done

This PR does not effect 3rd party component views
it effects the Joomla article view, and it effects it in a correct way

So your posting is not relevant

Now if you want to customize the rel-canonical of Joomla article view then you should already have / need such a plugin, that will iterate through the array of head links, find the rel canonical and replace it

I still think it is a new feature, but I like it and it works here !
Any way to also get it for category?

Code should be similar, just in category view it will need some more care !
because filtering variables are allowed in the URL thus these should be part of the rel-canonical ...

Also in the case of 3rd party plugins adding custom URL variables to Joomla article view links
to create different content

we could do this, add all non-recognized URL variables as part of the rel-canonical URL, this will fix the reported issue , while maintaining compatibility of current behaviour

any comments about the above ?
is it needed ?

So your posting is not relevant

It's relevant. You expect that "your" canonicals will be all perfect. They only will be if the individual Joomla is a perfectly structured system (menus etc.). If it would be that easy to find the correct canonicals we would find several perfectly working plugins in JED. I only found SEO killers producing extra work in the last few years.

Now if you want to customize the rel-canonical of Joomla article view then you already have a plugin

I don't want to customize them. I personally don't need them at all. I'm talking about users that will find several additional links in serach engines because unnecessary and wrong canonicals (mis)led them there.

and instead leave the responsibility for this to the component views

From my point of view that's a bad solution if one cannot disable this "feature" then. Or better: it should get an option to explicitely activate it.

asking for rel canonical not to be added by the SEF plugin, (which in several cases it was wrong)

Yes, that was a stupid idea.

From my point of view the only correct place is an additional plugin, again: that we can disable / extend / exchange / maybe configure. Time would tell...

I think the best case solution is that the component deals with its own canonical links (after any SEF plugin has rewritten the url) since there will be situations where a plugin will not know what the canonical should be (for example as no menu item exists for the page as it was linked to from another page of the component). Some pages could require the canonical to include the url variables when others would not. For example a page that you can sort the content on. You should not include the url variables for sorting just the url required to access the page.

That being said not all components support canonicals (like the tags component). It would be nice if you could have a plugin that could at least deal with the pages that have menu links. We know these are landing pages designated by the admin and we know what url is needed.

That being said I am just excited that we are getting canonicals for articles (and hopefully categories) figured out!

It's relevant. You expect that "your" canonicals will be all perfect. They only will be if the individual Joomla is a perfectly structured system (menus etc.). If it would be that easy to find the correct canonicals we would find several perfectly working plugins in JED. I only found SEO killers producing extra work in the last few years.

hhmm, i do not understand your argument

The 3rd party plugins know better than the component view itself what is the appropriate rel canonical ?
are you worried that some 3rd small plugins "fixing" "rel-canonicals" will become redudant ?

• i do recognize that the problematic URLs can be rare

but having proper rel-canonicals is not a feature, to be left to a 3rd plugin to "fix" something that people may look as bug, and expect to work out of the box

I don't want to customize them. I personally don't need them at all. I'm talking about users that will find several additional links in serach engines because unnecessary and wrong canonicals (mis)led them there.

Exactly and this PR fixes the issue !

From my point of view that's a bad solution if one cannot disable this "feature" then. Or better: it should get an option to explicitely activate it.

Explicitely activate correct rel-canonicals ?
This makes little sense

The question is if this PR adds correct rel-canonical , if yes accept PR if not then dismiss the PR

From my point of view the only correct place is an additional plugin, again: that we can disable / extend / exchange / maybe configure. Time would tell...

You do not need to add the rel-canonical inside plugin code to be able to override it

• you can use event onBeforeCompileHead event !
• continuing the above, moving the code to a plugin, is not only unneeded but also problematic

you would create 1 plugin per view or component ? (so many plugins)
you would create 1 master plugin that knows about all component views ? this is the solution we went away and everybody agreed it was a good thing for all components

@ggppdk Okay I don't see it working but it is probably something I have done wrong. I have retrieved the latest code (staging branch) from joomla-cms. applied the file change from your pull request.

I then installed the Joomla using the English sample data. In global configuration I have SEF URLs and Use URL Rewriting enabled. I also tested with and without adding my ip the Joomla SEF plugin.

I then tested using the About Menu item and the canonical link is only found in the source if I have my IP set in the Joomla SEF plugin and it still only returns what the url is currently being used to access the page and not the menu url for the About page.

What step am I missing here?

I said: All 3rd canonical plugins that I know and that I tested are bull shit and produce too many errors.
And I said: You are convinced that your canonicals are perfect in any case. I am not.
And I said: If the way you produce canonicals would be reliably correct for any Joomla page (in this case article views) in any environment any of the 3rd plugins would work the same way.

you would create 1 master plugin that knows about all component views ?

In principle I don't see a problem to integrate all Joomla core components views in a single core plugin. We have $context and JInput to identify them. The mistake was to integrate canonicals in SEF plugin.
3rd components are not affected.

you would create 1 plugin per view or component ? (so many plugins)

In principle I also don't see a problem with 1 plugin per component. Have a look at com_fields or com_search or com_finder. Freedom of choice ;-)

you can use event onBeforeCompileHead

I know that. Means: Installing / programming a plugin to get rid of canonicals that were set somewhere without any chance to disable them or override them before they were created.

this is the solution we went away and everybody agreed it was a good thing for all components

Everybody? A conversation between programmers (living in a theoretical ideal Joomla world) or between users (that are confronted with additional SEO work that they wouldn't have to do if they just could switch off canonicals) ? [sarcasm end]

@ggppdk okay I figured out my mistake (missing code).

It works!

The only change I would make is that it returns (with Joomla SEF disabled):

<link href="/about" rel="canonical" />

According to Google https://support.google.com/webmasters/answer/139066?hl=en#2 you need to use absolute paths rather than relative paths so we should include the domain as well.

I also confirmed that it works when you have a category menu item which contains articles. If you access those articles (these articles don't have direct menu links) in the category the correct canonical comes up.

Do you think you can get canonicals working for categories now? For example the blog category can be accessed via:

localhost/index.php?option=com_content&view=category&layout=blog&id=9&Itemid=116

but it should return the category menu item for the canonical

localhost/blog

@ReLater

And I said: If the way you produce canonicals would be reliably correct for any Joomla page (in this case article views) in any environment any of the 3rd plugins would work the same way.

The view should know which pages are the same, because the view is deciding which content to show ! (via of course calling model's methods)
The above plus the current menu item , (as you can have multiple menu items pointing to article view with different module assignments) will give you the rel-canonical URL

In other views
e.g. in category view you can not use the exact same code
as the category URL is not enough, you will also need to add the filtering variables if these exist in the current URL, and other URL variables (like the current page number !)

that is why this PR included only article view, the category view needs a more work !

@eSilverStrike

you need to use absolute paths rather than relative paths so we should include the domain as well.

Yes it is recommended (but not required)

• that rel-canonical contains the prefered domain, and prefered protocol

i ll update PR to use current one, and then is someone has configured prefered domain protocol in SEF plugin, then it will be replaced there (this is working already)

Also the rel-canonical needs to include current page if article is paginated
(another thing that this PR needs to consider)

https://support.google.com/webmasters/answer/1663744?hl=en&ref_topic=4617741

But i noticed that rel="next" and rel="prev" in previous / next page links in Joomla article pagination are missing

• Instead the rel="next" and rel="previous" are used to indicate next and previous article (of the article's category)
  which seems wrong to use such a thing in article view

Because you are saying to the search engines that multiple articles are a single paginated article
Am i wrong in this ? please see link i posted above

Also both the next article page and the next article are using the word "Next" !

Also the rel-canonical needs to include current page if article is paginated
Here is one reason why a plugin version for canonical links will not work in all cases and for the most part canonical links should be handled by the component itself (unless a menu item exits for the page then it can make things easier.

I wonder if the second option is best "Specify a View All page" from your Google link. Have the canonical for all pages of the article be used for each page of the article since each pages is part of the whole article. I am sure some people will disagree with me here.

Instead the rel="next" and rel="previous" are used to indicate next and previous article (of the article's category)
which seems wrong to use such a thing in article view

Your right but I don't like the idea of switching from the Category rel prev and next to the article that has multiple pages and then back again. From my understanding there really is no easy way to handle this type of situation when you basically have pages within pages. I think the best plan would be to leave it and hope Google will figure things out. It shouldn't be a problem especially if we do what I suggested above and point the canonical of each page of the article to the all pages display.

Looking at the article menu item I see you can't specify for an article to display all pages or a certain page to land on. It's too bad that the URL is messy as well with the showall variable always in there. It should have been setup where all pages uses the same URL as a normal non-paged article and then to view different article pages Joomla would have just added page=1 or page=2, etc...

Also both the next article page and the next article are using the word "Next" !

Yeah the pages of the article navigation should maybe have used numbers

@ggppdk so once you make the changes and figure out the best approach to multi page articles what is the next step to get the pull request added to the main repository?

after 2 successfull test the PR got the Ready To Commit (RTC) status, then is up to the mantainers to evaluate/review the PR , if all is ok then is merged on the current staging once merged in staging will be released in the next available release

@eSilverStrike

Please i will update this PR next days, as there is nothing urgent about this PR

I know this is effective solution but some users may currently use a plugin that do the same.
If yes then after this patch there will be two canonical URLs and google will ignore it at all.

There is an old but interesting article about canonical URLs at https://webmasters.googleblog.com/2013/04/5-common-mistakes-with-relcanonical.html

There will not be 2 urls

Such plugins are (should be) examining the head links and replacing any existing rel-canonical link

• if they are not doing the above, then they need to be fixed

e.g. if we had enabled domain setting in the SEF url then a rel-canonical is already added that needs to be replaced

Not fixing the rel-canonical issue,
because some SEO plugins are not checking head links if rel-canonical exists
makes little sense

The only real problem here is can we add a proper rel-canonical for "all" cases of the article view links ?

I can use SEF without SEF plugin.

After more search IMO this can be fixed in HeadRenderer::fetchHead() and only show the first canonical URL.

IMO option to enable/disable canonical URLs in com_content component (similar to Modern routing) would reduce issues in J3.x

One article can have a few variants/pages.

Each page has its own canonical URL (ignore empty showall parameter), this way you can check how many pages was viewed/read in ex. google tools.

If article has only one page then parameter showall should/may be ignored = 1 canonical only.
If article has more pages then URL with showall=1 (means view whole article) should have different canonical URL.
If there is parameter '&tmpl=...', 'limitstart=...' in article view I would ignore it, the same for others unknown parameters like utm_...

AMP plugins for mobile browsers probably should work with that.

So when will this fix get merged with Joomla and released?

@eSilverStrike in first Step every Pull Request (PR) needs 2 successfully Tests, this has 0. It would help if you test it.

I did test it as stated above. Do you mean I need to add a review for the changes of the successful test?

https://github.com/joomla/joomla-cms/pull/18341/files

@eSilverStrike please mark your Test as successfully:

• open Issue Tracker
• Login with your github-Account
• Click on blue "Test this"-Button above Authors-Picture
• mark your Test as successfully
• hit "submit test result"

I have tested this item ✅ successfully on 73ff26f

Works as specified. Article from different URLs have same canonical url.

Still need to figure out best way to handle canonicals for articles with multiple pages.

Thanks anyone spending time on this PR
No interest in spending more on it by me

So was this merged then?