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-current-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? > So if you're encountering such cases, then you're using custom or 3rd > party code or have a hardcoded hostname in your templates or are using the > site module. > > > > There is no magic case where reverse or the url template tag decides to > add a hostname, because it senses you want it. And if you just want to > serve the exact same site on a different domain, then ALLOWED_HOSTS is all > you need. > We're wanting to do something else - the sponsor's subdomain points to just one part of our site. We want to keep the charade of this part of our site being part of the sponsor subdomain so the urls that we present to browsers have to adjust correctly. You rightly deduce that we are going to brand this part of the site differently, but this will be global and will not depend on the http_host. Thanks! R. > > If you want to brand the site with a different look and feel, then you > will need the site module, because then you will serve different content. > > > > If you're asking "how can i be sure there are no mistakes in our code", > then you should already know the answer - test, test, test :). > > -- > > Melvyn Sopacua > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Django users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-users/jZt_bO2dR5c/unsubscribe. > To unsubscribe from this group and all its topics, 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/1789736.NRtqCP1Ze9%40fritzbook > <https://groups.google.com/d/msgid/django-users/1789736.NRtqCP1Ze9%40fritzbook?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- R. Richard Brockie Real-time bicycle race results - www.ontheday.net -- 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/CAKv-vOV3iMDgzrNkKM_J%3DYispGnVV26tYQkDZ9xegtp_icvNhQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.