Simplified default project template.
Squashed commit of: commit 508ec9144b35c50794708225b496bde1eb5e60aa Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 22:50:55 2013 +0100 Tweaked default settings file. * Explained why BASE_DIR exists. * Added a link to the database configuration options, and put it in its own section. * Moved sensitive settings that must be changed for production at the top. commit 6515fd2f1aa73a86dc8dbd2ccf512ddb6b140d57 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 14:35:21 2013 +0100 Documented the simplified app & project templates in the changelog. commit 2c5b576c2ea91d84273a019b3d0b3b8b4da72f23 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 13:59:27 2013 +0100 Minor fixes in tutorials 5 and 6. commit 55a51531be8104f21b3cca3f6bf70b0a7139a041 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 13:51:11 2013 +0100 Updated tutorial 2 for the new project template. commit 29ddae87bdaecff12dd31b16b000c01efbde9e20 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 11:58:54 2013 +0100 Updated tutorial 1 for the new project template. commit 0ecb9f6e2514cfd26a678a280d471433375101a3 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 11:29:13 2013 +0100 Adjusted the default URLconf detection to account for the admin. It's now enabled by default. commit 5fb4da0d3d09dac28dd94e3fde92b9d4335c0565 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 10:36:55 2013 +0100 Added security warnings for the most sensitive settings. commit 718d84bd8ac4a42fb4b28ec93965de32680f091e Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 23:24:06 2013 +0100 Used an absolute path for the SQLite database. This ensures the settings file works regardless of which directory django-admin.py / manage.py is invoked from. BASE_DIR got a +1 from a BDFL and another core dev. It doesn't involve the concept of a "Django project"; it's just a convenient way to express relative paths within the source code repository for non-Python files. Thanks Jacob Kaplan-Moss for the suggestion. commit 1b559b4bcda622e10909b68fe5cab90db6727dd9 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 23:22:40 2013 +0100 Removed STATIC_ROOT from the default settings template. It isn't necessary in development, and it confuses beginners to no end. Thanks Carl Meyer for the suggestion. commit a55f141a500bb7c9a1bc259bbe1954c13b199671 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 23:21:43 2013 +0100 Removed MEDIA_ROOT/URL from default settings template. Many sites will never deal with user-uploaded files, and MEDIA_ROOT is complicated to explain. Thanks Carl Meyer for the suggestion. commit 44bf2f2441420fd9429ee9fe1f7207f92dd87e70 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 22:22:09 2013 +0100 Removed logging config. This configuration is applied regardless of the value of LOGGING; duplicating it in LOGGING is confusing. commit eac747e848eaed65fd5f6f254f0a7559d856f88f Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 22:05:31 2013 +0100 Enabled the locale middleware by default. USE_I18N is True by default, and doesn't work well without LocaleMiddleware. commit d806c62b2d00826dc2688c84b092627b8d571cab Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 22:03:16 2013 +0100 Enabled clickjacking protection by default. commit 99152c30e6a15003f0b6737dc78e87adf462aacb Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 22:01:48 2013 +0100 Reorganized settings in logical sections, and trimmed comments. commit d37ffdfcb24b7e0ec7cc113d07190f65fb12fb8a Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:54:11 2013 +0100 Avoided misleading TEMPLATE_DEBUG = DEBUG. According to the docs TEMPLATE_DEBUG works only when DEBUG = True. commit 15d9478d3a9850e85841e7cf09cf83050371c6bf Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:46:25 2013 +0100 Removed STATICFILES_FINDERS/TEMPLATE_LOADERS from default settings file. Only developers with special needs ever need to change these settings. commit 574da0eb5bfb4570883756914b4dbd7e20e1f61e Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:45:01 2013 +0100 Removed STATICFILES/TEMPLATES_DIRS from default settings file. The current best practice is to put static files and templates in applications, for easier testing and deployment. commit 8cb18dbe56629aa1be74718a07e7cc66b4f9c9f0 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:24:16 2013 +0100 Removed settings related to email reporting from default settings file. While handy for small scale projects, it isn't exactly a best practice. commit 8ecbfcb3638058f0c49922540f874a7d802d864f Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 18:54:43 2013 +0100 Documented how to enable the sites framework. commit 23fc91a6fa67d91ddd9d71b1c3e0dc26bdad9841 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:28:59 2013 +0100 Disabled the sites framework by default. RequestSite does the job for single-domain websites. commit c4d82eb8afc0eb8568bf9c4d12644272415e3960 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Tue Jan 29 00:08:33 2013 +0100 Added a default admin.py to the application template. Thanks Ryan D Hiebert for the suggestion. commit 4071dc771e5c44b1c5ebb9beecefb164ae465e22 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 10:59:49 2013 +0100 Enabled the admin by default. Everyone uses the admin. commit c807a31f8d89e7e7fd97380e3023f7983a8b6fcb Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 10:57:05 2013 +0100 Removed admindocs from default project template. commit 09e4ce0e652a97da1a9e285046a91c8ad7a9189c Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:32:52 2013 +0100 Added links to the settings documentation. commit 5b8f5eaef364eb790fcde6f9e86f7d266074cca8 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 11:06:54 2013 +0100 Used a significant example for URLconf includes. commit 908e91d6fcee2a3cb51ca26ecdf12a6a24e69ef8 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 16:22:31 2013 +0100 Moved code comments about WSGI to docs, and rewrote said docs. commit 50417e51996146f891d08ca8b74dcc736a581932 Author: Aymeric Augustin <aymeric.augustin@m4x.org> Date: Mon Jan 28 15:51:50 2013 +0100 Normalized the default application template. Removed the default test that 1 + 1 = 2, because it's been committed way too many times, in too many projects. Added an import of `render` for views, because the first view will often be: def home(request): return render(request, "mysite/home.html")
							
								
								
									
										3
									
								
								django/conf/app_template/admin.py
									
									
									
									
									
										Normal file
									
								
							
							
						
						| @@ -0,0 +1,3 @@ | ||||
