— SYSTEM DETAILS —
self hosted on DO
Ghost version: 5.5
Node version: 14.19.3
db: mysql
ghost doctor identifies no errors
— ISSUE —
After upgrade to v5.x amp versions of urls in routes.yaml > collections causes an ugly browser error: “The page isn’t redirecting properly”. The inspector tools network tab show a long chain of 301 redirects to the same url. Presumably it just times out.
I should have been more precise. I do not necessarily attribute the issue to v5. Rather, I did not experience the issue prior to v5, and do experience it after v5. The source could be something else.
The redirects.json file contains one redirect for a specific post, so I do not think that is the issue.
To anticipate a follow up, no there are no redirect rules in NGINX except for http → https, and www. → non-www. Those have been in place since day one.
@RyanF Hi Ryan, after lots of testing and experimentation, I have finally isolated the cause of this error.
Two conditions must be true:
Set up a collection with a permalink, like this:
collections:
/docs/:
permalink: /docs/{slug}/
filter: primary_tag:docs
data: tag.docs
template: tag
Modify the tag taxonomy to use the tag slug, like this:
taxonomies:
tag: /{slug}/
author: /author/{slug}/
when you navigate to /docs/some-article/amp/, the inspector shows a long series of 301 redirects and then stops with this message in the browser: “The page isn’t redirecting properly.”
Yes, adding `/tag/’ or ‘/topic/’ to the tag taxonomy route resolves the issue. However, it is removed for a reason. Adding it back would require a lot of redirect logic.
Any update on when this might be resolved? It is a chronic issue with Google indexing in the search console. Ghost pages generally do quite well but this causes a failure.
I was never able to replicate this issue. However, I think that there’s a conflict being created in the routing: there are two routes at /docs/. This conflict is likely causing unexpected behavior. That would also explain why adding the /tag/ or /topics/ back in helps to alleviate the issue.
Alternatively, you could try changing the /docs/ collection to something else, to avoid the conflict at that point.