Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Ira Abbott):

 * has_patch:  1 => 0


Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
> {{{ #!diff
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> ++ site_id = getattr(settings, 'SITE_ID', '')
> ++ mixed = getattr(settings, 'SITE_MIXED_MODE', '')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if site_id and not mixed:
> --  site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif site_id and mixed == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )
> }}}

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Tim Graham:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> ++ site_id = getattr(settings, 'SITE_ID', '')
> ++ mixed = getattr(settings, 'SITE_MIXED_MODE', '')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if site_id and not mixed:
> --  site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif site_id and mixed == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take precedence over SITE_ID.  This will 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Ira Abbott):

 I have tested the changed file with both with and without the new setting
 and verified that site by request happened with the setting, but that I
 got the base site without it. I also removed the app requiring site id,
 but left the one with request and verified that with no SITE_ID (simple
 switcheroo in the settings).

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.e44a41b9b46a59aa908d221abbca3390%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Ira Abbott):

 After more tweaking and plugging it in for test:

 def get_current(self, request=None):
 """
 Return the current Site based on the SITE_ID in the project's
 settings.
 If SITE_ID isn't defined, return the site with domain matching
 request.get_host(). The ``Site`` object is cached the first time
 it's
 retrieved from the database.
 """
 from django.conf import settings
 site_id = getattr(settings, 'SITE_ID', '')
 mixed_mode = getattr(settings, 'SITE_MIXED_MODE', '')
 if site_id and not mixed_mode:
 return self._get_site_by_id(site_id)
 elif request:
 return self._get_site_by_request(request)
 elif site_id and mixed_mode == True:
 return self._get_site_by_id(site_id)

 raise ImproperlyConfigured(
 "You're using the Django \"sites framework\" without having "
 "set the SITE_ID setting. Create a site in your database and "
 "set the SITE_ID setting or pass a request to "
 "Site.objects.get_current() to fix this error."
 )

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.c76203417604a0fe6fdc54a7036aea33%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> ++ has_mixed = getattr(settings, 'SITE_MIXED_MODE')
> ++ has_site = getattr(settings, 'SITE_ID', '')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if has_site and not has_mixed:
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif has_site and has_mixed and settings.SITE_MIXED_MODE ==
> True:
> ++ site_id = settings.SITE_ID
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> ++ mixed = getattr(settings, 'SITE_MIXED_MODE')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if getattr(settings, 'SITE_ID', '') and not mixed:
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif getattr(settings, 'SITE_ID', '') and mixed == True:
> ++ site_id = settings.SITE_ID
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--

Comment (by Ira Abbott):

 Sorry for the churn.  I proposed something I am hoping is more elegant and
 in line than my current version.  After I typed it, I saw that it needed a
 little splatter-proofing.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.3001d1458f973a82012c23e1bdea17e9%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> ++ mixed = getattr(settings, 'SITE_MIXED_MODE')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if getattr(settings, 'SITE_ID', '') and not mixed:
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif mixed == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take precedence over SITE_ID.  This will allow
 applications using both paradigms 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> +   mixed = getattr(settings, 'SITE_MIXED_MODE')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if getattr(settings, 'SITE_ID', '') and not mixed:
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif mixed == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take precedence over SITE_ID.  This will allow
 applications using both paradigms 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
>   mixed = getattr(settings, 'SITE_MIXED_MODE')
> --if getattr(settings, 'SITE_ID', ''):
> ++ if getattr(settings, 'SITE_ID', '') and not mixed:
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif mixed == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take precedence over SITE_ID.  This will allow
 applications using both 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> --if getattr(settings, 'SITE_ID', ''):
> ++ if getattr(settings, 'SITE_ID', '') and not getattr(settings,
> 'SITE_MIXED_MODE'):
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif getattr(settings, 'SITE_MIXED_MODE') and
> settings.SITE_MIXED_MODE == True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take precedence over SITE_ID.  This will 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Description changed by Ira Abbott:

Old description:

