Django set "debug" mode depending on URL - django

Does anyone know a good way to handle the debug mode dynamically in Django - settings.py ? ..
I want the debug mode to be true if the requested is eg. test.mydomain.com
and when i go to mydomain.com the debug mode is false.
Is there a way to get the requested URL in the settings.py file to make a IF condition?

django's settings should stay immutable. it is supposed to be so.
you better create two settings,
settings.py, (which is already there)
debug_settings.py with DEBUG=True
and create two wsgi's in your django.
wsgi.py (which is already there) which refers to settings.py
wsgi_debug.py which refers to debug_settings.py
and in your apache config, depending on servername, make it refer to respective wsgi.

Related

Is there any way to automatically set Debug True Django application

I have a Django API that is being deployed in PythonAnywhere.
For that, I can not let the default option in settings.py as True:
DEBUG=True
However, the app also has a Swagger page using drf-yasg library. For that to work locally, I have to set the debug option as true.
However is being troublesome to maintain it, and I often mistakenly commit it as True to the repository.
Is there anyway I could manage this option so whenever I am running locally, it will automatically set it to True, but leave it as False by default?
DEBUG=False
For this purpose I use python-decouple package. To distinguish between production and development environments you can create one .env file with all production-related variables in it. In settings.py when retrieving the configuration parameters leave every default option with the one used in development. So when .env file is not present the default values are gonna be set.
from decouple import config
DEBUG = config('YOUR_ENV_VAR_DEBUG', default=True, cast=bool)
For more real-world use cases, please refer to the documentation.

pinax-project-account default password reset page with support#example.com

I installed the pinax-project-account as through the link below.
https://github.com/pinax/pinax-project-account
Also I did go and change the site to <mysite.com> instead of <example.com>
However, the password reset page still shows the below
If you have any trouble resetting your password, contact us at
support#example.com.
Is there anything that needs to be done to refresh? I run the web on gunicorn and nginx , and I already restarted the daemon and nginx.
Thanks
I believe it's a default value within pinax's own source code. Try checking env/lib/python2.7/site-packages/pinax_theme_bootstrap/conf.py (adjust to your environment as needed) and changing the CONTACT_EMAIL variable.
Alternatively, it may help in similar situations to add a new record to your underlying database table django_site with is what links the SITE_ID value in settings.py to its corresponding domain & name values. SITE_ID of 1 has default values "example.com" for both domain & name.
Additionally, though only somewhat related, make sure to change your DEFAULT_FROM_EMAIL setting in your application's settings.py.

should changes of translations in django rosetta propagate automatically to frontend?

When I make or alter translations in Rosetta in Django backend, the po and mo files get updated. However, I don't see them directly show up in the frontend.
The doc of Rosetta says:
NEW: if your webserver supports it, you can force auto-reloading of
the translated catalog whenever a change was saved. See the note
regarding the ROSETTA_WSGI_AUTO_RELOAD variable
So which conditions should the webserver fulfill for this to work?
as far as i have understood you have to set up your server with wsgi (e.g. Apache mod_wsgi) to use this feature.
ROSETTA_WSGI_AUTO_RELOAD and ROSETTA_UWSGI_AUTO_RELOAD: When running WSGI daemon mode, using mod_wsgi 2.0c5 or later, this setting controls whether the contents of the gettext catalog files should be automatically reloaded by the WSGI processes each time they are modified. For performance reasons, this setting should be disabled in production environments. Default to False.
You just need to add ROSETTA_WSGI_AUTO_RELOAD = True and ROSETTA_UWSGI_AUTO_RELOAD = True in your settings.py file.
If you have multiple settings.py file then have add these lines for all your settings file.
Example:
ROSETTA_WSGI_AUTO_RELOAD = True
ROSETTA_UWSGI_AUTO_RELOAD = True

Django under IIS (with HeliconZoo) in virtual directory - urls resolver works with path without directory name

I've a Django website running under IIS with a help of Helicon Zoo. It is located in virtual directory (so, url to it looks like http://mysite.com/django).
In my urls.py, I have patterns defined like this:
urlpatterns = patterns('',
....
url(r'^django/status/(?P<product>.*)/$',views.status),
....
)
But, when I open url like http://mysite.com/django/status/some_product
I'm getting 404 page with message:
Using the URLconf defined in urls, Django tried these URL patterns, in this order:
....
The current URL, status/some_product/, didn't match any of these.
As you can see, there is no django in URL which is tested. And of course, when I change pattern like this:
url(r'^status/(?P<product>.*)/$',views.status),
Everything works fine, but if APPEND_SLASH is enabled (and I have it enabled and setting it to False in settings.py does not help for some reason), my requests like http://mysite.com/django/status/some_product are redirected to http://mysite.com/status/some_product/.
So, the question is:
How can I configure Django so it will not throw out virtual directory name?
Is there anything I need to know about how to turn of APPEND_SLASH?
Right now I simply put APPEND_SLASH = False in settings.py, but no difference.
Note: I know almost nothing about Django and Python and I can't change how that website is set up (at least now).
I noticed that the zoofcgi has two operating modes
with django_settings_module
or with wsgi_app
As my project needs the second (wsgi_app), I noticed that the problem was not solved only by setting the variable django.root.
That is, there is a bug in the configuration of environmental variables for the second mode. So I created the project helicon-zoofcgi that solves this bug.
Now there is no need to be entering the site prefix in django urls, the zoofcgi module already solves it in the environment variables.
I hope that the project can be useful for someone in the future.
Finally, I've found what's wrong with it.
Appeared that the reason for described behavior is a setting provided with default web.config file:
<add name="django.root" value="%APPL_VIRTUAL_PATH%" />
After I removed it everything started working fine.
Here is some info related to django.root variable applied to Apache.

django url scheme in apache and dev server

I have a a django application which is being served from apache/mod_wsgi under www.mysite.com/mysite
suppose I redirect url "myapp" -> myapp/urls.py
so to visit it from apache I will visit www.mysite.com/mysite/myapp/page1
to visit it from dev server I will need to visit www.mysite.com/myapp/page1
it also means absolute URLs wil be different in both cases
so what is the best way to handle this , so that app works same way in apache and dev server?
Don't embed absolute and/or non-computed URLs in your code or database. They will always come back and bite you on the ass.
Use either an alternate settings.py, or have some logic in settings.py to tweak differences between development/staging/production. We use settings.py as the production file and dev/staging use a local_settings.py which is tested for in settings.py and, if present, overrides production settings in settings.py. This prevents alternate development settings from creeping into staging/production.
Set a BASE_URL for the entire site and use it for everything else.
We go a bit further and have STATIC_MEDIA_URL and BIG_CONTENT_URL (for MP3s and Flash video) as the base URLs for other stuff.
All of this allows us to use whatever server is right for the moment. When I'm doing development I normally let the MEDIA come from the production servers (it's faster), but sometimes I'm doing a reorg of the media directories and I can't do it on production without breaking the world. So I just change my local_settings.py file to use my copy of the directories.