| from django.contrib import admin | ||||
|  | ||||
| # Register your models here. | ||||
| @@ -1,16 +1,3 @@ | ||||
| """ | ||||
| This file demonstrates writing tests using the unittest module. These will pass | ||||
| when you run "manage.py test". | ||||
|  | ||||
| Replace this with more appropriate tests for your application. | ||||
| """ | ||||
|  | ||||
| from django.test import TestCase | ||||
|  | ||||
|  | ||||
| class SimpleTest(TestCase): | ||||
|     def test_basic_addition(self): | ||||
|         """ | ||||
|         Tests that 1 + 1 always equals 2. | ||||
|         """ | ||||
|         self.assertEqual(1 + 1, 2) | ||||
| # Create your tests here. | ||||
|   | ||||
| @@ -1 +1,3 @@ | ||||
| from django.shortcuts import render | ||||
|  | ||||
| # Create your views here. | ||||
|   | ||||
| @@ -1,152 +1,82 @@ | ||||
| # Django settings for {{ project_name }} project. | ||||
| """ | ||||
| Django settings for {{ project_name }} project. | ||||
|  | ||||
| DEBUG = True | ||||
| TEMPLATE_DEBUG = DEBUG | ||||
| For more information on this file, see | ||||
| https://docs.djangoproject.com/en/{{ docs_version }}/topics/settings/ | ||||
|  | ||||
| ADMINS = ( | ||||
|     # ('Your Name', 'your_email@example.com'), | ||||
| ) | ||||
| For the full list of settings and their values, see | ||||
| https://docs.djangoproject.com/en/{{ docs_version }}/ref/settings/ | ||||
| """ | ||||
|  | ||||
| MANAGERS = ADMINS | ||||
| # Build paths inside the project like this: os.path.join(BASE_DIR, ...) | ||||
| import os | ||||
| BASE_DIR = os.path.dirname(os.path.dirname(__file__)) | ||||
|  | ||||
| DATABASES = { | ||||
|     'default': { | ||||
|         'ENGINE': 'django.db.backends.', # Add 'postgresql_psycopg2', 'mysql', 'sqlite3' or 'oracle'. | ||||
|         'NAME': '',                      # Or path to database file if using sqlite3. | ||||
|         # The following settings are not used with sqlite3: | ||||
|         'USER': '', | ||||
|         'PASSWORD': '', | ||||
|         'HOST': '',                      # Empty for localhost through domain sockets or '127.0.0.1' for localhost through TCP. | ||||
|         'PORT': '',                      # Set to empty string for default. | ||||
|     } | ||||
| } | ||||
|  | ||||
| # Local time zone for this installation. Choices can be found here: | ||||
| # http://en.wikipedia.org/wiki/List_of_tz_zones_by_name | ||||
| # although not all choices may be available on all operating systems. | ||||
| # In a Windows environment this must be set to your system time zone. | ||||
| TIME_ZONE = 'America/Chicago' | ||||
| # Quick-start development settings - unsuitable for production | ||||
|  | ||||
| # Language code for this installation. All choices can be found here: | ||||
| # http://www.i18nguy.com/unicode/language-identifiers.html | ||||
| LANGUAGE_CODE = 'en-us' | ||||
|  | ||||
| SITE_ID = 1 | ||||
|  | ||||
| # If you set this to False, Django will make some optimizations so as not | ||||
| # to load the internationalization machinery. | ||||
| USE_I18N = True | ||||
|  | ||||
| # If you set this to False, Django will not format dates, numbers and | ||||
| # calendars according to the current locale. | ||||
| USE_L10N = True | ||||
|  | ||||
| # If you set this to False, Django will not use timezone-aware datetimes. | ||||
| USE_TZ = True | ||||
|  | ||||
| # Absolute filesystem path to the directory that will hold user-uploaded files. | ||||
| # Example: "/var/www/example.com/media/" | ||||
| MEDIA_ROOT = '' | ||||
|  | ||||
| # URL that handles the media served from MEDIA_ROOT. Make sure to use a | ||||
| # trailing slash. | ||||
| # Examples: "http://example.com/media/", "http://media.example.com/" | ||||
| MEDIA_URL = '' | ||||
|  | ||||
| # Absolute path to the directory static files should be collected to. | ||||
| # Don't put anything in this directory yourself; store your static files | ||||
| # in apps' "static/" subdirectories and in STATICFILES_DIRS. | ||||
| # Example: "/var/www/example.com/static/" | ||||
| STATIC_ROOT = '' | ||||
|  | ||||
| # URL prefix for static files. | ||||
| # Example: "http://example.com/static/", "http://static.example.com/" | ||||
| STATIC_URL = '/static/' | ||||
|  | ||||
| # Additional locations of static files | ||||
| STATICFILES_DIRS = ( | ||||
|     # Put strings here, like "/home/html/static" or "C:/www/django/static". | ||||
|     # Always use forward slashes, even on Windows. | ||||
|     # Don't forget to use absolute paths, not relative paths. | ||||
| ) | ||||
|  | ||||
| # List of finder classes that know how to find static files in | ||||
| # various locations. | ||||
| STATICFILES_FINDERS = ( | ||||
|     'django.contrib.staticfiles.finders.FileSystemFinder', | ||||
|     'django.contrib.staticfiles.finders.AppDirectoriesFinder', | ||||
|     # 'django.contrib.staticfiles.finders.DefaultStorageFinder', | ||||
| ) | ||||
|  | ||||
| # Make this unique, and don't share it with anybody. | ||||
| # SECURITY WARNING: keep the secret key used in production secret! | ||||
| # Hardcoded values can leak through source control. Consider loading | ||||
| # the secret key from an environment variable or a file instead. | ||||
| SECRET_KEY = '{{ secret_key }}' | ||||
|  | ||||
| # List of callables that know how to import templates from various sources. | ||||
| TEMPLATE_LOADERS = ( | ||||
|     'django.template.loaders.filesystem.Loader', | ||||
|     'django.template.loaders.app_directories.Loader', | ||||
|     # 'django.template.loaders.eggs.Loader', | ||||
| # SECURITY WARNING: don't run with debug turned on in production! | ||||
| DEBUG = True | ||||
|  | ||||
| TEMPLATE_DEBUG = True | ||||
|  | ||||
|  | ||||
| # Application definition | ||||
|  | ||||
| INSTALLED_APPS = ( | ||||
|     'django.contrib.admin', | ||||
|     'django.contrib.auth', | ||||
|     'django.contrib.contenttypes', | ||||
|     'django.contrib.sessions', | ||||
|     'django.contrib.messages', | ||||
|     'django.contrib.staticfiles', | ||||
| ) | ||||
|  | ||||
| MIDDLEWARE_CLASSES = ( | ||||
|     'django.middleware.common.CommonMiddleware', | ||||
|     'django.contrib.sessions.middleware.SessionMiddleware', | ||||
|     'django.middleware.locale.LocaleMiddleware', | ||||
|     'django.middleware.common.CommonMiddleware', | ||||
|     'django.middleware.csrf.CsrfViewMiddleware', | ||||
|     'django.contrib.auth.middleware.AuthenticationMiddleware', | ||||
|     'django.contrib.messages.middleware.MessageMiddleware', | ||||
|     # Uncomment the next line for simple clickjacking protection: | ||||
|     # 'django.middleware.clickjacking.XFrameOptionsMiddleware', | ||||
|     'django.middleware.clickjacking.XFrameOptionsMiddleware', | ||||
| ) | ||||
|  | ||||
| ROOT_URLCONF = '{{ project_name }}.urls' | ||||
|  | ||||
| # Python dotted path to the WSGI application used by Django's runserver. | ||||
| WSGI_APPLICATION = '{{ project_name }}.wsgi.application' | ||||
|  | ||||
| TEMPLATE_DIRS = ( | ||||
|     # Put strings here, like "/home/html/django_templates" or "C:/www/django/templates". | ||||
|     # Always use forward slashes, even on Windows. | ||||
|     # Don't forget to use absolute paths, not relative paths. | ||||
| ) | ||||
|  | ||||
| INSTALLED_APPS = ( | ||||
|     'django.contrib.auth', | ||||
|     'django.contrib.contenttypes', | ||||
|     'django.contrib.sessions', | ||||
|     'django.contrib.sites', | ||||
|     'django.contrib.messages', | ||||
|     'django.contrib.staticfiles', | ||||
|     # Uncomment the next line to enable the admin: | ||||
|     # 'django.contrib.admin', | ||||
|     # Uncomment the next line to enable admin documentation: | ||||
|     # 'django.contrib.admindocs', | ||||
| ) | ||||
| # Database | ||||
| # https://docs.djangoproject.com/en/{{ docs_version }}/ref/settings/#databases | ||||
|  | ||||
| # A sample logging configuration. The only tangible logging | ||||
| # performed by this configuration is to send an email to | ||||
| # the site admins on every HTTP 500 error when DEBUG=False. | ||||
| # See http://docs.djangoproject.com/en/dev/topics/logging for | ||||
| # more details on how to customize your logging configuration. | ||||
| LOGGING = { | ||||
|     'version': 1, | ||||
|     'disable_existing_loggers': False, | ||||
|     'filters': { | ||||
|         'require_debug_false': { | ||||
|             '()': 'django.utils.log.RequireDebugFalse' | ||||
|         } | ||||
|     }, | ||||
|     'handlers': { | ||||
|         'mail_admins': { | ||||
|             'level': 'ERROR', | ||||
|             'filters': ['require_debug_false'], | ||||
|             'class': 'django.utils.log.AdminEmailHandler' | ||||
|         } | ||||
|     }, | ||||
|     'loggers': { | ||||
|         'django.request': { | ||||
|             'handlers': ['mail_admins'], | ||||
|             'level': 'ERROR', | ||||
|             'propagate': True, | ||||
|         }, | ||||
| DATABASES = { | ||||
|     'default': { | ||||
|         'ENGINE': 'django.db.backends.sqlite3', | ||||
|         'NAME': os.path.join(BASE_DIR, 'db.sqlite3'), | ||||
|     } | ||||
| } | ||||
|  | ||||
| # Internationalization | ||||
| # https://docs.djangoproject.com/en/{{ docs_version }}/topics/i18n/ | ||||
|  | ||||
| LANGUAGE_CODE = 'en-us' | ||||
|  | ||||
| TIME_ZONE = 'UTC' | ||||
|  | ||||
| USE_I18N = True | ||||
|  | ||||
| USE_L10N = True | ||||
|  | ||||
| USE_TZ = True | ||||
|  | ||||
|  | ||||
| # Static files (CSS, JavaScript, Images) | ||||
| # https://docs.djangoproject.com/en/{{ docs_version }}/howto/static-files/ | ||||
|  | ||||
| STATIC_URL = '/static/' | ||||
|   | ||||
| @@ -1,17 +1,12 @@ | ||||
| from django.conf.urls import patterns, include, url | ||||
|  | ||||
| # Uncomment the next two lines to enable the admin: | ||||
| # from django.contrib import admin | ||||
| # admin.autodiscover() | ||||
| from django.contrib import admin | ||||
| admin.autodiscover() | ||||
|  | ||||
| urlpatterns = patterns('', | ||||
|     # Examples: | ||||
|     # url(r'^$', '{{ project_name }}.views.home', name='home'), | ||||
|     # url(r'^{{ project_name }}/', include('{{ project_name }}.foo.urls')), | ||||
|     # url(r'^blog/', include('blog.urls')), | ||||
|  | ||||
|     # Uncomment the admin/doc line below to enable admin documentation: | ||||
|     # url(r'^admin/doc/', include('django.contrib.admindocs.urls')), | ||||
|  | ||||
|     # Uncomment the next line to enable the admin: | ||||
|     # url(r'^admin/', include(admin.site.urls)), | ||||
|     url(r'^admin/', include(admin.site.urls)), | ||||
| ) | ||||
|   | ||||
| @@ -1,32 +1,14 @@ | ||||
| """ | ||||
| WSGI config for {{ project_name }} project. | ||||
|  | ||||
| This module contains the WSGI application used by Django's development server | ||||
| and any production WSGI deployments. It should expose a module-level variable | ||||
| named ``application``. Django's ``runserver`` and ``runfcgi`` commands discover | ||||
| this application via the ``WSGI_APPLICATION`` setting. | ||||
|  | ||||
| Usually you will have the standard Django WSGI application here, but it also | ||||
| might make sense to replace the whole Django WSGI application with a custom one | ||||
| that later delegates to the Django one. For example, you could introduce WSGI | ||||
| middleware here, or combine a Django application with an application of another | ||||
| framework. | ||||
| It exposes the WSGI callable as a module-level variable named ``application``. | ||||
|  | ||||
| For more information on this file, see | ||||
| https://docs.djangoproject.com/en/{{ docs_version }}/howto/deployment/wsgi/ | ||||
| """ | ||||
| import os | ||||
|  | ||||
| # We defer to a DJANGO_SETTINGS_MODULE already in the environment. This breaks | ||||
| # if running multiple sites in the same mod_wsgi process. To fix this, use | ||||
| # mod_wsgi daemon mode with each site in its own daemon process, or use | ||||
| # os.environ["DJANGO_SETTINGS_MODULE"] = "{{ project_name }}.settings" | ||||
| import os | ||||
| os.environ.setdefault("DJANGO_SETTINGS_MODULE", "{{ project_name }}.settings") | ||||
|  | ||||
| # This application object is used by any WSGI server configured to use this | ||||
| # file. This includes Django's development server, if the WSGI_APPLICATION | ||||
| # setting points here. | ||||
| from django.core.wsgi import get_wsgi_application | ||||
| application = get_wsgi_application() | ||||
|  | ||||
| # Apply WSGI middleware here. | ||||
| # from helloworld.wsgi import HelloWorldApplication | ||||
| # application = HelloWorldApplication(application) | ||||
|   | ||||
| @@ -105,10 +105,15 @@ class TemplateCommand(BaseCommand): | ||||
|         base_name = '%s_name' % app_or_project | ||||
|         base_subdir = '%s_template' % app_or_project | ||||
|         base_directory = '%s_directory' % app_or_project | ||||
|         if django.VERSION[-1] == 0: | ||||
|             docs_version = 'dev' | ||||
|         else: | ||||
|             docs_version = '%d.%d' % django.VERSION[:2] | ||||
|  | ||||
|         context = Context(dict(options, **{ | ||||
|             base_name: name, | ||||
|             base_directory: top_dir, | ||||
|             'docs_version': docs_version, | ||||
|         }), autoescape=False) | ||||
|  | ||||
|         # Setup a stub settings environment for template rendering | ||||
|   | ||||
| @@ -438,9 +438,12 @@ def technical_404_response(request, exception): | ||||
|     except (IndexError, TypeError, KeyError): | ||||
|         tried = [] | ||||
|     else: | ||||
|         if not tried: | ||||
|             # tried exists but is an empty list. The URLconf must've been empty. | ||||
|             return empty_urlconf(request) | ||||
|         if (not tried                           # empty URLconf | ||||
|             or (request.path == '/' | ||||
|                 and len(tried) == 1             # default URLconf | ||||
|                 and len(tried[0]) == 1 | ||||
|                 and tried[0][0].app_name == tried[0][0].namespace == 'admin')): | ||||
|             return default_urlconf(request) | ||||
|  | ||||
|     urlconf = getattr(request, 'urlconf', settings.ROOT_URLCONF) | ||||
|     if isinstance(urlconf, types.ModuleType): | ||||
| @@ -458,12 +461,10 @@ def technical_404_response(request, exception): | ||||
|     }) | ||||
|     return HttpResponseNotFound(t.render(c), content_type='text/html') | ||||
|  | ||||
| def empty_urlconf(request): | ||||
| def default_urlconf(request): | ||||
|     "Create an empty URLconf 404 error response." | ||||
|     t = Template(EMPTY_URLCONF_TEMPLATE, name='Empty URLConf template') | ||||
|     c = Context({ | ||||
|         'project_name': settings.SETTINGS_MODULE.split('.')[0] | ||||
|     }) | ||||
|     t = Template(DEFAULT_URLCONF_TEMPLATE, name='Default URLconf template') | ||||
|     c = Context({}) | ||||
|     return HttpResponse(t.render(c), content_type='text/html') | ||||
|  | ||||
| # | ||||
| @@ -1067,7 +1068,7 @@ TECHNICAL_404_TEMPLATE = """ | ||||
| </html> | ||||
| """ | ||||
|  | ||||
| EMPTY_URLCONF_TEMPLATE = """ | ||||
| DEFAULT_URLCONF_TEMPLATE = """ | ||||
| <!DOCTYPE html> | ||||
| <html lang="en"><head> | ||||
|   <meta http-equiv="content-type" content="text/html; charset=utf-8"> | ||||
| @@ -1087,7 +1088,6 @@ EMPTY_URLCONF_TEMPLATE = """ | ||||
|     tbody td, tbody th { vertical-align:top; padding:2px 3px; } | ||||
|     thead th { padding:1px 6px 1px 3px; background:#fefefe; text-align:left; font-weight:normal; font-size:11px; border:1px solid #ddd; } | ||||
|     tbody th { width:12em; text-align:right; color:#666; padding-right:.5em; } | ||||
|     ul { margin-left: 2em; margin-top: 1em; } | ||||
|     #summary { background: #e0ebff; } | ||||
|     #summary h2 { font-weight: normal; color: #666; } | ||||
|     #explanation { background:#eee; } | ||||
| @@ -1103,11 +1103,10 @@ EMPTY_URLCONF_TEMPLATE = """ | ||||
| </div> | ||||
|  | ||||
| <div id="instructions"> | ||||
|   <p>Of course, you haven't actually done any work yet. Here's what to do next:</p> | ||||
|   <ul> | ||||
|     <li>If you plan to use a database, edit the <code>DATABASES</code> setting in <code>{{ project_name }}/settings.py</code>.</li> | ||||
|     <li>Start your first app by running <code>python manage.py startapp [appname]</code>.</li> | ||||
|   </ul> | ||||
|   <p> | ||||
|     Of course, you haven't actually done any work yet. | ||||
|     Next, start your first app by running <code>python manage.py startapp [appname]</code>. | ||||
|   </p> | ||||
| </div> | ||||
|  | ||||
| <div id="explanation"> | ||||
|   | ||||
| @@ -8,9 +8,10 @@ servers and applications. | ||||
| .. _WSGI: http://www.wsgi.org | ||||
|  | ||||
| Django's :djadmin:`startproject` management command sets up a simple default | ||||
| WSGI configuration for you, which you can tweak as needed for your project, and | ||||
| direct any WSGI-compliant webserver to use. Django includes getting-started | ||||
| documentation for the following WSGI servers: | ||||
| WSGI configuration for you, which you can tweak as needed for your project, | ||||
| and direct any WSGI-compliant application server to use. | ||||
|  | ||||
| Django includes getting-started documentation for the following WSGI servers: | ||||
|  | ||||
| .. toctree:: | ||||
|    :maxdepth: 1 | ||||
| @@ -23,32 +24,76 @@ documentation for the following WSGI servers: | ||||
| The ``application`` object | ||||
| -------------------------- | ||||
|  | ||||
| One key concept of deploying with WSGI is to specify a central ``application`` | ||||
| callable object which the webserver uses to communicate with your code. This is | ||||
| commonly specified as an object named ``application`` in a Python module | ||||
| accessible to the server. | ||||
| The key concept of deploying with WSGI is the ``application`` callable which | ||||
| the application server uses to communicate with your code. It's commonly | ||||
| provided as an object named ``application`` in a Python module accessible to | ||||
| the server. | ||||
|  | ||||
| The :djadmin:`startproject` command creates a :file:`projectname/wsgi.py` that | ||||
| contains such an application callable. | ||||
| The :djadmin:`startproject` command creates a file | ||||
| :file:`<project_name>/wsgi.py` that contains such an ``application`` callable. | ||||
|  | ||||
| It's used both by Django's development server and in production WSGI | ||||
| deployments. | ||||
|  | ||||
| WSGI servers obtain the path to the ``application`` callable from their | ||||
| configuration. Django's built-in servers, namely the :djadmin:`runserver` and | ||||
| :djadmin:`runfcgi` commands, read it from the :setting:`WSGI_APPLICATION` | ||||
| setting. By default, it's set to ``<project_name>.wsgi.application``, which | ||||
| points to the ``application`` callable in :file:`<project_name>/wsgi.py`. | ||||
|  | ||||
| Configuring the settings module | ||||
| ------------------------------- | ||||
|  | ||||
| When the WSGI server loads your application, Django needs to import the | ||||
| settings module — that's where your entire application is defined. | ||||
|  | ||||
| Django uses the :envvar:`DJANGO_SETTINGS_MODULE` environment variable to | ||||
| locate the appropriate settings module. It must contain the dotted path to the | ||||
| settings module. You can use a different value for development and production; | ||||
| it all depends on how you organize your settings. | ||||
|  | ||||
| If this variable isn't set, the default :file:`wsgi.py` sets it to | ||||
| ``mysite.settings``, where ``mysite`` is the name of your project. That's how | ||||
| :djadmin:`runserver` discovers the default settings file by default. | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
|    Upgrading from a previous release of Django and don't have a :file:`wsgi.py` | ||||
|    file in your project? You can simply add one to your project's top-level | ||||
|    Python package (probably next to :file:`settings.py` and :file:`urls.py`) | ||||
|    with the contents below. If you want :djadmin:`runserver` to also make use | ||||
|    of this WSGI file, you can also add ``WSGI_APPLICATION = | ||||
|    "mysite.wsgi.application"`` in your settings (replacing ``mysite`` with the | ||||
|    name of your project). | ||||
|     Since environment variables are process-wide, this doesn't work when you | ||||
|     run multiple Django sites in the same process. This happens with mod_wsgi. | ||||
|  | ||||
| Initially this file contains:: | ||||
|     To avoid this problem, use mod_wsgi's daemon mode with each site in its | ||||
|     own daemon process, or override the value from the environnemnt by | ||||
|     enforcing ``os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"`` in | ||||
|     your :file:`wsgi.py`. | ||||
|  | ||||
|  | ||||
| Applying WSGI middleware | ||||
| ------------------------ | ||||
|  | ||||
| To apply `WSGI middleware`_ you can simply wrap the application object. For | ||||
| istance you could add these lines at the bottom of :file:`wsgi.py`:: | ||||
|  | ||||
|     from helloworld.wsgi import HelloWorldApplication | ||||
|     application = HelloWorldApplication(application) | ||||
|  | ||||
| You could also replace the Django WSGI application with a custom WSGI | ||||
| application that later delegates to the Django WSGI application, if you want | ||||
| to combine a Django application with a WSGI application of another framework. | ||||
|  | ||||
| .. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides | ||||
|  | ||||
| Upgrading from Django < 1.4 | ||||
| --------------------------- | ||||
|  | ||||
| If you're upgrading from Django 1.3.x or earlier, you don't have a | ||||
| :file:`wsgi.py` file in your project. | ||||
|  | ||||
| You can simply add one to your project's top-level Python package (probably | ||||
| next to :file:`settings.py` and :file:`urls.py`) with the contents below:: | ||||
|  | ||||
|     import os | ||||
|  | ||||
|     os.environ.setdefault("DJANGO_SETTINGS_MODULE", "mysite.settings") | ||||
|  | ||||
|     # This application object is used by the development server | ||||
|     # as well as any WSGI server configured to use this file. | ||||
|     from django.core.wsgi import get_wsgi_application | ||||
|     application = get_wsgi_application() | ||||
|  | ||||
| @@ -58,14 +103,6 @@ environment variable. You'll need to edit this line to replace ``mysite`` with | ||||
| the name of your project package, so the path to your settings module is | ||||
| correct. | ||||
|  | ||||
| To apply `WSGI middleware`_ you can simply wrap the application object | ||||
| in the same file:: | ||||
|  | ||||
|     from helloworld.wsgi import HelloWorldApplication | ||||
|     application = HelloWorldApplication(application) | ||||
|  | ||||
| You could also replace the Django WSGI application with a custom WSGI | ||||
| application that later delegates to the Django WSGI application, if you want to | ||||
| combine a Django application with a WSGI application of another framework. | ||||
|  | ||||
| .. _`WSGI middleware`: http://www.python.org/dev/peps/pep-3333/#middleware-components-that-play-both-sides | ||||
| Also add ``WSGI_APPLICATION = "mysite.wsgi.application"`` in your settings, so | ||||
| that :djadmin:`runserver` finds your ``application`` callable. Don't forget to | ||||
| replace ``mysite`` with the name of your project in this line. | ||||
|   | ||||
| @@ -39,8 +39,8 @@ By default, Django will send email from root@localhost. However, some mail | ||||
| providers reject all email from this address. To use a different sender | ||||
| address, modify the :setting:`SERVER_EMAIL` setting. | ||||
|  | ||||
| To disable this behavior, just remove all entries from the :setting:`ADMINS` | ||||
| setting. | ||||
| To activate this behavior, put the email addresses of the recipients in the | ||||
| :setting:`ADMINS` setting. | ||||
|  | ||||
| .. seealso:: | ||||
|  | ||||
|   | ||||
| Before Width: | Height: | Size: 63 KiB After Width: | Height: | Size: 32 KiB | 
| Before Width: | Height: | Size: 24 KiB After Width: | Height: | Size: 16 KiB | 
| Before Width: | Height: | Size: 74 KiB After Width: | Height: | Size: 40 KiB | 
| Before Width: | Height: | Size: 28 KiB After Width: | Height: | Size: 19 KiB | 
| @@ -63,8 +63,8 @@ After the previous tutorials, our project should look like this:: | ||||
|             urls.py | ||||
|             wsgi.py | ||||
|         polls/ | ||||
|             admin.py | ||||
|             __init__.py | ||||
|             admin.py | ||||
|             models.py | ||||
|             tests.py | ||||
|             urls.py | ||||
|   | ||||
| @@ -182,40 +182,40 @@ Database setup | ||||
| -------------- | ||||
|  | ||||
| Now, edit :file:`mysite/settings.py`. It's a normal Python module with | ||||
| module-level variables representing Django settings. Change the | ||||
| following keys in the :setting:`DATABASES` ``'default'`` item to match | ||||
| your database connection settings. | ||||
| module-level variables representing Django settings. | ||||
|  | ||||
| By default, the configuration uses SQLite. If you're new to databases, or | ||||
| you're just interested in trying Django, this is the easiest choice. SQLite is | ||||
| included in Python, so you won't need to install anything else to support your | ||||
| database. | ||||
|  | ||||
| If you wish to use another database, install the appropriate :ref:`database | ||||
| bindings <database-installation>`, and change the following keys in the | ||||
| :setting:`DATABASES` ``'default'`` item to match your database connection | ||||
| settings: | ||||
|  | ||||
| * :setting:`ENGINE <DATABASE-ENGINE>` -- Either | ||||
|   ``'django.db.backends.sqlite3'``, | ||||
|   ``'django.db.backends.postgresql_psycopg2'``, | ||||
|   ``'django.db.backends.mysql'``, ``'django.db.backends.sqlite3'`` or | ||||
|   ``'django.db.backends.mysql'``, or | ||||
|   ``'django.db.backends.oracle'``. Other backends are :setting:`also available | ||||
|   <DATABASE-ENGINE>`. | ||||
|  | ||||
| * :setting:`NAME` -- The name of your database. If you're using | ||||
|   SQLite, the database will be a file on your computer; in that | ||||
|   case, :setting:`NAME` should be the full absolute path, | ||||
|   including filename, of that file. If the file doesn't exist, it | ||||
|   will automatically be created when you synchronize the database | ||||
|   for the first time (see below). | ||||
|  | ||||
|   When specifying the path, always use forward slashes, even on | ||||
|   Windows (e.g. ``C:/homes/user/mysite/sqlite3.db``). | ||||
| * :setting:`NAME` -- The name of your database. If you're using SQLite, the | ||||
|   database will be a file on your computer; in that case, :setting:`NAME` | ||||
|   should be the full absolute path, including filename, of that file. When | ||||
|   specifying the path, always use forward slashes, even on Windows (e.g. | ||||
|   ``C:/homes/user/mysite/sqlite3.db``). | ||||
|  | ||||
| * :setting:`USER` -- Your database username (not used for SQLite). | ||||
|  | ||||
| * :setting:`PASSWORD` -- Your database password (not used for | ||||
|   SQLite). | ||||
| * :setting:`PASSWORD` -- Your database password (not used for SQLite). | ||||
|  | ||||
| * :setting:`HOST` -- The host your database is on. Leave this as | ||||
|   an empty string (or possibly ``127.0.0.1``) if your database server is on the | ||||
|   same physical machine (not used for SQLite). See :setting:`HOST` for details. | ||||
| * :setting:`HOST` -- The host your database is on (not used for SQLite). | ||||
|   Leave this as an empty string (or possibly ``127.0.0.1``) if your | ||||
|   database server is on the same physical machine . | ||||
|  | ||||
| If you're new to databases, we recommend simply using SQLite by setting | ||||
| :setting:`ENGINE <DATABASE-ENGINE>` to ``'django.db.backends.sqlite3'`` and | ||||
| :setting:`NAME` to the place where you'd like to store the database. SQLite is | ||||
| included in Python, so you won't need to install anything else to support your | ||||
| database. | ||||
| For more details, see the reference documentation for :setting:`DATABASES`. | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
| @@ -226,17 +226,20 @@ database. | ||||
|     If you're using SQLite, you don't need to create anything beforehand - the | ||||
|     database file will be created automatically when it is needed. | ||||
|  | ||||
| While you're editing :file:`settings.py`, set :setting:`TIME_ZONE` to your | ||||
| time zone. The default value is the Central time zone in the U.S. (Chicago). | ||||
| While you're editing :file:`mysite/settings.py`, set :setting:`TIME_ZONE` to | ||||
| your time zone. | ||||
|  | ||||
| Also, note the :setting:`INSTALLED_APPS` setting toward the bottom of | ||||
| the file. That holds the names of all Django applications that are | ||||
| activated in this Django instance. Apps can be used in multiple projects, and | ||||
| you can package and distribute them for use by others in their projects. | ||||
| Also, note the :setting:`INSTALLED_APPS` setting at the top of the file. That | ||||
| holds the names of all Django applications that are activated in this Django | ||||
| instance. Apps can be used in multiple projects, and you can package and | ||||
| distribute them for use by others in their projects. | ||||
|  | ||||
| By default, :setting:`INSTALLED_APPS` contains the following apps, all of which | ||||
| come with Django: | ||||
|  | ||||
| * :mod:`django.contrib.admin` -- The admin site. You'll use it in :doc:`part 2 | ||||
|   of this tutorial </intro/tutorial02>`. | ||||
|  | ||||
| * :mod:`django.contrib.auth` -- An authentication system. | ||||
|  | ||||
| * :mod:`django.contrib.contenttypes` -- A framework for content types. | ||||
| @@ -261,11 +264,12 @@ that, run the following command: | ||||
|  | ||||
|     python manage.py syncdb | ||||
|  | ||||
| The :djadmin:`syncdb` command looks at the :setting:`INSTALLED_APPS` setting and | ||||
| creates any necessary database tables according to the database settings in your | ||||
| :file:`settings.py` file. You'll see a message for each database table it | ||||
| creates, and you'll get a prompt asking you if you'd like to create a superuser | ||||
| account for the authentication system. Go ahead and do that. | ||||
| The :djadmin:`syncdb` command looks at the :setting:`INSTALLED_APPS` setting | ||||
| and creates any necessary database tables according to the database settings | ||||
| in your :file:`mysqlite/settings.py` file. You'll see a message for each | ||||
| database table it creates, and you'll get a prompt asking you if you'd like to | ||||
| create a superuser account for the authentication system. Go ahead and do | ||||
| that. | ||||
|  | ||||
| If you're interested, run the command-line client for your database and type | ||||
| ``\dt`` (PostgreSQL), ``SHOW TABLES;`` (MySQL), or ``.schema`` (SQLite) to | ||||
| @@ -288,10 +292,10 @@ Creating models | ||||
| Now that your environment -- a "project" -- is set up, you're set to start | ||||
| doing work. | ||||
|  | ||||
| Each application you write in Django consists of a Python package, somewhere | ||||
| on your `Python path`_, that follows a certain convention. Django comes with a | ||||
| utility that automatically generates the basic directory structure of an app, | ||||
| so you can focus on writing code rather than creating directories. | ||||
| Each application you write in Django consists of a Python package that follows | ||||
| a certain convention. Django comes with a utility that automatically generates | ||||
| the basic directory structure of an app, so you can focus on writing code | ||||
| rather than creating directories. | ||||
|  | ||||
| .. admonition:: Projects vs. apps | ||||
|  | ||||
| @@ -316,6 +320,7 @@ That'll create a directory :file:`polls`, which is laid out like this:: | ||||
|  | ||||
|     polls/ | ||||
|         __init__.py | ||||
|         admin.py | ||||
|         models.py | ||||
|         tests.py | ||||
|         views.py | ||||
| @@ -401,26 +406,21 @@ But first we need to tell our project that the ``polls`` app is installed. | ||||
|     you can distribute apps, because they don't have to be tied to a given | ||||
|     Django installation. | ||||
|  | ||||
| Edit the :file:`settings.py` file again, and change the | ||||
| :setting:`INSTALLED_APPS` setting to include the string ``'polls'``. So | ||||
| it'll look like this:: | ||||
| Edit the :file:`mysite/settings.py` file again, and change the | ||||
| :setting:`INSTALLED_APPS` setting to include the string ``'polls'``. So it'll | ||||
| look like this:: | ||||
|  | ||||
|     INSTALLED_APPS = ( | ||||
|         'django.contrib.admin', | ||||
|         'django.contrib.auth', | ||||
|         'django.contrib.contenttypes', | ||||
|         'django.contrib.sessions', | ||||
|         'django.contrib.sites', | ||||
|         'django.contrib.messages', | ||||
|         'django.contrib.staticfiles', | ||||
|         # Uncomment the next line to enable the admin: | ||||
|         # 'django.contrib.admin', | ||||
|         # Uncomment the next line to enable admin documentation: | ||||
|         # 'django.contrib.admindocs', | ||||
|         'polls', | ||||
|     ) | ||||
|  | ||||
| Now Django knows to include the ``polls`` app. Let's run another | ||||
| command: | ||||
| Now Django knows to include the ``polls`` app. Let's run another command: | ||||
|  | ||||
| .. code-block:: bash | ||||
|  | ||||
| @@ -433,13 +433,13 @@ statements for the polls app): | ||||
|  | ||||
|     BEGIN; | ||||
|     CREATE TABLE "polls_poll" ( | ||||
|         "id" serial NOT NULL PRIMARY KEY, | ||||
|         "id" integer NOT NULL PRIMARY KEY, | ||||
|         "question" varchar(200) NOT NULL, | ||||
|         "pub_date" timestamp with time zone NOT NULL | ||||
|         "pub_date" datetime NOT NULL | ||||
|     ); | ||||
|     CREATE TABLE "polls_choice" ( | ||||
|         "id" serial NOT NULL PRIMARY KEY, | ||||
|         "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id") DEFERRABLE INITIALLY DEFERRED, | ||||
|         "id" integer NOT NULL PRIMARY KEY, | ||||
|         "poll_id" integer NOT NULL REFERENCES "polls_poll" ("id"), | ||||
|         "choice_text" varchar(200) NOT NULL, | ||||
|         "votes" integer NOT NULL | ||||
|     ); | ||||
| @@ -447,7 +447,8 @@ statements for the polls app): | ||||
|  | ||||
| Note the following: | ||||
|  | ||||
| * The exact output will vary depending on the database you are using. | ||||
| * The exact output will vary depending on the database you are using. The | ||||
|   example above is generated for SQLite. | ||||
|  | ||||
| * Table names are automatically generated by combining the name of the app | ||||
|   (``polls``) and the lowercase name of the model -- ``poll`` and | ||||
| @@ -465,8 +466,7 @@ Note the following: | ||||
|   types such as ``auto_increment`` (MySQL), ``serial`` (PostgreSQL), or | ||||
|   ``integer primary key`` (SQLite) are handled for you automatically. Same | ||||
|   goes for quoting of field names -- e.g., using double quotes or single | ||||
|   quotes. The author of this tutorial runs PostgreSQL, so the example | ||||
|   output is in PostgreSQL syntax. | ||||
|   quotes. | ||||
|  | ||||
| * The :djadmin:`sql` command doesn't actually run the SQL in your database - | ||||
|   it just prints it to the screen so that you can see what SQL Django thinks | ||||
|   | ||||
| @@ -21,49 +21,11 @@ automatically-generated admin site. | ||||
|     The admin isn't intended to be used by site visitors. It's for site | ||||
|     managers. | ||||
|  | ||||
| Activate the admin site | ||||
| ======================= | ||||
|  | ||||
| The Django admin site is not activated by default -- it's an opt-in thing. To | ||||
| activate the admin site for your installation, do these three things: | ||||
|  | ||||
| * Uncomment ``"django.contrib.admin"`` in the :setting:`INSTALLED_APPS` setting. | ||||
|  | ||||
| * Run ``python manage.py syncdb``. Since you have added a new application | ||||
|   to :setting:`INSTALLED_APPS`, the database tables need to be updated. | ||||
|  | ||||
| * Edit your ``mysite/urls.py`` file and uncomment the lines that reference | ||||
|   the admin -- there are three lines in total to uncomment. This file is a | ||||
|   URLconf; we'll dig into URLconfs in the next tutorial. For now, all you | ||||
|   need to know is that it maps URL roots to applications. In the end, you | ||||
|   should have a ``urls.py`` file that looks like this: | ||||
|  | ||||
|   .. parsed-literal:: | ||||
|  | ||||
|       from django.conf.urls import patterns, include, url | ||||
|  | ||||
|       # Uncomment the next two lines to enable the admin: | ||||
|       **from django.contrib import admin** | ||||
|       **admin.autodiscover()** | ||||
|  | ||||
|       urlpatterns = patterns('', | ||||
|           # Examples: | ||||
|           # url(r'^$', '{{ project_name }}.views.home', name='home'), | ||||
|           # url(r'^{{ project_name }}/', include('{{ project_name }}.foo.urls')), | ||||
|  | ||||
|           # Uncomment the admin/doc line below to enable admin documentation: | ||||
|           # url(r'^admin/doc/', include('django.contrib.admindocs.urls')), | ||||
|  | ||||
|           # Uncomment the next line to enable the admin: | ||||
|           **url(r'^admin/', include(admin.site.urls)),** | ||||
|       ) | ||||
|  | ||||
|   (The bold lines are the ones that needed to be uncommented.) | ||||
|  | ||||
| Start the development server | ||||
| ============================ | ||||
|  | ||||
| Let's start the development server and explore the admin site. | ||||
| The Django admin site is activated by default. Let's start the development | ||||
| server and explore it. | ||||
|  | ||||
| Recall from Tutorial 1 that you start the development server like so: | ||||
|  | ||||
| @@ -77,6 +39,10 @@ http://127.0.0.1:8000/admin/. You should see the admin's login screen: | ||||
| .. image:: _images/admin01.png | ||||
|    :alt: Django admin login screen | ||||
|  | ||||
| Since :doc:`translation </topics/i18n/translation>` is turned on by default, | ||||
| the login screen may be displayed in your own language, depending on your | ||||
| browser's settings and on whether Django has a translation for this language. | ||||
|  | ||||
| .. admonition:: Doesn't match what you see? | ||||
|  | ||||
|     If at this point, instead of the above login page, you get an error | ||||
| @@ -93,24 +59,26 @@ http://127.0.0.1:8000/admin/. You should see the admin's login screen: | ||||
| Enter the admin site | ||||
| ==================== | ||||
|  | ||||
| Now, try logging in. (You created a superuser account in the first part of this | ||||
| Now, try logging in. You created a superuser account in the first part of this | ||||
| tutorial, remember?  If you didn't create one or forgot the password you can | ||||
| :ref:`create another one <topics-auth-creating-superusers>`.) You should see | ||||
| the Django admin index page: | ||||
| :ref:`create another one <topics-auth-creating-superusers>`. | ||||
|  | ||||
| You should see the Django admin index page: | ||||
|  | ||||
| .. image:: _images/admin02t.png | ||||
|    :alt: Django admin index page | ||||
|  | ||||
| You should see a few types of editable content, including groups, users | ||||
| and sites. These are core features Django ships with by default. | ||||
| You should see a few types of editable content: groups and users. They are | ||||
| provided by :mod:`django.contrib.auth`, the authentication framework shipped | ||||
| by Django. | ||||
|  | ||||
| Make the poll app modifiable in the admin | ||||
| ========================================= | ||||
|  | ||||
| But where's our poll app? It's not displayed on the admin index page. | ||||
|  | ||||
| Just one thing to do: We need to tell the admin that ``Poll`` | ||||
| objects have an admin interface. To do this, create a file called | ||||
| Just one thing to do: we need to tell the admin that ``Poll`` | ||||
| objects have an admin interface. To do this, open the file called | ||||
| ``admin.py`` in your ``polls`` directory, and edit it to look like this:: | ||||
|  | ||||
|     from django.contrib import admin | ||||
| @@ -118,10 +86,6 @@ objects have an admin interface. To do this, create a file called | ||||
|  | ||||
|     admin.site.register(Poll) | ||||
|  | ||||
| You'll need to restart the development server to see your changes. Normally, | ||||
| the server auto-reloads code every time you modify a file, but the action of | ||||
| creating a new file doesn't trigger the auto-reloading logic. | ||||
|  | ||||
| Explore the free admin functionality | ||||
| ==================================== | ||||
|  | ||||
| @@ -145,7 +109,7 @@ Click the "What's up?" poll to edit it: | ||||
|  | ||||
| Things to note here: | ||||
|  | ||||
| * The form is automatically generated from the Poll model. | ||||
| * The form is automatically generated from the ``Poll`` model. | ||||
|  | ||||
| * The different model field types (:class:`~django.db.models.DateTimeField`, | ||||
|   :class:`~django.db.models.CharField`) correspond to the appropriate HTML | ||||
| @@ -302,7 +266,7 @@ registration code to read:: | ||||
| This tells Django: "``Choice`` objects are edited on the ``Poll`` admin page. By | ||||
| default, provide enough fields for 3 choices." | ||||
|  | ||||
| Load the "Add poll" page to see how that looks, you may need to restart your development server: | ||||
| Load the "Add poll" page to see how that looks: | ||||
|  | ||||
| .. image:: _images/admin11t.png | ||||
|    :alt: Add poll page now has choices on it | ||||
| @@ -435,31 +399,24 @@ That's easy to change, though, using Django's template system. The Django admin | ||||
| is powered by Django itself, and its interfaces use Django's own template | ||||
| system. | ||||
|  | ||||
| Open your settings file (``mysite/settings.py``, remember) and look at the | ||||
| :setting:`TEMPLATE_DIRS` setting. :setting:`TEMPLATE_DIRS` is a tuple of | ||||
| filesystem directories to check when loading Django templates. It's a search | ||||
| path. | ||||
|  | ||||
| Create a ``mytemplates`` directory in your project directory. Templates can | ||||
| live anywhere on your filesystem that Django can access. (Django runs as | ||||
| whatever user your server runs.) However, keeping your templates within the | ||||
| project is a good convention to follow. | ||||
|  | ||||
| By default, :setting:`TEMPLATE_DIRS` is empty. So, let's add a line to it, to | ||||
| tell Django where our templates live:: | ||||
| Open your settings file (``mysite/settings.py``, remember) and  add a | ||||
| :setting:`TEMPLATE_DIRS` setting:: | ||||
|  | ||||
|     TEMPLATE_DIRS = ( | ||||
|         '/path/to/mysite/mytemplates', # Change this to your own directory. | ||||
|     ) | ||||
|     TEMPLATE_DIRS = (os.path.join(BASE_DIR, 'mytemplates'),) | ||||
|  | ||||
| Now copy the template ``admin/base_site.html`` from within the default Django | ||||
| admin template directory in the source code of Django itself | ||||
| (``django/contrib/admin/templates``) into an ``admin`` subdirectory of | ||||
| whichever directory you're using in :setting:`TEMPLATE_DIRS`. For example, if | ||||
| your :setting:`TEMPLATE_DIRS` includes ``'/path/to/mysite/mytemplates'``, as | ||||
| above, then copy ``django/contrib/admin/templates/admin/base_site.html`` to | ||||
| ``/path/to/mysite/mytemplates/admin/base_site.html``. Don't forget that | ||||
| ``admin`` subdirectory. | ||||
| Don't forget the trailing comma. :setting:`TEMPLATE_DIRS` is a tuple of | ||||
| filesystem directories to check when loading Django templates; it's a search | ||||
| path. | ||||
|  | ||||
| Now create a directory called ``admin`` inside ``mytemplates``, and copy the | ||||
| template ``admin/base_site.html`` from within the default Django admin | ||||
| template directory in the source code of Django itself | ||||
| (``django/contrib/admin/templates``) into that directory. | ||||
|  | ||||
| .. admonition:: Where are the Django source files? | ||||
|  | ||||
|   | ||||
| @@ -159,8 +159,7 @@ can do in an automated test, so let's turn that into an automated test. | ||||
| The best place for an application's tests is in the application's ``tests.py`` | ||||
| file - the testing system will look there for tests automatically. | ||||
|  | ||||
| Put the following in the ``tests.py`` file in the ``polls`` application (you'll | ||||
| notice  ``tests.py`` contains some dummy tests, you can remove those):: | ||||
| Put the following in the ``tests.py`` file in the ``polls`` application:: | ||||
|  | ||||
|     import datetime | ||||
|  | ||||
|   | ||||
| @@ -51,7 +51,7 @@ How to use it | ||||
| Setting X-Frame-Options for all responses | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| To set the same X-Frame-Options value for all responses in your site, add | ||||
| To set the same X-Frame-Options value for all responses in your site, put | ||||
| ``'django.middleware.clickjacking.XFrameOptionsMiddleware'`` to | ||||
| :setting:`MIDDLEWARE_CLASSES`:: | ||||
|  | ||||
| @@ -61,6 +61,10 @@ To set the same X-Frame-Options value for all responses in your site, add | ||||
|         ... | ||||
|     ) | ||||
|  | ||||
| .. versionchanged:: 1.6 | ||||
|     This middleware is enabled in the settings file generated by | ||||
|     :djadmin:`startproject`. | ||||
|  | ||||
| By default, the middleware will set the X-Frame-Options header to SAMEORIGIN for | ||||
| every outgoing ``HttpResponse``. If you want DENY instead, set the | ||||
| :setting:`X_FRAME_OPTIONS` setting:: | ||||
|   | ||||
| @@ -14,7 +14,13 @@ Django's admin interface. | ||||
| Overview | ||||
| ======== | ||||
|  | ||||
| There are seven steps in activating the Django admin site: | ||||
| The admin is enabled in the default project template used by | ||||
| :djadmin:`startproject`. | ||||
|  | ||||
| .. versionchanged:: 1.6 | ||||
|     In previous versions, the admin wasn't enabled by default. | ||||
|  | ||||
| For reference, here are the requirements: | ||||
|  | ||||
| 1. Add ``'django.contrib.admin'`` to your :setting:`INSTALLED_APPS` | ||||
|    setting. | ||||
|   | ||||
| @@ -115,13 +115,12 @@ In addition, modify the :setting:`INSTALLED_APPS` setting to include | ||||
| and ``world`` (your newly created application):: | ||||
|  | ||||
|     INSTALLED_APPS = ( | ||||
|         'django.contrib.admin', | ||||
|         'django.contrib.auth', | ||||
|         'django.contrib.contenttypes', | ||||
|         'django.contrib.sessions', | ||||
|         'django.contrib.sites', | ||||
|         'django.contrib.messages', | ||||
|         'django.contrib.staticfiles', | ||||
|         'django.contrib.admin', | ||||
|         'django.contrib.gis', | ||||
|         'world' | ||||
|     ) | ||||
|   | ||||
| @@ -247,13 +247,29 @@ To do this, you can use the sites framework. A simple example:: | ||||
|     'http://example.com/mymodel/objects/3/' | ||||
|  | ||||
|  | ||||
| Default site and ``syncdb`` | ||||
| =========================== | ||||
| Enabling the sites framework | ||||
| ============================ | ||||
|  | ||||
| .. versionchanged:: 1.6 | ||||
|     In previous versions, the sites framework was enabled by default. | ||||
|  | ||||
| To enable the sites framework, follow these steps: | ||||
|  | ||||
| 1. Add ``'django.contrib.sites'`` to your :setting:`INSTALLED_APPS` | ||||
|    setting. | ||||
|  | ||||
| 2. Define a :setting:`SITE_ID` setting:: | ||||
|  | ||||
|     SITE_ID = 1 | ||||
|  | ||||
| 3. Run :djadmin:`syncdb`. | ||||
|  | ||||
| ``django.contrib.sites`` registers a | ||||
| :data:`~django.db.models.signals.post_syncdb` signal handler which creates a | ||||
| default site named ``example.com`` with the domain ``example.com``. For | ||||
| example, this site will be created after Django creates the test database. | ||||
| default site named ``example.com`` with the domain ``example.com``. This site | ||||
| will also be created after Django creates the test database. To set the | ||||
| correct name and domain for your project, you can use an :doc:`initial data | ||||
| fixture </howto/initial-data>`. | ||||
|  | ||||
| Caching the current ``Site`` object | ||||
| =================================== | ||||
|   | ||||
| @@ -921,6 +921,8 @@ For example:: | ||||
|  | ||||
|     django-admin.py startapp myapp /Users/jezdez/Code/myapp | ||||
|  | ||||
| .. _custom-app-and-project-templates: | ||||
|  | ||||
| .. django-admin-option:: --template | ||||
|  | ||||
| With the ``--template`` option, you can use a custom app template by providing | ||||
| @@ -952,6 +954,7 @@ with the ``--name`` option. The :class:`template context | ||||
|   options) | ||||
| - ``app_name`` -- the app name as passed to the command | ||||
| - ``app_directory`` -- the full path of the newly created app | ||||
| - ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'`` | ||||
|  | ||||
| .. _render_warning: | ||||
|  | ||||
| @@ -1021,6 +1024,7 @@ with the ``--name`` option. The :class:`template context | ||||
| - ``project_name`` -- the project name as passed to the command | ||||
| - ``project_directory`` -- the full path of the newly created project | ||||
| - ``secret_key`` -- a random key for the :setting:`SECRET_KEY` setting | ||||
| - ``docs_version`` -- the version of the documentation: ``'dev'`` or ``'1.x'`` | ||||
|  | ||||
| Please also see the :ref:`rendering warning <render_warning>` as mentioned | ||||
| for :djadmin:`startapp`. | ||||
|   | ||||
| @@ -1134,9 +1134,12 @@ LANGUAGE_CODE | ||||
|  | ||||
| Default: ``'en-us'`` | ||||
|  | ||||
| A string representing the language code for this installation. This should be in | ||||
| standard :term:`language format<language code>`. For example, U.S. English is | ||||
| ``"en-us"``. See :doc:`/topics/i18n/index`. | ||||
| A string representing the language code for this installation. This should be | ||||
| in standard :term:`language format<language code>`. For example, U.S. English | ||||
| is ``"en-us"``. See also the `list of language identifiers`_ and | ||||
| :doc:`/topics/i18n/index`. | ||||
|  | ||||
| .. _list of language identifiers: http://www.i18nguy.com/unicode/language-identifiers.html | ||||
|  | ||||
| .. setting:: LANGUAGE_COOKIE_NAME | ||||
|  | ||||
| @@ -1668,12 +1671,8 @@ TIME_ZONE | ||||
|  | ||||
| Default: ``'America/Chicago'`` | ||||
|  | ||||
| A string representing the time zone for this installation, or | ||||
| ``None``. `See available choices`_. (Note that list of available | ||||
| choices lists more than one on the same line; you'll want to use just | ||||
| one of the choices for a given time zone. For instance, one line says | ||||
| ``'Europe/London GB GB-Eire'``, but you should use the first bit of | ||||
| that -- ``'Europe/London'`` -- as your :setting:`TIME_ZONE` setting.) | ||||
| A string representing the time zone for this installation, or ``None``. See | ||||
| the `list of time zones`_. | ||||
|  | ||||
| Note that this isn't necessarily the time zone of the server. For example, one | ||||
| server may serve multiple Django-powered sites, each with a separate time zone | ||||
| @@ -1706,7 +1705,7 @@ to ensure your processes are running in the correct environment. | ||||
|     If you're running Django on Windows, :setting:`TIME_ZONE` must be set to | ||||
|     match the system time zone. | ||||
|  | ||||
| .. _See available choices: http://www.postgresql.org/docs/8.1/static/datetime-keywords.html#DATETIME-TIMEZONE-SET-TABLE | ||||
| .. _list of time zones: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones | ||||
|  | ||||
| .. _pytz: http://pytz.sourceforge.net/ | ||||
|  | ||||
|   | ||||
| @@ -17,6 +17,19 @@ deprecation process for some features`_. | ||||
| What's new in Django 1.6 | ||||
| ======================== | ||||
|  | ||||
| Simplified default project and app templates | ||||
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||||
|  | ||||
| The default templates used by :djadmin:`startproject` and :djadmin:`startapp` | ||||
| have been simplified and modernized. The :doc:`admin | ||||
| </ref/contrib/admin/index>` is now enabled by default in new projects; the | ||||
| :doc:`sites </ref/contrib/sites>` framework no longer is. :ref:`Language | ||||
| detection <how-django-discovers-language-preference>` and :ref:`clickjacking | ||||
| prevention <clickjacking-prevention>` are turned on. | ||||
|  | ||||
| If the default templates don't suit your tastes, you can use :ref:`custom | ||||
| project and app templates <custom-app-and-project-templates>`. | ||||
|  | ||||
| Minor features | ||||
| ~~~~~~~~~~~~~~ | ||||
|  | ||||
|   | ||||
| @@ -29,7 +29,9 @@ use internationalization, you should take the two seconds to set | ||||
| :setting:`USE_I18N = False <USE_I18N>` in your settings file. Then Django will | ||||
| make some optimizations so as not to load the internationalization machinery. | ||||
| You'll probably also want to remove ``'django.core.context_processors.i18n'`` | ||||
| from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting. | ||||
| from your :setting:`TEMPLATE_CONTEXT_PROCESSORS` setting and | ||||
| ``'django.middleware.locale.LocaleMiddleware'`` from your | ||||
| :setting:`MIDDLEWARE_CLASSES` setting. | ||||
|  | ||||
| .. note:: | ||||
|  | ||||
| @@ -1476,9 +1478,14 @@ If you want to let each individual user specify which language he or she | ||||
| prefers, use ``LocaleMiddleware``. ``LocaleMiddleware`` enables language | ||||
| selection based on data from the request. It customizes content for each user. | ||||
|  | ||||
| To use ``LocaleMiddleware``, add ``'django.middleware.locale.LocaleMiddleware'`` | ||||
| to your :setting:`MIDDLEWARE_CLASSES` setting. Because middleware order | ||||
| matters, you should follow these guidelines: | ||||
| ``LocaleMiddleware`` is enabled in the default settings file: the | ||||
| :setting:`MIDDLEWARE_CLASSES` setting contains | ||||
| ``'django.middleware.locale.LocaleMiddleware'``. | ||||
|  | ||||
| .. versionchanged:: 1.6 | ||||
|     In previous versions, ``LocaleMiddleware`  wasn't enabled by default. | ||||
|  | ||||
| Because middleware order matters, you should follow these guidelines: | ||||
|  | ||||
| * Make sure it's one of the first middlewares installed. | ||||
| * It should come after ``SessionMiddleware``, because ``LocaleMiddleware`` | ||||
|   | ||||