Last post 5 hours 23 min ago

Posts last week 94

Average response time last week 34 min

All time posts 67874

All time tickets 10492

All time avg. posts per day 20

Helpdesk is open from Monday through Friday CET

Please create an (free) account to post any question in the support area.

Please check the development versions area. Look at the changelog, maybe your specific problem has been resolved already!

All tickets are private and they cannot be viewed by anyone. We have made public only a few tickets that we found helpful, after removing private information from them.

#4545 – Duplicates redirect to the frontpage instead to the article

Posted in ‘sh404SEF’

This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Tuesday, 23 January 2018 15:15 UTC

hjosse-mein-allergie-portal-com

Dear Support-Team,
we are using the latest sh404SEF together with the latest Joomla 3 release.

From time to time we have issues with SEF duplicate entries of a new article, which redirects to the front page instead to the article.

This happens most of the time when we create a new article and directly after creation a user without the correct permissions is trying to access this page at the frontend.
sh404SEF seems then to save the menu ItemID of the default home page (frontpage) as primary duplicate and then shows the frontpage. Sometimes the frontpage content is visible, but the correct meta data of the article page is visible too.

This issue can be solved manually by just deleting the sh404SEF SEF-Entry including all duplicates and then access the page at the frontend again with the correct permissions from the menu.

Is there any way we can stop sh404SEF to redirect to the frontpage in this case for new articles at the first time?

Thank you and best regards!

Tuesday, 23 January 2018 15:21 UTC

wb_weeblr

sh404SEF seems then to save the menu ItemID of the default home page (frontpage) as primary duplicate and then shows the frontpage.

It does not "seem". That's exactly what it is doing: sh404SEF does not create any URL. It only get the URLs (the real ones, the non-sef ones) from Joomla and store them into the database. So it has no way of knowing which one is the right Itemid or not, it just records what Joomla gives to it.

a user without the correct permissions is trying to access this page at the frontend.

Why would that happen? why would that user see a link to an article that it is not supposed to access?

Rgds

Tuesday, 23 January 2018 16:20 UTC

hjosse-mein-allergie-portal-com

E.g. when a new article is not visible at the frontend yet, but you try to watch a preview of this new article with the preview link in the backend. Then of course you cannot see it in the frontend and get a redirect to the frontpage. This redirect seems to be saved in the SEF URLs, too even when the article is published later.

Also this happens when you try to open a new article by directly accessing the URL of this article after publishing it, but if you instead follow the links from the Joomla frontend menu to the article after publishing, the article is visible without problems and then it is also visible if you directly enter the URL of that article.

So the content always must be opened by using the frontend menu links the first time after it is created (direct enter of SEO URL in address bar causes problems). I am not sure if there is some kind of internal crawling mechanism which is saving new urls the first time they appear.

Any ideas what could cause this issues?

Tuesday, 23 January 2018 16:47 UTC

wb_weeblr

Any ideas what could cause this issues?

You have fully described the cause of this issue. Again, sh404SEF only records URLs created by Joomla. If Joomls, regardless of the reason, does not include an Itemid in the URL, or the wrong one, that's what's get recorded. We cannot control that at all. Indeed, we keep the first URL recorded as the "main" one.

When doing a preview, most of times Joomla does not include an Itemid (because no menu linking has been created).

Also this happens when you try to open a new article by directly accessing the URL of this article after publishing it, but if you instead follow the links from the Joomla frontend menu to the article after publishing, the article is visible without problems and then it is also visible if you directly enter the URL of that article.

Yes: before a link is displayed on the front end, or needed by Joomla otherwise, then no link exist at all, and this should create a 404.

direct enter of SEO URL in address bar causes problems

This would cause a 404 because the link does not exist in the database yet.

So the content always must be opened by using the frontend menu links the first time after it is created

It must be opened from any page where there is a link to it.

Rgds

Wednesday, 24 January 2018 09:08 UTC

hjosse-mein-allergie-portal-com

Could this behaviour be a result of a bad template design? 404 errors are not handled very well by default of that template, too.

Do you have a hind where we could start to look at?

Thanks for clarifying that sh404SEF is not the root of this issue. I think we can close this ticket now.

Wednesday, 24 January 2018 12:00 UTC

wb_weeblr

Could this behaviour be a result of a bad template design?

No, this is just exactly how Joomla routing works. The preview does not include an Itemid - and it can't because you have not yet told Joomla how you want the page to be displayed, so it cannot find an Itemid. The basic problem is that in Joomla URLs are based on menu structure.

One thing I would suggest is to be sure to disable "301 redirect from Joomla SEF to sh404SEF" under the "Advanced" tab of sh40SEF configuration. If enabled, this may make the matter worse in that case.

sh404SEF is in a way at root of the issue, as it tries to combat the duplicate content generated by Joomla using all sorts of Itemid and URL combination for the same actual content. So we group all those different non-sef URLs variations under the same SEF URL. What you see now is therefore a side effect of the good side.

Rgds

Thursday, 25 January 2018 10:02 UTC

hjosse-mein-allergie-portal-com

OK, thanks for the information on this issue. Lets close it for now.

This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.