In using Marten Kenbeek's URL dispatch rewrite branch, I've found that
using the pattern of defining some site configuration in your settings is
the way to go: it more easily allows you to have URL patterns on multiple
domain/scheme combinations.
I use a dict similar to what Tim has shown, and the
On 01/25/2016 09:01 AM, Tim Graham wrote:
> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev
> settings), but if you are browsing a dif
Oh, looks like django-hosts also has this problem. It looks like in some
cases the URLs will be correct (due to the PARENT_HOST setting, I think,
which is 'djangoproject.dev:8000' in the djangoproject.com dev settings),
but if you are browsing a different host (e.g. the docs site), then those
U
> On 25 janv. 2016, at 14:19, Tim Graham wrote:
>
> I believe it's a common use case to import a copy of a production database
> and examine it locally -- that's what I meant about portability.
I’m not convinced by this argument because the data for the Site model will be
wrong anyway in this
I believe it's a common use case to import a copy of a production database
and examine it locally -- that's what I meant about portability.
I'm not aware of any Django usage that involves serving protocols other
than http(s). Is this a case you've come across?
On Monday, January 25, 2016 at 4:3
1. it's not necessarily about SSL, it can be for any protocol but SITE
dependent.
2. and for the dev/prod , your data will be different anyway so you put
the preferred protocol accordingly to your setup.
3. it's only for generating full URLs, not for internal links (ex:
si
Hi,
I think the same in the case of:
>
>1. It would make data less portable between development (where SSL is
>often not in use) and production.
>
> So maybe a settings option could work.
El miércoles, 13 de enero de 2016, 14:21:14 (UTC+1), Eric Rouleau escribió:
>
> Hi
>
> I've creat
since no feedback has been given yet, I will add that the change is just
an addition (new feature) meaning there is no breaking of code , it just
provides a way to define a default protocol for a given SITE, and will
ultimately default to http when none is specified
--
You received this mes
Hi
I've created a ticket to propose adding a preferred/default protocol in the
"sites" framework at https://code.djangoproject.com/ticket/26079
tim suggested I bring this to the mailing list and said the following:
I'm not immediately convinced that a database field is the way to go for a
> co
