Flyout menu: all version's links on a 404 page point to 404.html

[Proggle]

This is crossposted from the godot documentation github, since the issue seems to be with readthedocs rather than with their specific implementation.

Issue description:
I was having an issue implementing something in godot 3, and was reading a thread about it. I clicked a link someone gave to documentation about rigid bodies ( https://docs.godotengine.org/en/stable/classes/class_rigidbody.html? )

This class page no longer exists in godot 4's documentation , so I got a '404' page, which said
"Sorry, we couldn't find that page. It may have been renamed or removed in the version of the documentation you're currently browsing."

So I clicked on the 'version' picker to try to change versions to godot 3.

Unfortunately, the version change links for 'not found' pages don't link to the correct place - if I click '3.6', it should link to https://docs.godotengine.org/en/3.6/classes/class_rigidbody.html . Instead, the links take you to the 404 page for that version ( https://docs.godotengine.org/en/3.6/404.html ). This is very unhelpful.

Expected Behavior
If it can't find the page for the 'stable' version, it should still let me select an older version and look for that page in that version's documentation.

An added feature to make things easier would be for readthedocs to check if that page exists in different versions of the code, and list or highlight the ones where that page exists in the documentation.

[humitos]

the links take you to the 404 page for that version

This is very unfortunate 😄

The flyout link, instead of pointing to the 404.html it should point to https://docs.godotengine.org/en/<version>/classes/class_rigidbody.html. In particular, for version 3.6, the link should be https://docs.godotengine.org/en/3.6/classes/class_rigidbody.html --which returns a 200.

An added feature to make things easier would be for readthedocs to check if that page exists in different versions of the code, and list or highlight the ones where that page exists in the documentation.

This would be awesome 💯 . However, it could be a problem for projects with many versions, since Read the Docs would need to do a HEAD request to S3 for each of those versions, making the final response pretty slow. There may be other non-that-simple ways to implement this that could be a better implementation, tho.

[Proggle]

This would be awesome 💯 . However, it could be a problem for projects with many versions, since Read the Docs would need to do a HEAD request to S3 for each of those versions, making the final response pretty slow. There may be other non-that-simple ways to implement this that could be a better implementation, tho.

I agree that spamming a couple hundred HEAD requests immediately could be too much, though it seems like it'd be better than the alternative of having no indication of which version is valid (which, from a user perspective, means they need to manually click through each version's page and check if it's a 404 after loading, which would definitely take longer to do).

[SyedMa3]

Hi @humitos I am interested in working on this bug. But I am unable to figure out the files related to this bug. Can you please help me out? Thanks

[humitos]

We re-wrote the flyout menu completely in the new implementation of it via Addons.

The new flyout links to the "home page of each version" instead of the "exact page the user is reading in a different version". I think this is the correct approach because we can't guarantee the page the user is reading exist in all the versions listed in the flyout. @Proggle would you like to try the new beta addons to test this behavior? If so, you can enable it from the new beta dashboard at https://beta.readthedocs.org/ going to your project settings page.

If anything, this behavior could be a setting in the project. However, this would have some downsides since we will need to call the API endpoint with the url= attribute which will have a big impact on caching. See #10536

That said, I think we can't implement this feature in a reliable way that doesn't confuse our users. I think we can keep the new current behavior as the correct one for now.

I will close this issue for now, but feel free to re-open if you consider. cc @readthedocs/backend