Support single version subprojects URLs to serve from Django

[humitos]

Currently, Read the Docs Community does not have this problem because we serve directly from NGINX without passing through Django to get the X-Accel-Redirect header in its response.

Although, on Corporate we are returning an infinite redirect when accessing /projects/subproject/ URL when subproject is a Single Version project.

• We have a redirect_project_slug view that is called when hitting /projects/subproject/ to redirect to its default lang/version --this does not apply on single version subproject
• This redirect URL is only registered on urls/subdomain.py file (and not on urls/single_version.py), which should not be called when accessing a single version project is hit
• Our SingleVersionMiddleware (which overrides the request.urlconf) is not detecting that we are accessing to a single version project, because it uses the request.slug (which is the superproject) to check it. Related to Proxito: look for custom 404 pages in the parent project of subprojects #5557 (comment)

The current changes on this PR makes it work locally when USE_SUBDOMAIN=True, although it's not the best fix for this. To define this URL where it belongs to, we need to touch our SubdomainMiddleware to properly set subproject_slug and use that in different places instead --which could be a bigger refactor/improvement.

[humitos]

To define this URL where it belongs to, we need to touch our SubdomainMiddleware to properly set subproject_slug and use that in different places instead --which could be a bigger refactor/improvement.

In fact, this problem is more related to "Given an URL, parse it to get all the RTD objects from it" as we have talked. Currently, we are doing this at map_project_slug and map_subproject_slug (via Django URL named regex) and SubdomainMiddleware (via manipulating the host/domain and checking X-RTD-SLUG header).

Maybe it's time to work on this if we are considering the "big refactor".

[agjohnson]

It's not super clear to me where the design decision lays in this PR. Perhaps it would be more helpful to put this change into more context and summarize in more detail where you think the problems are with this implementation. It's also not clear why the middleware refactor is required, so I don't feel I have enough context to offer guidance.

[humitos]

It's not super clear to me where the design decision lays in this PR.

Basically, if

1. we want to deploy and go with the current solution for now (which is a hack) or,
2. we want to improve our middleware to detect that a subproject is being accessed and set the slug of it in the request object, so other places can trust on that. For example, the SingleVersionMiddleware that sets the proper urlconf to the request in that case.

Perhaps it would be more helpful to put this change into more context and summarize in more detail where you think the problems are with this implementation.

The problem is that it does not follow our pattern of using the specific urlconf depending on project specific values (like single_version), which is confusing in the end to have this exception here. Because of this, I need to add a shortcut on redirect_project_slug because this URL is defined only for non single-version urlconf.

It's also not clear why the middleware refactor is required, so I don't feel I have enough context to offer guidance.

When accessing a subproject (e.g. docs.cname.org/projects/subproject), our middleware sets request.slug to the project that has the Domain docs.cname.org and the rest of the code thinks we are accessing that project instead of subproject. The refactor is about adding more data like request.subproject_slug to give the ability to some part of the code that depends on the subproject, use that value instead.

Besides, improving the middleware by setting this extra value(s) is useful in another places like for custom 404 page in subprojects.

[ericholscher]

If this approach works, I'm +1 on shipping it and fixing a user's approach.

[ericholscher]

Hopefully this code will all disappear in the next couple months, so I'm OK with hacks :)

[humitos]

Since this is only needed for corporate, the only missing thing in this hacky PR is to import serve_docs from corporate before merging (readthedocsinc.core.views.serve_docs).

[humitos]

I finished the hack for this PR. It should not affect .org at all. We should check that this works when deploying .com.

[ericholscher]

Looks fine I guess -- I really dislike this pattern, but at least it's temporary.

[ericholscher]

We should log here.

[humitos]

Good idea! I added logs in both cases.