> We all learn very early in playing with django to set a site and a
> SITE_ID.  Once we operate as multiple sites, we either use the multiple
> processes, each configured with a separate SITE_ID or we can now pass a
> request in.  However,  I assume for backward compatibility, SITE_ID must
> be removed.  This allows all sites which specify SITE_ID to operate as if
> the addition of passing request was not added.  However, removing SITE_ID
> to allow get_site_by_request breaks all applications which do NOT pass
> request, because there is no SITE_ID.
>
> I propose a setting, which, when set to True in addition to setting
> SITE_ID, causes request to take precedence over SITE_ID.  This will allow
> applications using both paradigms to coexist without modification - sites
> which pass request use get_site_by_request as if SITE_ID had not been
> defined and calls passing no request get SITE_ID.  When the new setting
> is not present, all behavior is backward compatible.
>
> Essentially, I am proposing something like the 'change set' I typed in
> below - I considered that a complex and/or in the fist if could cover all
> of the conditions, but I think qualifying the first line with the new
> setting and adding the elif to cover the cleanup case of not set to True
> is easier to understand - especially in light of understanding the the
> backward compatibility aspect of the change.  The version of this change
> I am currently running simply defines a new SITE_DEFAULT_ID to catch the
> third case, but it occurred to me that some modules may expect SITE_ID
> directly for some reason, and MIXED_MODE has them covered too.
>
> I expect the documentation change to accompany the new setting would go
> with the Sites documentation next to SITE_ID an explanation of removing
> SITE_ID to use request.
>
> This would be my first contribution, so I am unsure that it would
> welcome.  If this ticket is accepted, I will quite gladly prepare a pull
> request with an agreed upon setting name (in case mine doesn't grab ya)
> or other any other suggested style improvements etc.
>
> Thank you for taking the time to review my request.
>
> All the best, and thank you for your work with django.
>
> Manually edited 'change set' describing the proposed change (three lines)
> follow:
>
> django/contrib/sites/models.py
>
> def get_current(self, request=None):
> """
> Return the current Site based on the SITE_ID in the project's
> settings.
> If SITE_ID isn't defined, return the site with domain matching
> request.get_host(). The ``Site`` object is cached the first time
> it's
> retrieved from the database.
> """
> from django.conf import settings
> --if getattr(settings, 'SITE_ID', ''):
> ++ if getattr(settings, 'SITE_ID', '') and not getattr(settings,
> 'SITE_MIXED_MODE'):
> site_id = settings.SITE_ID
> return self._get_site_by_id(site_id)
> elif request:
>  return self._get_site_by_request(request)
> ++   elif getattr(settings, 'SITE_MIXED_MODE') and
> settings.SITE_MIXED_MODE = True:
> ++ return self._get_site_by_id(site_id)
>
> raise ImproperlyConfigured(
> "You're using the Django \"sites framework\" without having "
> "set the SITE_ID setting. Create a site in your database and
> "
> "set the SITE_ID setting or pass a request to "
> "Site.objects.get_current() to fix this error."
> )

New description:

 We all learn very early in playing with django to set a site and a
 SITE_ID.  Once we operate as multiple sites, we either use the multiple
 processes, each configured with a separate SITE_ID or we can now pass a
 request in.  However,  I assume for backward compatibility, SITE_ID must
 be removed.  This allows all sites which specify SITE_ID to operate as if
 the addition of passing request was not added.  However, removing SITE_ID
 to allow get_site_by_request breaks all applications which do NOT pass
 request, because there is no SITE_ID.

 I propose a setting, which, when set to True in addition to setting
 SITE_ID, causes request to take precedence over SITE_ID.  This will 

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Ira Abbott):

 * cc: Ira Abbott (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.8ca19d972b1d14c906c75961ddbd28ec%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Django] #30021: Feature request to allow "mixed mode" Sites operation.

[Django]

#30021: Feature request to allow "mixed mode" Sites operation.
---+--
 Reporter:  Ira Abbott |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  contrib.sites  |  Version:  2.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  1  |  Needs documentation:  1
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  1  |UI/UX:  0
---+--
Changes (by Ira Abbott):

 * needs_docs:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To post to this group, send email to django-updates@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.f0d9602c1b1bd7c440fe9b761e635811%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.