Adding temporary settings to the default project template sounds like a 
fair bit of cruft for a contrib app that isn't enabled by default. I don't 
use ping_google but I'm in favor of making the switch without a 
deprecation. Users of ping_google please comment, but switching to https 
doesn't seem like the sort of change that's going to cause massive pain.

On Wednesday, January 9, 2019 at 5:26:37 AM UTC-5, Markus Holtermann wrote:
>
> Hi all, 
>
> We could introduce a settings variable `SITEMAPS_PING_GOOGLE_HTTPS` that's 
> part of newly created projects' settings (in 
> https://github.com/django/django/blob/master/django/conf/project_template/project_name/settings.py-tpl)
>  
> and set to `True`. In global_settings.py it defaults to `False`. Users 
> could then turn it on for existing projects. Once the deprecation period is 
> over we would simply remove the variable and thus enforce HTTPS. We could 
> then also possibly issue a notice through the checks framework that the 
> variable is now obsolete. 
>
> Cheers, 
>
> Markus 
>
> On Wed, Jan 9, 2019, at 10:59 AM, Carlton Gibson wrote: 
> > Hi all. 
> > 
> > There's PR to fix long-standing issue with HTTP-only URLs being 
> > generated by the `ping_google` sitemaps command. 
> > 
> > https://code.djangoproject.com/ticket/23829 
> > https://github.com/django/django/pull/10651 
> > 
> > (The PR also allows specifying the domain, so you don't need 
> > contrib.sites installed.) 
> > 
> > The idea is to generate HTTPS URLs by default, having a flag to switch 
> > (back) to HTTP if that's what you really need. (`--use_http`) 
> > 
> > This though is a breaking change potentially: you'd need to add the new 
> > flag to your deployment scripts, or wherever, to keep existing HTTP 
> > URLs working. 
> > 
> > Because of this Adam suggested putting it through the deprecation 
> > process: keep the HTTP default and switch to HTTPS as the default 
> > later. 
> > 
> > However, I can't see how we can offer the new preferred usage (default 
> > to HTTPS without additional flags to the command) from day-one, 
> > allowing a shim to fallback to the existing behaviour: the best we seem 
> > to be able to do is emit a warning saying there'll be a breaking change 
> > in the future. If that's the case I'd rather just bite the bullet on 
> > it: clearly state that the new flag will be needed to keep using HTTP 
> > URLs in the v2.2 release notes and move on. 
> > 
> > Thoughts please. Thanks. 
> > 
> > Carlton. 
> > 
> > 
> >   
> > 
> > 
> >  -- 
> >  You received this message because you are subscribed to the Google 
> > Groups "Django developers (Contributions to Django itself)" group. 
> >  To unsubscribe from this group and stop receiving emails from it, send 
> > an email to django-develop...@googlegroups.com <javascript:>. 
> >  To post to this group, send email to 
> > django-d...@googlegroups.com <javascript:>. 
> >  Visit this group at https://groups.google.com/group/django-developers. 
> >  To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/django-developers/4188349d-a72a-4c2b-92d9-ee607c4c8b04%40googlegroups.com
>  
> <
> https://groups.google.com/d/msgid/django-developers/4188349d-a72a-4c2b-92d9-ee607c4c8b04%40googlegroups.com?utm_medium=email&utm_source=footer>.
>  
>
> >  For more options, visit https://groups.google.com/d/optout. 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/dcd66cbf-0e6a-4cc0-8937-9ca229f7dc43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to