On Mon, Jun 4, 2018, 12:37 PM Melvyn Sopacua <m.r.sopa...@gmail.com> wrote:
> On maandag 4 juni 2018 20:40:03 CEST Richard Brockie wrote: > > > On Mon, Jun 4, 2018 at 9:01 PM Melvyn Sopacua <m.r.sopa...@gmail.com> > wrote: > > > > This isn't a problem. Neither url nor reverse is capable of returning > URLs > > > > with hostnames, at least not that I'm aware of. Only > django.contrib.site > > > > < > https://docs.djangoproject.com/en/2.0/ref/contrib/sites/#getting-the-curr > > > > ent-domain-for-display> module can do this for out-of-band > communications. > > > > > > Aha - there's an error in how I posed the question. I was confusing the > url > > > and reverse() outputs with the links as interpreted by a browser. > > > > > > If http_host is ''subdomain.sponsor.url" we are at the site using the > > > sponsor's alias which maps to a unique "/year/slug/" on our site (just > one > > > of many). In this case, we require the output of {% url %} and reverse() > to > > > have 2 possibilities: > > > > > > 1. Normal operation (with our default http_host): returns the full path: > > > "/year/slug/some/more/path/" > > > 2. Sponsor http_host: returns a trimmed path: "/some/more/path". Here > > > "/year/slug" is suppressed as it is built into the > > > ''subdomain.sponsor.url" alias. > > > > > > I hope this clarifies what we think we need to do > > > > Aha! Now I get it! This should be solveable at the WSGI layer: > > > > PATH_INFO > > The remainder of the request URL's "path", designating the virtual > "location" of the request's target within the application. This may be an > empty string, if the request URL targets the application root and does not > have a trailing slash. > > > > See https://www.python.org/dev/peps/pep-0333/ > > > > A URL rewrite or proxy at the webserver level should work as well. It may > take a bit of experimenting. > Would URL rewrites solve this? How does that affect URL's generated in the template? It sounds like a separate 'site' with the sites framework is needed, along with a modified urls.py that does not include the year and slug in the path. Your might be able to use the existing urls.py by making the year and slug optional in the regex. When using the sponsored site, you would pass along extra context to the URL dispatcher that includes the year/slug or whatever data is being assumed by the usage of the sponsor URL. Basically, you need two different paths to the same resource, dependent on the domain name or site in question. Why not just leave the year and slug in and save yourself the extra work? Is the vanity path a requirement or just 'nice to have'? -James -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CA%2Be%2BciVucZjzfOxfRwwJijUc%2BxpNVgJWJO%3Dc%2Bg_Ygo-t3tXdcQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
