mirror of https://github.com/django/django.git
Changed e-mail to email throughout documentation and codebase. The one exception is translation strings, which I didn't want to disrupt
git-svn-id: http://code.djangoproject.com/svn/django/trunk@15967 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Adrian Holovaty
parent
7099d465ab
commit
94af19c43f
|
|
@ -124,7 +124,7 @@ LANGUAGE_COOKIE_NAME = 'django_language'
|
|||
USE_L10N = False
|
||||
|
||||
# Not-necessarily-technical managers of the site. They get broken link
|
||||
# notifications and other various e-mails.
|
||||
# notifications and other various emails.
|
||||
MANAGERS = ADMINS
|
||||
|
||||
# Default content type and charset to use for all HttpResponse objects, if a
|
||||
|
|
@ -139,7 +139,7 @@ FILE_CHARSET = 'utf-8'
|
|||
# E-mail address that error messages come from.
|
||||
SERVER_EMAIL = 'root@localhost'
|
||||
|
||||
# Whether to send broken-link e-mails.
|
||||
# Whether to send broken-link emails.
|
||||
SEND_BROKEN_LINK_EMAILS = False
|
||||
|
||||
# Database connection info.
|
||||
|
|
@ -165,10 +165,10 @@ DATABASE_ROUTERS = []
|
|||
# to a module that defines an EmailBackend class.
|
||||
EMAIL_BACKEND = 'django.core.mail.backends.smtp.EmailBackend'
|
||||
|
||||
# Host for sending e-mail.
|
||||
# Host for sending email.
|
||||
EMAIL_HOST = 'localhost'
|
||||
|
||||
# Port for sending e-mail.
|
||||
# Port for sending email.
|
||||
EMAIL_PORT = 25
|
||||
|
||||
# Optional SMTP authentication information for EMAIL_HOST.
|
||||
|
|
@ -207,7 +207,7 @@ TEMPLATE_CONTEXT_PROCESSORS = (
|
|||
# Output to use in template system for invalid (e.g. misspelled) variables.
|
||||
TEMPLATE_STRING_IF_INVALID = ''
|
||||
|
||||
# Default e-mail address to use for various automated correspondence from
|
||||
# Default email address to use for various automated correspondence from
|
||||
# the site managers.
|
||||
DEFAULT_FROM_EMAIL = 'webmaster@localhost'
|
||||
|
||||
|
|
@ -462,11 +462,11 @@ COMMENTS_BANNED_USERS_GROUP = None
|
|||
# Set to None if you're not using it.
|
||||
COMMENTS_MODERATORS_GROUP = None
|
||||
|
||||
# The group ID that designates the users whose comments should be e-mailed to MANAGERS.
|
||||
# The group ID that designates the users whose comments should be emailed to MANAGERS.
|
||||
# Set to None if you're not using it.
|
||||
COMMENTS_SKETCHY_USERS_GROUP = None
|
||||
|
||||
# The system will e-mail MANAGERS the first COMMENTS_FIRST_FEW comments by each
|
||||
# The system will email MANAGERS the first COMMENTS_FIRST_FEW comments by each
|
||||
# user. Set this to 0 if you want to disable it.
|
||||
COMMENTS_FIRST_FEW = 0
|
||||
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ class PasswordResetForm(forms.Form):
|
|||
|
||||
def clean_email(self):
|
||||
"""
|
||||
Validates that an active user exists with the given e-mail address.
|
||||
Validates that an active user exists with the given email address.
|
||||
"""
|
||||
email = self.cleaned_data["email"]
|
||||
self.users_cache = User.objects.filter(
|
||||
|
|
|
|||
|
|
@ -100,7 +100,7 @@ class Group(models.Model):
|
|||
|
||||
A user in a group automatically has all the permissions granted to that group. For example, if the group Site editors has the permission can_edit_home_page, any user in that group will have that permission.
|
||||
|
||||
Beyond permissions, groups are a convenient way to categorize users to apply some label, or extended functionality, to them. For example, you could create a group 'Special users', and you could write code that would do special things to those users -- such as giving them access to a members-only portion of your site, or sending them members-only e-mail messages.
|
||||
Beyond permissions, groups are a convenient way to categorize users to apply some label, or extended functionality, to them. For example, you could create a group 'Special users', and you could write code that would do special things to those users -- such as giving them access to a members-only portion of your site, or sending them members-only email messages.
|
||||
"""
|
||||
name = models.CharField(_('name'), max_length=80, unique=True)
|
||||
permissions = models.ManyToManyField(Permission, verbose_name=_('permissions'), blank=True)
|
||||
|
|
@ -115,7 +115,7 @@ class Group(models.Model):
|
|||
class UserManager(models.Manager):
|
||||
def create_user(self, username, email, password=None):
|
||||
"""
|
||||
Creates and saves a User with the given username, e-mail and password.
|
||||
Creates and saves a User with the given username, email and password.
|
||||
"""
|
||||
now = datetime.datetime.now()
|
||||
|
||||
|
|
@ -353,7 +353,7 @@ class User(models.Model):
|
|||
return messages
|
||||
|
||||
def email_user(self, subject, message, from_email=None):
|
||||
"Sends an e-mail to this User."
|
||||
"Sends an email to this User."
|
||||
from django.core.mail import send_mail
|
||||
send_mail(subject, message, from_email, [self.email])
|
||||
|
||||
|
|
|
|||
|
|
@ -147,7 +147,7 @@ class RemoteUserCustomTest(RemoteUserTest):
|
|||
|
||||
backend =\
|
||||
'django.contrib.auth.tests.remote_user.CustomRemoteUserBackend'
|
||||
# REMOTE_USER strings with e-mail addresses for the custom backend to
|
||||
# REMOTE_USER strings with email addresses for the custom backend to
|
||||
# clean.
|
||||
known_user = 'knownuser@example.com'
|
||||
known_user2 = 'knownuser2@example.com'
|
||||
|
|
|
|||
|
|
@ -19,7 +19,7 @@ from django.core.mail.message import \
|
|||
from django.core.mail.backends.smtp import EmailBackend as _SMTPConnection
|
||||
|
||||
def get_connection(backend=None, fail_silently=False, **kwds):
|
||||
"""Load an e-mail backend and return an instance of it.
|
||||
"""Load an email backend and return an instance of it.
|
||||
|
||||
If backend is None (default) settings.EMAIL_BACKEND is used.
|
||||
|
||||
|
|
@ -65,7 +65,7 @@ def send_mass_mail(datatuple, fail_silently=False, auth_user=None,
|
|||
auth_password=None, connection=None):
|
||||
"""
|
||||
Given a datatuple of (subject, message, from_email, recipient_list), sends
|
||||
each message to each recipient list. Returns the number of e-mails sent.
|
||||
each message to each recipient list. Returns the number of emails sent.
|
||||
|
||||
If from_email is None, the DEFAULT_FROM_EMAIL setting is used.
|
||||
If auth_user and auth_password are set, they're used to log in.
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ class AdminEmailHandler(logging.Handler):
|
|||
logging.Handler.__init__(self)
|
||||
self.include_html = include_html
|
||||
|
||||
"""An exception log handler that e-mails log entries to site admins.
|
||||
"""An exception log handler that emails log entries to site admins.
|
||||
|
||||
If the request is passed as the first argument to the log record,
|
||||
request data will be provided in the
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ the question on IRC -- visit the `#django IRC channel`_ on the Freenode IRC
|
|||
network.
|
||||
|
||||
You might notice we have a second mailing list, called django-developers_ --
|
||||
but please don't e-mail support questions to this mailing list. This list is
|
||||
but please don't email support questions to this mailing list. This list is
|
||||
for discussion of the development of Django itself. Asking a tech support
|
||||
question there is considered quite impolite.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Error reporting via e-mail
|
||||
Error reporting via email
|
||||
==========================
|
||||
|
||||
When you're running a public site you should always turn off the
|
||||
|
|
@ -9,12 +9,12 @@ revealed by the error pages.
|
|||
However, running with :setting:`DEBUG` set to ``False`` means you'll never see
|
||||
errors generated by your site -- everyone will just see your public error pages.
|
||||
You need to keep track of errors that occur in deployed sites, so Django can be
|
||||
configured to e-mail you details of those errors.
|
||||
configured to email you details of those errors.
|
||||
|
||||
Server errors
|
||||
-------------
|
||||
|
||||
When :setting:`DEBUG` is ``False``, Django will e-mail the users listed in the
|
||||
When :setting:`DEBUG` is ``False``, Django will email the users listed in the
|
||||
:setting:`ADMINS` setting whenever your code raises an unhandled exception and
|
||||
results in an internal server error (HTTP status code 500). This gives the
|
||||
administrators immediate notification of any errors. The :setting:`ADMINS` will
|
||||
|
|
@ -23,7 +23,7 @@ the HTTP request that caused the error.
|
|||
|
||||
.. note::
|
||||
|
||||
In order to send e-mail, Django requires a few settings telling it
|
||||
In order to send email, Django requires a few settings telling it
|
||||
how to connect to your mail server. At the very least, you'll need
|
||||
to specify :setting:`EMAIL_HOST` and possibly
|
||||
:setting:`EMAIL_HOST_USER` and :setting:`EMAIL_HOST_PASSWORD`,
|
||||
|
|
@ -32,8 +32,8 @@ the HTTP request that caused the error.
|
|||
documentation </ref/settings>` for a full list of email-related
|
||||
settings.
|
||||
|
||||
By default, Django will send e-mail from root@localhost. However, some mail
|
||||
providers reject all e-mail from this address. To use a different sender
|
||||
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`
|
||||
|
|
@ -43,15 +43,15 @@ setting.
|
|||
|
||||
.. versionadded:: 1.3
|
||||
|
||||
Server error e-mails are sent using the logging framework, so you can
|
||||
Server error emails are sent using the logging framework, so you can
|
||||
customize this behaviour by :doc:`customizing your logging configuration
|
||||
</topics/logging>`.
|
||||
|
||||
404 errors
|
||||
----------
|
||||
|
||||
Django can also be configured to e-mail errors about broken links (404 "page
|
||||
not found" errors). Django sends e-mails about 404 errors when:
|
||||
Django can also be configured to email errors about broken links (404 "page
|
||||
not found" errors). Django sends emails about 404 errors when:
|
||||
|
||||
* :setting:`DEBUG` is ``False``
|
||||
|
||||
|
|
@ -60,9 +60,9 @@ not found" errors). Django sends e-mails about 404 errors when:
|
|||
* Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware``
|
||||
(which it does by default).
|
||||
|
||||
If those conditions are met, Django will e-mail the users listed in the
|
||||
If those conditions are met, Django will email the users listed in the
|
||||
:setting:`MANAGERS` setting whenever your code raises a 404 and the request has
|
||||
a referer. (It doesn't bother to e-mail for 404s that don't have a referer --
|
||||
a referer. (It doesn't bother to email for 404s that don't have a referer --
|
||||
those are usually just people typing in broken URLs or broken Web 'bots).
|
||||
|
||||
You can tell Django to stop reporting particular 404s by tweaking the
|
||||
|
|
|
|||
|
|
@ -159,7 +159,7 @@ The development process
|
|||
:doc:`FastCGI/SCGI/AJP <howto/deployment/fastcgi>` |
|
||||
:doc:`Apache authentication <howto/apache-auth>` |
|
||||
:doc:`Handling static files <howto/static-files>` |
|
||||
:doc:`Tracking code errors by e-mail <howto/error-reporting>`
|
||||
:doc:`Tracking code errors by email <howto/error-reporting>`
|
||||
|
||||
Other batteries included
|
||||
========================
|
||||
|
|
|
|||
|
|
@ -151,7 +151,7 @@ Joseph Kocherhans
|
|||
`Gary Wilson`_
|
||||
Gary starting contributing patches to Django in 2006 while developing Web
|
||||
applications for `The University of Texas`_ (UT). Since, he has made
|
||||
contributions to the e-mail and forms systems, as well as many other
|
||||
contributions to the email and forms systems, as well as many other
|
||||
improvements and code cleanups throughout the code base.
|
||||
|
||||
Gary is currently a developer and software engineering graduate student at
|
||||
|
|
|
|||
|
|
@ -113,7 +113,7 @@ following actions:
|
|||
security problems immediately.
|
||||
|
||||
* Pre-notify everyone we know to be running the affected version(s) of
|
||||
Django. We will send these notifications through private e-mail
|
||||
Django. We will send these notifications through private email
|
||||
which will include documentation of the vulnerability, links to the
|
||||
relevant patch(es), and a request to keep the vulnerability
|
||||
confidential until the official go-public date.
|
||||
|
|
@ -788,7 +788,7 @@ documentation:
|
|||
* **Django** -- when referring to the framework, capitalize Django. It is
|
||||
lowercase only in Python code and in the djangoproject.com logo.
|
||||
|
||||
* **e-mail** -- it has a hyphen.
|
||||
* **email** -- no hyphen.
|
||||
|
||||
* **MySQL**
|
||||
|
||||
|
|
|
|||
|
|
@ -45,7 +45,7 @@ of 1.0. This includes these APIs:
|
|||
- :doc:`Model definition, managers, querying and transactions
|
||||
</topics/db/index>`
|
||||
|
||||
- :doc:`Sending e-mail </topics/email>`.
|
||||
- :doc:`Sending email </topics/email>`.
|
||||
|
||||
- :doc:`File handling and storage </topics/files>`
|
||||
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ Here's the basic workflow for how a user would use a wizard:
|
|||
3. Step 1 and 2 repeat, for every subsequent form in the wizard.
|
||||
4. Once the user has submitted all the forms and all the data has been
|
||||
validated, the wizard processes the data -- saving it to the database,
|
||||
sending an e-mail, or whatever the application needs to do.
|
||||
sending an email, or whatever the application needs to do.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
|
@ -67,7 +67,7 @@ convention is to put them in a file called :file:`forms.py` in your
|
|||
application.
|
||||
|
||||
For example, let's write a "contact form" wizard, where the first page's form
|
||||
collects the sender's e-mail address and subject, and the second page collects
|
||||
collects the sender's email address and subject, and the second page collects
|
||||
the message itself. Here's what the :file:`forms.py` might look like::
|
||||
|
||||
from django import forms
|
||||
|
|
|
|||
|
|
@ -181,9 +181,9 @@ fallback for cases where it is not installed.
|
|||
Getting the current domain for display
|
||||
--------------------------------------
|
||||
|
||||
LJWorld.com and Lawrence.com both have e-mail alert functionality, which lets
|
||||
LJWorld.com and Lawrence.com both have email alert functionality, which lets
|
||||
readers sign up to get notifications when news happens. It's pretty basic: A
|
||||
reader signs up on a Web form, and he immediately gets an e-mail saying,
|
||||
reader signs up on a Web form, and he immediately gets an email saying,
|
||||
"Thanks for your subscription."
|
||||
|
||||
It'd be inefficient and redundant to implement this signup-processing code
|
||||
|
|
@ -211,9 +211,9 @@ Here's an example of what the form-handling view looks like::
|
|||
|
||||
# ...
|
||||
|
||||
On Lawrence.com, this e-mail has the subject line "Thanks for subscribing to
|
||||
lawrence.com alerts." On LJWorld.com, the e-mail has the subject "Thanks for
|
||||
subscribing to LJWorld.com alerts." Same goes for the e-mail's message body.
|
||||
On Lawrence.com, this email has the subject line "Thanks for subscribing to
|
||||
lawrence.com alerts." On LJWorld.com, the email has the subject "Thanks for
|
||||
subscribing to LJWorld.com alerts." Same goes for the email's message body.
|
||||
|
||||
Note that an even more flexible (but more heavyweight) way of doing this would
|
||||
be to use Django's template system. Assuming Lawrence.com and LJWorld.com have
|
||||
|
|
|
|||
|
|
@ -455,15 +455,15 @@ This example illustrates all possible attributes and methods for a
|
|||
def author_email(self, obj):
|
||||
"""
|
||||
Takes the object returned by get_object() and returns the feed's
|
||||
author's e-mail as a normal Python string.
|
||||
author's email as a normal Python string.
|
||||
"""
|
||||
|
||||
def author_email(self):
|
||||
"""
|
||||
Returns the feed's author's e-mail as a normal Python string.
|
||||
Returns the feed's author's email as a normal Python string.
|
||||
"""
|
||||
|
||||
author_email = 'test@example.com' # Hard-coded author e-mail.
|
||||
author_email = 'test@example.com' # Hard-coded author email.
|
||||
|
||||
# AUTHOR LINK --One of the following three is optional. The framework
|
||||
# looks for them in this order. In each case, the URL should include
|
||||
|
|
@ -637,15 +637,15 @@ This example illustrates all possible attributes and methods for a
|
|||
def item_author_email(self, obj):
|
||||
"""
|
||||
Takes an item, as returned by items(), and returns the item's
|
||||
author's e-mail as a normal Python string.
|
||||
author's email as a normal Python string.
|
||||
"""
|
||||
|
||||
def item_author_email(self):
|
||||
"""
|
||||
Returns the author e-mail for every item in the feed.
|
||||
Returns the author email for every item in the feed.
|
||||
"""
|
||||
|
||||
item_author_email = 'test@example.com' # Hard-coded author e-mail.
|
||||
item_author_email = 'test@example.com' # Hard-coded author email.
|
||||
|
||||
# ITEM AUTHOR LINK -- One of the following three is optional. The
|
||||
# framework looks for them in this order. In each case, the URL should
|
||||
|
|
|
|||
|
|
@ -1086,7 +1086,7 @@ a password has been manually set for it.
|
|||
.. django-admin-option:: --username
|
||||
.. django-admin-option:: --email
|
||||
|
||||
The username and e-mail address for the new account can be supplied by
|
||||
The username and email address for the new account can be supplied by
|
||||
using the ``--username`` and ``--email`` arguments on the command
|
||||
line. If either of those is not supplied, ``createsuperuser`` will prompt for
|
||||
it when running interactively.
|
||||
|
|
|
|||
|
|
@ -89,11 +89,11 @@ and return a boolean designating whether the data was valid::
|
|||
|
||||
Let's try with some invalid data. In this case, ``subject`` is blank (an error,
|
||||
because all fields are required by default) and ``sender`` is not a valid
|
||||
e-mail address::
|
||||
email address::
|
||||
|
||||
>>> data = {'subject': '',
|
||||
... 'message': 'Hi there',
|
||||
... 'sender': 'invalid e-mail address',
|
||||
... 'sender': 'invalid email address',
|
||||
... 'cc_myself': True}
|
||||
>>> f = ContactForm(data)
|
||||
>>> f.is_valid()
|
||||
|
|
@ -105,7 +105,7 @@ Access the :attr:`~Form.errors` attribute to get a dictionary of error
|
|||
messages::
|
||||
|
||||
>>> f.errors
|
||||
{'sender': [u'Enter a valid e-mail address.'], 'subject': [u'This field is required.']}
|
||||
{'sender': [u'Enter a valid email address.'], 'subject': [u'This field is required.']}
|
||||
|
||||
In this dictionary, the keys are the field names, and the values are lists of
|
||||
Unicode strings representing the error messages. The error messages are stored
|
||||
|
|
@ -204,7 +204,7 @@ If your data does *not* validate, your ``Form`` instance will not have a
|
|||
|
||||
>>> data = {'subject': '',
|
||||
... 'message': 'Hi there',
|
||||
... 'sender': 'invalid e-mail address',
|
||||
... 'sender': 'invalid email address',
|
||||
... 'cc_myself': True}
|
||||
>>> f = ContactForm(data)
|
||||
>>> f.is_valid()
|
||||
|
|
@ -531,25 +531,25 @@ method you're using::
|
|||
|
||||
>>> data = {'subject': '',
|
||||
... 'message': 'Hi there',
|
||||
... 'sender': 'invalid e-mail address',
|
||||
... 'sender': 'invalid email address',
|
||||
... 'cc_myself': True}
|
||||
>>> f = ContactForm(data, auto_id=False)
|
||||
>>> print f.as_table()
|
||||
<tr><th>Subject:</th><td><ul class="errorlist"><li>This field is required.</li></ul><input type="text" name="subject" maxlength="100" /></td></tr>
|
||||
<tr><th>Message:</th><td><input type="text" name="message" value="Hi there" /></td></tr>
|
||||
<tr><th>Sender:</th><td><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul><input type="text" name="sender" value="invalid e-mail address" /></td></tr>
|
||||
<tr><th>Sender:</th><td><ul class="errorlist"><li>Enter a valid email address.</li></ul><input type="text" name="sender" value="invalid email address" /></td></tr>
|
||||
<tr><th>Cc myself:</th><td><input checked="checked" type="checkbox" name="cc_myself" /></td></tr>
|
||||
>>> print f.as_ul()
|
||||
<li><ul class="errorlist"><li>This field is required.</li></ul>Subject: <input type="text" name="subject" maxlength="100" /></li>
|
||||
<li>Message: <input type="text" name="message" value="Hi there" /></li>
|
||||
<li><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul>Sender: <input type="text" name="sender" value="invalid e-mail address" /></li>
|
||||
<li><ul class="errorlist"><li>Enter a valid email address.</li></ul>Sender: <input type="text" name="sender" value="invalid email address" /></li>
|
||||
<li>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></li>
|
||||
>>> print f.as_p()
|
||||
<p><ul class="errorlist"><li>This field is required.</li></ul></p>
|
||||
<p>Subject: <input type="text" name="subject" maxlength="100" /></p>
|
||||
<p>Message: <input type="text" name="message" value="Hi there" /></p>
|
||||
<p><ul class="errorlist"><li>Enter a valid e-mail address.</li></ul></p>
|
||||
<p>Sender: <input type="text" name="sender" value="invalid e-mail address" /></p>
|
||||
<p><ul class="errorlist"><li>Enter a valid email address.</li></ul></p>
|
||||
<p>Sender: <input type="text" name="sender" value="invalid email address" /></p>
|
||||
<p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
|
||||
|
||||
Customizing the error list format
|
||||
|
|
@ -571,8 +571,8 @@ pass that in at construction time::
|
|||
<div class="errorlist"><div class="error">This field is required.</div></div>
|
||||
<p>Subject: <input type="text" name="subject" maxlength="100" /></p>
|
||||
<p>Message: <input type="text" name="message" value="Hi there" /></p>
|
||||
<div class="errorlist"><div class="error">Enter a valid e-mail address.</div></div>
|
||||
<p>Sender: <input type="text" name="sender" value="invalid e-mail address" /></p>
|
||||
<div class="errorlist"><div class="error">Enter a valid email address.</div></div>
|
||||
<p>Sender: <input type="text" name="sender" value="invalid email address" /></p>
|
||||
<p>Cc myself: <input checked="checked" type="checkbox" name="cc_myself" /></p>
|
||||
|
||||
More granular output
|
||||
|
|
|
|||
|
|
@ -27,10 +27,10 @@ exception or returns the clean value::
|
|||
u'foo@example.com'
|
||||
>>> f.clean(u'foo@example.com')
|
||||
u'foo@example.com'
|
||||
>>> f.clean('invalid e-mail address')
|
||||
>>> f.clean('invalid email address')
|
||||
Traceback (most recent call last):
|
||||
...
|
||||
ValidationError: [u'Enter a valid e-mail address.']
|
||||
ValidationError: [u'Enter a valid email address.']
|
||||
|
||||
Core field arguments
|
||||
--------------------
|
||||
|
|
@ -208,23 +208,23 @@ fields. We've specified ``auto_id=False`` to simplify the output::
|
|||
>>> class HelpTextContactForm(forms.Form):
|
||||
... subject = forms.CharField(max_length=100, help_text='100 characters max.')
|
||||
... message = forms.CharField()
|
||||
... sender = forms.EmailField(help_text='A valid e-mail address, please.')
|
||||
... sender = forms.EmailField(help_text='A valid email address, please.')
|
||||
... cc_myself = forms.BooleanField(required=False)
|
||||
>>> f = HelpTextContactForm(auto_id=False)
|
||||
>>> print f.as_table()
|
||||
<tr><th>Subject:</th><td><input type="text" name="subject" maxlength="100" /><br /><span class="helptext">100 characters max.</span></td></tr>
|
||||
<tr><th>Message:</th><td><input type="text" name="message" /></td></tr>
|
||||
<tr><th>Sender:</th><td><input type="text" name="sender" /><br />A valid e-mail address, please.</td></tr>
|
||||
<tr><th>Sender:</th><td><input type="text" name="sender" /><br />A valid email address, please.</td></tr>
|
||||
<tr><th>Cc myself:</th><td><input type="checkbox" name="cc_myself" /></td></tr>
|
||||
>>> print f.as_ul()
|
||||
<li>Subject: <input type="text" name="subject" maxlength="100" /> <span class="helptext">100 characters max.</span></li>
|
||||
<li>Message: <input type="text" name="message" /></li>
|
||||
<li>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</li>
|
||||
<li>Sender: <input type="text" name="sender" /> A valid email address, please.</li>
|
||||
<li>Cc myself: <input type="checkbox" name="cc_myself" /></li>
|
||||
>>> print f.as_p()
|
||||
<p>Subject: <input type="text" name="subject" maxlength="100" /> <span class="helptext">100 characters max.</span></p>
|
||||
<p>Message: <input type="text" name="message" /></p>
|
||||
<p>Sender: <input type="text" name="sender" /> A valid e-mail address, please.</p>
|
||||
<p>Sender: <input type="text" name="sender" /> A valid email address, please.</p>
|
||||
<p>Cc myself: <input type="checkbox" name="cc_myself" /></p>
|
||||
|
||||
``error_messages``
|
||||
|
|
@ -481,7 +481,7 @@ Takes four optional arguments:
|
|||
* Default widget: ``TextInput``
|
||||
* Empty value: ``''`` (an empty string)
|
||||
* Normalizes to: A Unicode object.
|
||||
* Validates that the given value is a valid e-mail address, using a
|
||||
* Validates that the given value is a valid email address, using a
|
||||
moderately complex regular expression.
|
||||
* Error message keys: ``required``, ``invalid``
|
||||
|
||||
|
|
@ -490,7 +490,7 @@ If provided, these arguments ensure that the string is at most or at least the
|
|||
given length.
|
||||
|
||||
.. versionchanged:: 1.2
|
||||
The EmailField previously did not recognize e-mail addresses as valid that
|
||||
The EmailField previously did not recognize email addresses as valid that
|
||||
contained an IDN (Internationalized Domain Name; a domain containing
|
||||
unicode characters) domain part. This has now been corrected.
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ overridden:
|
|||
* The Form subclass's ``clean()`` method. This method can perform
|
||||
any validation that requires access to multiple fields from the form at
|
||||
once. This is where you might put in things to check that if field ``A``
|
||||
is supplied, field ``B`` must contain a valid e-mail address and the
|
||||
is supplied, field ``B`` must contain a valid email address and the
|
||||
like. The data that this method returns is the final ``cleaned_data``
|
||||
attribute for the form, so don't forget to return the full list of
|
||||
cleaned data if you override this method (by default, ``Form.clean()``
|
||||
|
|
@ -187,12 +187,12 @@ a look at Django's ``EmailField``::
|
|||
|
||||
class EmailField(CharField):
|
||||
default_error_messages = {
|
||||
'invalid': _(u'Enter a valid e-mail address.'),
|
||||
'invalid': _(u'Enter a valid email address.'),
|
||||
}
|
||||
default_validators = [validators.validate_email]
|
||||
|
||||
As you can see, ``EmailField`` is just a ``CharField`` with customized error
|
||||
message and a validator that validates e-mail addresses. This can also be done
|
||||
message and a validator that validates email addresses. This can also be done
|
||||
on field definition so::
|
||||
|
||||
email = forms.EmailField()
|
||||
|
|
@ -200,14 +200,14 @@ on field definition so::
|
|||
is equivalent to::
|
||||
|
||||
email = forms.CharField(validators=[validators.validate_email],
|
||||
error_messages={'invalid': _(u'Enter a valid e-mail address.')})
|
||||
error_messages={'invalid': _(u'Enter a valid email address.')})
|
||||
|
||||
|
||||
Form field default cleaning
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Let's firstly create a custom form field that validates its input is a string
|
||||
containing comma-separated e-mail addresses. The full class looks like this::
|
||||
containing comma-separated email addresses. The full class looks like this::
|
||||
|
||||
from django import forms
|
||||
from django.core.validators import validate_email
|
||||
|
|
|
|||
|
|
@ -469,7 +469,7 @@ The admin represents this as an ``<input type="text">`` (a single-line input).
|
|||
|
||||
.. class:: EmailField([max_length=75, **options])
|
||||
|
||||
A :class:`CharField` that checks that the value is a valid e-mail address.
|
||||
A :class:`CharField` that checks that the value is a valid email address.
|
||||
|
||||
``FileField``
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -66,13 +66,13 @@ ADMINS
|
|||
Default: ``()`` (Empty tuple)
|
||||
|
||||
A tuple that lists people who get code error notifications. When
|
||||
``DEBUG=False`` and a view raises an exception, Django will e-mail these people
|
||||
``DEBUG=False`` and a view raises an exception, Django will email these people
|
||||
with the full exception information. Each member of the tuple should be a tuple
|
||||
of (Full name, e-mail address). Example::
|
||||
of (Full name, email address). Example::
|
||||
|
||||
(('John', 'john@example.com'), ('Mary', 'mary@example.com'))
|
||||
|
||||
Note that Django will e-mail *all* of these people whenever an error happens.
|
||||
Note that Django will email *all* of these people whenever an error happens.
|
||||
See :doc:`/howto/error-reporting` for more information.
|
||||
|
||||
.. setting:: ALLOWED_INCLUDE_ROOTS
|
||||
|
|
@ -756,7 +756,7 @@ DEFAULT_FROM_EMAIL
|
|||
|
||||
Default: ``'webmaster@localhost'``
|
||||
|
||||
Default e-mail address to use for various automated correspondence from the
|
||||
Default email address to use for various automated correspondence from the
|
||||
site manager(s).
|
||||
|
||||
.. setting:: DEFAULT_INDEX_TABLESPACE
|
||||
|
|
@ -821,7 +821,7 @@ EMAIL_HOST
|
|||
|
||||
Default: ``'localhost'``
|
||||
|
||||
The host to use for sending e-mail.
|
||||
The host to use for sending email.
|
||||
|
||||
See also ``EMAIL_PORT``.
|
||||
|
||||
|
|
@ -867,7 +867,7 @@ EMAIL_SUBJECT_PREFIX
|
|||
|
||||
Default: ``'[Django] '``
|
||||
|
||||
Subject-line prefix for e-mail messages sent with ``django.core.mail.mail_admins``
|
||||
Subject-line prefix for email messages sent with ``django.core.mail.mail_admins``
|
||||
or ``django.core.mail.mail_managers``. You'll probably want to include the
|
||||
trailing space.
|
||||
|
||||
|
|
@ -1028,7 +1028,7 @@ IGNORABLE_404_ENDS
|
|||
|
||||
Default: ``('mail.pl', 'mailform.pl', 'mail.cgi', 'mailform.cgi', 'favicon.ico', '.php')``
|
||||
|
||||
See also ``IGNORABLE_404_STARTS`` and ``Error reporting via e-mail``.
|
||||
See also ``IGNORABLE_404_STARTS`` and ``Error reporting via email``.
|
||||
|
||||
.. setting:: IGNORABLE_404_STARTS
|
||||
|
||||
|
|
@ -1038,7 +1038,7 @@ IGNORABLE_404_STARTS
|
|||
Default: ``('/cgi-bin/', '/_vti_bin', '/_vti_inf')``
|
||||
|
||||
A tuple of strings that specify beginnings of URLs that should be ignored by
|
||||
the 404 e-mailer. See ``SEND_BROKEN_LINK_EMAILS``, ``IGNORABLE_404_ENDS`` and
|
||||
the 404 emailer. See ``SEND_BROKEN_LINK_EMAILS``, ``IGNORABLE_404_ENDS`` and
|
||||
the :doc:`/howto/error-reporting`.
|
||||
|
||||
.. setting:: INSTALLED_APPS
|
||||
|
|
@ -1433,7 +1433,7 @@ SEND_BROKEN_LINK_EMAILS
|
|||
|
||||
Default: ``False``
|
||||
|
||||
Whether to send an e-mail to the ``MANAGERS`` each time somebody visits a
|
||||
Whether to send an email to the ``MANAGERS`` each time somebody visits a
|
||||
Django-powered page that is 404ed with a non-empty referer (i.e., a broken
|
||||
link). This is only used if ``CommonMiddleware`` is installed (see
|
||||
:doc:`/topics/http/middleware`. See also ``IGNORABLE_404_STARTS``,
|
||||
|
|
@ -1459,7 +1459,7 @@ SERVER_EMAIL
|
|||
|
||||
Default: ``'root@localhost'``
|
||||
|
||||
The e-mail address that error messages come from, such as those sent to
|
||||
The email address that error messages come from, such as those sent to
|
||||
``ADMINS`` and ``MANAGERS``.
|
||||
|
||||
.. setting:: SESSION_COOKIE_AGE
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ passing them around at will, because ASCII is a subset of UTF-8.
|
|||
Don't be fooled into thinking that if your :setting:`DEFAULT_CHARSET` setting is set
|
||||
to something other than ``'utf-8'`` you can use that other encoding in your
|
||||
bytestrings! :setting:`DEFAULT_CHARSET` only applies to the strings generated as
|
||||
the result of template rendering (and e-mail). Django will always assume UTF-8
|
||||
the result of template rendering (and email). Django will always assume UTF-8
|
||||
encoding for internal bytestrings. The reason for this is that the
|
||||
:setting:`DEFAULT_CHARSET` setting is not actually under your control (if you are the
|
||||
application developer). It's under the control of the person installing and
|
||||
|
|
@ -304,16 +304,16 @@ A couple of tips to remember when writing your own template tags and filters:
|
|||
translation objects into strings. It's easier to work solely with Unicode
|
||||
strings at that point.
|
||||
|
||||
E-mail
|
||||
Email
|
||||
======
|
||||
|
||||
Django's e-mail framework (in ``django.core.mail``) supports Unicode
|
||||
Django's email framework (in ``django.core.mail``) supports Unicode
|
||||
transparently. You can use Unicode data in the message bodies and any headers.
|
||||
However, you're still obligated to respect the requirements of the e-mail
|
||||
specifications, so, for example, e-mail addresses should use only ASCII
|
||||
However, you're still obligated to respect the requirements of the email
|
||||
specifications, so, for example, email addresses should use only ASCII
|
||||
characters.
|
||||
|
||||
The following code example demonstrates that everything except e-mail addresses
|
||||
The following code example demonstrates that everything except email addresses
|
||||
can be non-ASCII::
|
||||
|
||||
from django.core.mail import EmailMessage
|
||||
|
|
|
|||
|
|
@ -106,7 +106,7 @@ to, or in lieu of custom ``field.clean()`` methods.
|
|||
.. data:: validate_email
|
||||
|
||||
A :class:`RegexValidator` instance that ensures a value looks like an
|
||||
e-mail address.
|
||||
email address.
|
||||
|
||||
``validate_slug``
|
||||
-----------------
|
||||
|
|
|
|||
|
|
@ -202,7 +202,7 @@ deprecated, as described in the :ref:`upgrading notes <ref-csrf-upgrading-notes>
|
|||
------------------
|
||||
|
||||
The ``SMTPConnection`` class has been deprecated in favor of a generic
|
||||
E-mail backend API. Old code that explicitly instantiated an instance
|
||||
Email backend API. Old code that explicitly instantiated an instance
|
||||
of an SMTPConnection::
|
||||
|
||||
from django.core.mail import SMTPConnection
|
||||
|
|
@ -211,7 +211,7 @@ of an SMTPConnection::
|
|||
connection.send_messages(messages)
|
||||
|
||||
should now call :meth:`~django.core.mail.get_connection()` to
|
||||
instantiate a generic e-mail connection::
|
||||
instantiate a generic email connection::
|
||||
|
||||
from django.core.mail import get_connection
|
||||
connection = get_connection()
|
||||
|
|
@ -220,7 +220,7 @@ instantiate a generic e-mail connection::
|
|||
|
||||
Depending on the value of the :setting:`EMAIL_BACKEND` setting, this
|
||||
may not return an SMTP connection. If you explicitly require an SMTP
|
||||
connection with which to send e-mail, you can explicitly request an
|
||||
connection with which to send email, you can explicitly request an
|
||||
SMTP connection::
|
||||
|
||||
from django.core.mail import get_connection
|
||||
|
|
@ -385,23 +385,23 @@ malicious site in their browser. A related type of attack, 'login
|
|||
CSRF', where an attacking site tricks a user's browser into logging
|
||||
into a site with someone else's credentials, is also covered.
|
||||
|
||||
E-mail Backends
|
||||
Email Backends
|
||||
---------------
|
||||
|
||||
You can now :ref:`configure the way that Django sends e-mail
|
||||
<topic-email-backends>`. Instead of using SMTP to send all e-mail, you
|
||||
can now choose a configurable e-mail backend to send messages. If your
|
||||
You can now :ref:`configure the way that Django sends email
|
||||
<topic-email-backends>`. Instead of using SMTP to send all email, you
|
||||
can now choose a configurable email backend to send messages. If your
|
||||
hosting provider uses a sandbox or some other non-SMTP technique for
|
||||
sending mail, you can now construct an e-mail backend that will allow
|
||||
sending mail, you can now construct an email backend that will allow
|
||||
Django's standard :doc:`mail sending methods</topics/email>` to use
|
||||
those facilities.
|
||||
|
||||
This also makes it easier to debug mail sending - Django ships with
|
||||
backend implementations that allow you to send e-mail to a
|
||||
backend implementations that allow you to send email to a
|
||||
:ref:`file<topic-email-file-backend>`, to the
|
||||
:ref:`console<topic-email-console-backend>`, or to
|
||||
:ref:`memory<topic-email-memory-backend>` - you can even configure all
|
||||
e-mail to be :ref:`thrown away<topic-email-dummy-backend>`.
|
||||
email to be :ref:`thrown away<topic-email-dummy-backend>`.
|
||||
|
||||
Messages Framework
|
||||
------------------
|
||||
|
|
|
|||
|
|
@ -30,7 +30,7 @@ Django 1.2 introduces several large, important new features, including:
|
|||
* Hooks for `object-level permissions`_, `permissions for anonymous users`_,
|
||||
and `more flexible username requirements`_.
|
||||
|
||||
* Customization of e-mail sending via `e-mail backends`_.
|
||||
* Customization of email sending via `email backends`_.
|
||||
|
||||
* New :ref:`"smart" if template tag <new-in-1.2-smart-if>` which supports
|
||||
comparison operators.
|
||||
|
|
@ -184,23 +184,23 @@ The built-in :class:`~django.contrib.auth.models.User` model's
|
|||
:attr:`~django.contrib.auth.models.User.username` field now allows a wider range
|
||||
of characters, including ``@``, ``+``, ``.`` and ``-`` characters.
|
||||
|
||||
E-mail backends
|
||||
Email backends
|
||||
---------------
|
||||
|
||||
You can now :ref:`configure the way that Django sends e-mail
|
||||
<topic-email-backends>`. Instead of using SMTP to send all e-mail, you
|
||||
can now choose a configurable e-mail backend to send messages. If your
|
||||
You can now :ref:`configure the way that Django sends email
|
||||
<topic-email-backends>`. Instead of using SMTP to send all email, you
|
||||
can now choose a configurable email backend to send messages. If your
|
||||
hosting provider uses a sandbox or some other non-SMTP technique for
|
||||
sending mail, you can now construct an e-mail backend that will allow
|
||||
sending mail, you can now construct an email backend that will allow
|
||||
Django's standard :doc:`mail sending methods</topics/email>` to use
|
||||
those facilities.
|
||||
|
||||
This also makes it easier to debug mail sending. Django ships with
|
||||
backend implementations that allow you to send e-mail to a
|
||||
backend implementations that allow you to send email to a
|
||||
:ref:`file<topic-email-file-backend>`, to the
|
||||
:ref:`console<topic-email-console-backend>`, or to
|
||||
:ref:`memory<topic-email-memory-backend>`. You can even configure all
|
||||
e-mail to be :ref:`thrown away<topic-email-dummy-backend>`.
|
||||
email to be :ref:`thrown away<topic-email-dummy-backend>`.
|
||||
|
||||
.. _new-in-1.2-smart-if:
|
||||
|
||||
|
|
@ -868,7 +868,7 @@ imports are deprecated, as described in the :ref:`upgrading notes
|
|||
------------------
|
||||
|
||||
The ``SMTPConnection`` class has been deprecated in favor of a generic
|
||||
e-mail backend API. Old code that explicitly instantiated an instance
|
||||
email backend API. Old code that explicitly instantiated an instance
|
||||
of an SMTPConnection::
|
||||
|
||||
from django.core.mail import SMTPConnection
|
||||
|
|
@ -877,7 +877,7 @@ of an SMTPConnection::
|
|||
connection.send_messages(messages)
|
||||
|
||||
...should now call :meth:`~django.core.mail.get_connection()` to
|
||||
instantiate a generic e-mail connection::
|
||||
instantiate a generic email connection::
|
||||
|
||||
from django.core.mail import get_connection
|
||||
connection = get_connection()
|
||||
|
|
@ -886,7 +886,7 @@ instantiate a generic e-mail connection::
|
|||
|
||||
Depending on the value of the :setting:`EMAIL_BACKEND` setting, this
|
||||
may not return an SMTP connection. If you explicitly require an SMTP
|
||||
connection with which to send e-mail, you can explicitly request an
|
||||
connection with which to send email, you can explicitly request an
|
||||
SMTP connection::
|
||||
|
||||
from django.core.mail import get_connection
|
||||
|
|
|
|||
|
|
@ -84,7 +84,7 @@ Fields
|
|||
|
||||
.. attribute:: models.User.email
|
||||
|
||||
Optional. E-mail address.
|
||||
Optional. Email address.
|
||||
|
||||
.. attribute:: models.User.password
|
||||
|
||||
|
|
@ -263,7 +263,7 @@ Methods
|
|||
|
||||
.. method:: models.User.email_user(subject, message, from_email=None)
|
||||
|
||||
Sends an e-mail to the user. If
|
||||
Sends an email to the user. If
|
||||
:attr:`~django.contrib.auth.models.User.from_email` is ``None``, Django
|
||||
uses the :setting:`DEFAULT_FROM_EMAIL`.
|
||||
|
||||
|
|
@ -948,7 +948,7 @@ includes a few other useful built-in views located in
|
|||
|
||||
Allows a user to reset their password by generating a one-time use link
|
||||
that can be used to reset the password, and sending that link to the
|
||||
user's registered e-mail address.
|
||||
user's registered email address.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
The ``from_email`` argument was added.
|
||||
|
|
@ -960,7 +960,7 @@ includes a few other useful built-in views located in
|
|||
:file:`registration/password_reset_form.html` if not supplied.
|
||||
|
||||
* ``email_template_name``: The full name of a template to use for
|
||||
generating the e-mail with the new password. This will default to
|
||||
generating the email with the new password. This will default to
|
||||
:file:`registration/password_reset_email.html` if not supplied.
|
||||
|
||||
* ``password_reset_form``: Form that will be used to set the password.
|
||||
|
|
@ -973,7 +973,7 @@ includes a few other useful built-in views located in
|
|||
* ``post_reset_redirect``: The URL to redirect to after a successful
|
||||
password change.
|
||||
|
||||
* ``from_email``: A valid e-mail address. By default Django uses
|
||||
* ``from_email``: A valid email address. By default Django uses
|
||||
the :setting:`DEFAULT_FROM_EMAIL`.
|
||||
|
||||
**Template context:**
|
||||
|
|
@ -1061,7 +1061,7 @@ provides several built-in forms located in :mod:`django.contrib.auth.forms`:
|
|||
|
||||
.. class:: PasswordResetForm
|
||||
|
||||
A form for generating and e-mailing a one-time use link to reset a
|
||||
A form for generating and emailing a one-time use link to reset a
|
||||
user's password.
|
||||
|
||||
.. class:: SetPasswordForm
|
||||
|
|
@ -1384,7 +1384,7 @@ example, if the group ``Site editors`` has the permission
|
|||
Beyond permissions, groups are a convenient way to categorize users to give
|
||||
them some label, or extended functionality. For example, you could create a
|
||||
group ``'Special users'``, and you could write code that could, say, give them
|
||||
access to a members-only portion of your site, or send them members-only e-mail
|
||||
access to a members-only portion of your site, or send them members-only email
|
||||
messages.
|
||||
|
||||
Messages
|
||||
|
|
|
|||
|
|
@ -941,7 +941,7 @@ Many Web pages' contents differ based on authentication and a host of other
|
|||
variables, and cache systems that blindly save pages based purely on URLs could
|
||||
expose incorrect or sensitive data to subsequent visitors to those pages.
|
||||
|
||||
For example, say you operate a Web e-mail system, and the contents of the
|
||||
For example, say you operate a Web email system, and the contents of the
|
||||
"inbox" page obviously depend on which user is logged in. If an ISP blindly
|
||||
cached your site, then the first user who logged in through that ISP would have
|
||||
his user-specific inbox page cached for subsequent visitors to the site. That's
|
||||
|
|
|
|||
|
|
@ -1,14 +1,14 @@
|
|||
==============
|
||||
Sending e-mail
|
||||
Sending email
|
||||
==============
|
||||
|
||||
.. module:: django.core.mail
|
||||
:synopsis: Helpers to easily send e-mail.
|
||||
:synopsis: Helpers to easily send email.
|
||||
|
||||
Although Python makes sending e-mail relatively easy via the `smtplib
|
||||
Although Python makes sending email relatively easy via the `smtplib
|
||||
library`_, Django provides a couple of light wrappers over it. These wrappers
|
||||
are provided to make sending e-mail extra quick, to make it easy to test
|
||||
e-mail sending during development, and to provide support for platforms that
|
||||
are provided to make sending email extra quick, to make it easy to test
|
||||
email sending during development, and to provide support for platforms that
|
||||
can't use SMTP.
|
||||
|
||||
The code lives in the ``django.core.mail`` module.
|
||||
|
|
@ -33,7 +33,7 @@ set, are used to authenticate to the SMTP server, and the
|
|||
|
||||
.. note::
|
||||
|
||||
The character set of e-mail sent with ``django.core.mail`` will be set to
|
||||
The character set of email sent with ``django.core.mail`` will be set to
|
||||
the value of your :setting:`DEFAULT_CHARSET` setting.
|
||||
|
||||
send_mail()
|
||||
|
|
@ -41,7 +41,7 @@ send_mail()
|
|||
|
||||
.. function:: send_mail(subject, message, from_email, recipient_list, fail_silently=False, auth_user=None, auth_password=None, connection=None)
|
||||
|
||||
The simplest way to send e-mail is using
|
||||
The simplest way to send email is using
|
||||
``django.core.mail.send_mail()``.
|
||||
|
||||
The ``subject``, ``message``, ``from_email`` and ``recipient_list`` parameters
|
||||
|
|
@ -50,9 +50,9 @@ are required.
|
|||
* ``subject``: A string.
|
||||
* ``message``: A string.
|
||||
* ``from_email``: A string.
|
||||
* ``recipient_list``: A list of strings, each an e-mail address. Each
|
||||
* ``recipient_list``: A list of strings, each an email address. Each
|
||||
member of ``recipient_list`` will see the other recipients in the "To:"
|
||||
field of the e-mail message.
|
||||
field of the email message.
|
||||
* ``fail_silently``: A boolean. If it's ``False``, ``send_mail`` will raise
|
||||
an ``smtplib.SMTPException``. See the `smtplib docs`_ for a list of
|
||||
possible exceptions, all of which are subclasses of ``SMTPException``.
|
||||
|
|
@ -62,9 +62,9 @@ are required.
|
|||
* ``auth_password``: The optional password to use to authenticate to the
|
||||
SMTP server. If this isn't provided, Django will use the value of the
|
||||
:setting:`EMAIL_HOST_PASSWORD` setting.
|
||||
* ``connection``: The optional e-mail backend to use to send the mail.
|
||||
* ``connection``: The optional email backend to use to send the mail.
|
||||
If unspecified, an instance of the default backend will be used.
|
||||
See the documentation on :ref:`E-mail backends <topic-email-backends>`
|
||||
See the documentation on :ref:`Email backends <topic-email-backends>`
|
||||
for more details.
|
||||
|
||||
.. _smtplib docs: http://docs.python.org/library/smtplib.html
|
||||
|
|
@ -74,7 +74,7 @@ send_mass_mail()
|
|||
|
||||
.. function:: send_mass_mail(datatuple, fail_silently=False, auth_user=None, auth_password=None, connection=None)
|
||||
|
||||
``django.core.mail.send_mass_mail()`` is intended to handle mass e-mailing.
|
||||
``django.core.mail.send_mass_mail()`` is intended to handle mass emailing.
|
||||
|
||||
``datatuple`` is a tuple in which each element is in this format::
|
||||
|
||||
|
|
@ -83,9 +83,9 @@ send_mass_mail()
|
|||
``fail_silently``, ``auth_user`` and ``auth_password`` have the same functions
|
||||
as in :meth:`~django.core.mail.send_mail()`.
|
||||
|
||||
Each separate element of ``datatuple`` results in a separate e-mail message.
|
||||
Each separate element of ``datatuple`` results in a separate email message.
|
||||
As in :meth:`~django.core.mail.send_mail()`, recipients in the same
|
||||
``recipient_list`` will all see the other addresses in the e-mail messages'
|
||||
``recipient_list`` will all see the other addresses in the email messages'
|
||||
"To:" field.
|
||||
|
||||
For example, the following code would send two different messages to
|
||||
|
|
@ -111,21 +111,21 @@ mail_admins()
|
|||
|
||||
.. function:: mail_admins(subject, message, fail_silently=False, connection=None, html_message=None)
|
||||
|
||||
``django.core.mail.mail_admins()`` is a shortcut for sending an e-mail to the
|
||||
``django.core.mail.mail_admins()`` is a shortcut for sending an email to the
|
||||
site admins, as defined in the :setting:`ADMINS` setting.
|
||||
|
||||
``mail_admins()`` prefixes the subject with the value of the
|
||||
:setting:`EMAIL_SUBJECT_PREFIX` setting, which is ``"[Django] "`` by default.
|
||||
|
||||
The "From:" header of the e-mail will be the value of the
|
||||
The "From:" header of the email will be the value of the
|
||||
:setting:`SERVER_EMAIL` setting.
|
||||
|
||||
This method exists for convenience and readability.
|
||||
|
||||
.. versionchanged:: 1.3
|
||||
|
||||
If ``html_message`` is provided, the resulting e-mail will be a
|
||||
multipart/alternative e-mail with ``message`` as the "text/plain"
|
||||
If ``html_message`` is provided, the resulting email will be a
|
||||
multipart/alternative email with ``message`` as the "text/plain"
|
||||
content type and ``html_message`` as the "text/html" content type.
|
||||
|
||||
mail_managers()
|
||||
|
|
@ -134,20 +134,20 @@ mail_managers()
|
|||
.. function:: mail_managers(subject, message, fail_silently=False, connection=None, html_message=None)
|
||||
|
||||
``django.core.mail.mail_managers()`` is just like ``mail_admins()``, except it
|
||||
sends an e-mail to the site managers, as defined in the :setting:`MANAGERS`
|
||||
sends an email to the site managers, as defined in the :setting:`MANAGERS`
|
||||
setting.
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
This sends a single e-mail to john@example.com and jane@example.com, with them
|
||||
This sends a single email to john@example.com and jane@example.com, with them
|
||||
both appearing in the "To:"::
|
||||
|
||||
send_mail('Subject', 'Message.', 'from@example.com',
|
||||
['john@example.com', 'jane@example.com'])
|
||||
|
||||
This sends a message to john@example.com and jane@example.com, with them both
|
||||
receiving a separate e-mail::
|
||||
receiving a separate email::
|
||||
|
||||
datatuple = (
|
||||
('Subject', 'Message.', 'from@example.com', ['john@example.com']),
|
||||
|
|
@ -159,19 +159,19 @@ Preventing header injection
|
|||
===========================
|
||||
|
||||
`Header injection`_ is a security exploit in which an attacker inserts extra
|
||||
e-mail headers to control the "To:" and "From:" in e-mail messages that your
|
||||
email headers to control the "To:" and "From:" in email messages that your
|
||||
scripts generate.
|
||||
|
||||
The Django e-mail functions outlined above all protect against header injection
|
||||
The Django email functions outlined above all protect against header injection
|
||||
by forbidding newlines in header values. If any ``subject``, ``from_email`` or
|
||||
``recipient_list`` contains a newline (in either Unix, Windows or Mac style),
|
||||
the e-mail function (e.g. :meth:`~django.core.mail.send_mail()`) will raise
|
||||
the email function (e.g. :meth:`~django.core.mail.send_mail()`) will raise
|
||||
``django.core.mail.BadHeaderError`` (a subclass of ``ValueError``) and, hence,
|
||||
will not send the e-mail. It's your responsibility to validate all data before
|
||||
passing it to the e-mail functions.
|
||||
will not send the email. It's your responsibility to validate all data before
|
||||
passing it to the email functions.
|
||||
|
||||
If a ``message`` contains headers at the start of the string, the headers will
|
||||
simply be printed as the first bit of the e-mail message.
|
||||
simply be printed as the first bit of the email message.
|
||||
|
||||
Here's an example view that takes a ``subject``, ``message`` and ``from_email``
|
||||
from the request's POST data, sends that to admin@example.com and redirects to
|
||||
|
|
@ -208,24 +208,24 @@ wrappers that make use of the :class:`~django.core.mail.EmailMessage` class.
|
|||
Not all features of the :class:`~django.core.mail.EmailMessage` class are
|
||||
available through the :meth:`~django.core.mail.send_mail()` and related
|
||||
wrapper functions. If you wish to use advanced features, such as BCC'ed
|
||||
recipients, file attachments, or multi-part e-mail, you'll need to create
|
||||
recipients, file attachments, or multi-part email, you'll need to create
|
||||
:class:`~django.core.mail.EmailMessage` instances directly.
|
||||
|
||||
.. note::
|
||||
This is a design feature. :meth:`~django.core.mail.send_mail()` and
|
||||
related functions were originally the only interface Django provided.
|
||||
However, the list of parameters they accepted was slowly growing over
|
||||
time. It made sense to move to a more object-oriented design for e-mail
|
||||
time. It made sense to move to a more object-oriented design for email
|
||||
messages and retain the original functions only for backwards
|
||||
compatibility.
|
||||
|
||||
:class:`~django.core.mail.EmailMessage` is responsible for creating the e-mail
|
||||
message itself. The :ref:`e-mail backend <topic-email-backends>` is then
|
||||
responsible for sending the e-mail.
|
||||
:class:`~django.core.mail.EmailMessage` is responsible for creating the email
|
||||
message itself. The :ref:`email backend <topic-email-backends>` is then
|
||||
responsible for sending the email.
|
||||
|
||||
For convenience, :class:`~django.core.mail.EmailMessage` provides a simple
|
||||
``send()`` method for sending a single e-mail. If you need to send multiple
|
||||
messages, the e-mail backend API :ref:`provides an alternative
|
||||
``send()`` method for sending a single email. If you need to send multiple
|
||||
messages, the email backend API :ref:`provides an alternative
|
||||
<topics-sending-multiple-emails>`.
|
||||
|
||||
EmailMessage Objects
|
||||
|
|
@ -241,7 +241,7 @@ All parameters are optional and can be set at any time prior to calling the
|
|||
.. versionchanged:: 1.3
|
||||
The ``cc`` argument was added.
|
||||
|
||||
* ``subject``: The subject line of the e-mail.
|
||||
* ``subject``: The subject line of the email.
|
||||
|
||||
* ``body``: The body text. This should be a plain text message.
|
||||
|
||||
|
|
@ -252,9 +252,9 @@ All parameters are optional and can be set at any time prior to calling the
|
|||
* ``to``: A list or tuple of recipient addresses.
|
||||
|
||||
* ``bcc``: A list or tuple of addresses used in the "Bcc" header when
|
||||
sending the e-mail.
|
||||
sending the email.
|
||||
|
||||
* ``connection``: An e-mail backend instance. Use this parameter if
|
||||
* ``connection``: An email backend instance. Use this parameter if
|
||||
you want to use the same connection for multiple messages. If omitted, a
|
||||
new connection is created when ``send()`` is called.
|
||||
|
||||
|
|
@ -265,10 +265,10 @@ All parameters are optional and can be set at any time prior to calling the
|
|||
* ``headers``: A dictionary of extra headers to put on the message. The
|
||||
keys are the header name, values are the header values. It's up to the
|
||||
caller to ensure header names and values are in the correct format for
|
||||
an e-mail message.
|
||||
an email message.
|
||||
|
||||
* ``cc``: A list or tuple of recipient addresses used in the "Cc" header
|
||||
when sending the e-mail.
|
||||
when sending the email.
|
||||
|
||||
For example::
|
||||
|
||||
|
|
@ -279,7 +279,7 @@ For example::
|
|||
The class has the following methods:
|
||||
|
||||
* ``send(fail_silently=False)`` sends the message. If a connection was
|
||||
specified when the e-mail was constructed, that connection will be used.
|
||||
specified when the email was constructed, that connection will be used.
|
||||
Otherwise, an instance of the default backend will be instantiated and
|
||||
used. If the keyword argument ``fail_silently`` is ``True``, exceptions
|
||||
raised while sending the message will be quashed.
|
||||
|
|
@ -307,7 +307,7 @@ The class has the following methods:
|
|||
|
||||
* Alternatively, you can pass ``attach()`` three arguments:
|
||||
``filename``, ``content`` and ``mimetype``. ``filename`` is the name
|
||||
of the file attachment as it will appear in the e-mail, ``content`` is
|
||||
of the file attachment as it will appear in the email, ``content`` is
|
||||
the data that will be contained inside the attachment and
|
||||
``mimetype`` is the optional MIME type for the attachment. If you
|
||||
omit ``mimetype``, the MIME content type will be guessed from the
|
||||
|
|
@ -329,12 +329,12 @@ The class has the following methods:
|
|||
Sending alternative content types
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It can be useful to include multiple versions of the content in an e-mail; the
|
||||
It can be useful to include multiple versions of the content in an email; the
|
||||
classic example is to send both text and HTML versions of a message. With
|
||||
Django's e-mail library, you can do this using the ``EmailMultiAlternatives``
|
||||
Django's email library, you can do this using the ``EmailMultiAlternatives``
|
||||
class. This subclass of :class:`~django.core.mail.EmailMessage` has an
|
||||
``attach_alternative()`` method for including extra versions of the message
|
||||
body in the e-mail. All the other methods (including the class initialization)
|
||||
body in the email. All the other methods (including the class initialization)
|
||||
are inherited directly from :class:`~django.core.mail.EmailMessage`.
|
||||
|
||||
To send a text and HTML combination, you could write::
|
||||
|
|
@ -351,7 +351,7 @@ To send a text and HTML combination, you could write::
|
|||
By default, the MIME type of the ``body`` parameter in an
|
||||
:class:`~django.core.mail.EmailMessage` is ``"text/plain"``. It is good
|
||||
practice to leave this alone, because it guarantees that any recipient will be
|
||||
able to read the e-mail, regardless of their mail client. However, if you are
|
||||
able to read the email, regardless of their mail client. However, if you are
|
||||
confident that your recipients can handle an alternative content type, you can
|
||||
use the ``content_subtype`` attribute on the
|
||||
:class:`~django.core.mail.EmailMessage` class to change the main content type.
|
||||
|
|
@ -369,13 +369,13 @@ E-Mail Backends
|
|||
|
||||
.. versionadded:: 1.2
|
||||
|
||||
The actual sending of an e-mail is handled by the e-mail backend.
|
||||
The actual sending of an email is handled by the email backend.
|
||||
|
||||
The e-mail backend class has the following methods:
|
||||
The email backend class has the following methods:
|
||||
|
||||
* ``open()`` instantiates an long-lived e-mail-sending connection.
|
||||
* ``open()`` instantiates an long-lived email-sending connection.
|
||||
|
||||
* ``close()`` closes the current e-mail-sending connection.
|
||||
* ``close()`` closes the current email-sending connection.
|
||||
|
||||
* ``send_messages(email_messages)`` sends a list of
|
||||
:class:`~django.core.mail.EmailMessage` objects. If the connection is
|
||||
|
|
@ -383,38 +383,38 @@ The e-mail backend class has the following methods:
|
|||
connection afterwards. If the connection is already open, it will be
|
||||
left open after mail has been sent.
|
||||
|
||||
Obtaining an instance of an e-mail backend
|
||||
Obtaining an instance of an email backend
|
||||
------------------------------------------
|
||||
|
||||
The :meth:`get_connection` function in ``django.core.mail`` returns an
|
||||
instance of the e-mail backend that you can use.
|
||||
instance of the email backend that you can use.
|
||||
|
||||
.. currentmodule:: django.core.mail
|
||||
|
||||
.. function:: get_connection(backend=None, fail_silently=False, *args, **kwargs)
|
||||
|
||||
By default, a call to ``get_connection()`` will return an instance of the
|
||||
e-mail backend specified in :setting:`EMAIL_BACKEND`. If you specify the
|
||||
email backend specified in :setting:`EMAIL_BACKEND`. If you specify the
|
||||
``backend`` argument, an instance of that backend will be instantiated.
|
||||
|
||||
The ``fail_silently`` argument controls how the backend should handle errors.
|
||||
If ``fail_silently`` is True, exceptions during the e-mail sending process
|
||||
If ``fail_silently`` is True, exceptions during the email sending process
|
||||
will be silently ignored.
|
||||
|
||||
All other arguments are passed directly to the constructor of the
|
||||
e-mail backend.
|
||||
email backend.
|
||||
|
||||
Django ships with several e-mail sending backends. With the exception of the
|
||||
Django ships with several email sending backends. With the exception of the
|
||||
SMTP backend (which is the default), these backends are only useful during
|
||||
testing and development. If you have special e-mail sending requirements, you
|
||||
can :ref:`write your own e-mail backend <topic-custom-email-backend>`.
|
||||
testing and development. If you have special email sending requirements, you
|
||||
can :ref:`write your own email backend <topic-custom-email-backend>`.
|
||||
|
||||
.. _topic-email-smtp-backend:
|
||||
|
||||
SMTP backend
|
||||
~~~~~~~~~~~~
|
||||
|
||||
This is the default backend. E-mail will be sent through a SMTP server.
|
||||
This is the default backend. Email will be sent through a SMTP server.
|
||||
The server address and authentication credentials are set in the
|
||||
:setting:`EMAIL_HOST`, :setting:`EMAIL_PORT`, :setting:`EMAIL_HOST_USER`,
|
||||
:setting:`EMAIL_HOST_PASSWORD` and :setting:`EMAIL_USE_TLS` settings in your
|
||||
|
|
@ -429,8 +429,8 @@ want to specify it explicitly, put the following in your settings::
|
|||
|
||||
Prior to version 1.2, Django provided a
|
||||
:class:`~django.core.mail.SMTPConnection` class. This class provided a way
|
||||
to directly control the use of SMTP to send e-mail. This class has been
|
||||
deprecated in favor of the generic e-mail backend API.
|
||||
to directly control the use of SMTP to send email. This class has been
|
||||
deprecated in favor of the generic email backend API.
|
||||
|
||||
For backwards compatibility :class:`~django.core.mail.SMTPConnection` is
|
||||
still available in ``django.core.mail`` as an alias for the SMTP backend.
|
||||
|
|
@ -441,8 +441,8 @@ want to specify it explicitly, put the following in your settings::
|
|||
Console backend
|
||||
~~~~~~~~~~~~~~~
|
||||
|
||||
Instead of sending out real e-mails the console backend just writes the
|
||||
e-mails that would be send to the standard output. By default, the console
|
||||
Instead of sending out real emails the console backend just writes the
|
||||
emails that would be send to the standard output. By default, the console
|
||||
backend writes to ``stdout``. You can use a different stream-like object by
|
||||
providing the ``stream`` keyword argument when constructing the connection.
|
||||
|
||||
|
|
@ -458,7 +458,7 @@ convenience that can be used during development.
|
|||
File backend
|
||||
~~~~~~~~~~~~
|
||||
|
||||
The file backend writes e-mails to a file. A new file is created for each new
|
||||
The file backend writes emails to a file. A new file is created for each new
|
||||
session that is opened on this backend. The directory to which the files are
|
||||
written is either taken from the :setting:`EMAIL_FILE_PATH` setting or from
|
||||
the ``file_path`` keyword when creating a connection with
|
||||
|
|
@ -505,15 +505,15 @@ convenience that can be used during development.
|
|||
|
||||
.. _topic-custom-email-backend:
|
||||
|
||||
Defining a custom e-mail backend
|
||||
Defining a custom email backend
|
||||
--------------------------------
|
||||
|
||||
If you need to change how e-mails are sent you can write your own e-mail
|
||||
If you need to change how emails are sent you can write your own email
|
||||
backend. The ``EMAIL_BACKEND`` setting in your settings file is then the
|
||||
Python import path for your backend class.
|
||||
|
||||
Custom e-mail backends should subclass ``BaseEmailBackend`` that is located in
|
||||
the ``django.core.mail.backends.base`` module. A custom e-mail backend must
|
||||
Custom email backends should subclass ``BaseEmailBackend`` that is located in
|
||||
the ``django.core.mail.backends.base`` module. A custom email backend must
|
||||
implement the ``send_messages(email_messages)`` method. This method receives a
|
||||
list of :class:`~django.core.mail.EmailMessage` instances and returns the
|
||||
number of successfully delivered messages. If your backend has any concept of
|
||||
|
|
@ -523,15 +523,15 @@ implementation.
|
|||
|
||||
.. _topics-sending-multiple-emails:
|
||||
|
||||
Sending multiple e-mails
|
||||
Sending multiple emails
|
||||
------------------------
|
||||
|
||||
Establishing and closing an SMTP connection (or any other network connection,
|
||||
for that matter) is an expensive process. If you have a lot of e-mails to send,
|
||||
for that matter) is an expensive process. If you have a lot of emails to send,
|
||||
it makes sense to reuse an SMTP connection, rather than creating and
|
||||
destroying a connection every time you want to send an e-mail.
|
||||
destroying a connection every time you want to send an email.
|
||||
|
||||
There are two ways you tell an e-mail backend to reuse a connection.
|
||||
There are two ways you tell an email backend to reuse a connection.
|
||||
|
||||
Firstly, you can use the ``send_messages()`` method. ``send_messages()`` takes
|
||||
a list of :class:`~django.core.mail.EmailMessage` instances (or subclasses),
|
||||
|
|
@ -539,11 +539,11 @@ and sends them all using a single connection.
|
|||
|
||||
For example, if you have a function called ``get_notification_email()`` that
|
||||
returns a list of :class:`~django.core.mail.EmailMessage` objects representing
|
||||
some periodic e-mail you wish to send out, you could send these e-mails using
|
||||
some periodic email you wish to send out, you could send these emails using
|
||||
a single call to send_messages::
|
||||
|
||||
from django.core import mail
|
||||
connection = mail.get_connection() # Use default e-mail connection
|
||||
connection = mail.get_connection() # Use default email connection
|
||||
messages = get_notification_email()
|
||||
connection.send_messages(messages)
|
||||
|
||||
|
|
@ -551,7 +551,7 @@ In this example, the call to ``send_messages()`` opens a connection on the
|
|||
backend, sends the list of messages, and then closes the connection again.
|
||||
|
||||
The second approach is to use the ``open()`` and ``close()`` methods on the
|
||||
e-mail backend to manually control the connection. ``send_messages()`` will not
|
||||
email backend to manually control the connection. ``send_messages()`` will not
|
||||
manually open or close the connection if it is already open, so if you
|
||||
manually open the connection, you can control when it is closed. For example::
|
||||
|
||||
|
|
@ -561,10 +561,10 @@ manually open the connection, you can control when it is closed. For example::
|
|||
# Manually open the connection
|
||||
connection.open()
|
||||
|
||||
# Construct an e-mail message that uses the connection
|
||||
# Construct an email message that uses the connection
|
||||
email1 = mail.EmailMessage('Hello', 'Body goes here', 'from@example.com',
|
||||
['to1@example.com'], connection=connection)
|
||||
email1.send() # Send the e-mail
|
||||
email1.send() # Send the email
|
||||
|
||||
# Construct two more messages
|
||||
email2 = mail.EmailMessage('Hello', 'Body goes here', 'from@example.com',
|
||||
|
|
@ -572,42 +572,42 @@ manually open the connection, you can control when it is closed. For example::
|
|||
email3 = mail.EmailMessage('Hello', 'Body goes here', 'from@example.com',
|
||||
['to3@example.com'])
|
||||
|
||||
# Send the two e-mails in a single call -
|
||||
# Send the two emails in a single call -
|
||||
connection.send_messages([email2, email3])
|
||||
# The connection was already open so send_messages() doesn't close it.
|
||||
# We need to manually close the connection.
|
||||
connection.close()
|
||||
|
||||
|
||||
Testing e-mail sending
|
||||
Testing email sending
|
||||
======================
|
||||
|
||||
There are times when you do not want Django to send e-mails at
|
||||
There are times when you do not want Django to send emails at
|
||||
all. For example, while developing a Web site, you probably don't want
|
||||
to send out thousands of e-mails -- but you may want to validate that
|
||||
e-mails will be sent to the right people under the right conditions,
|
||||
and that those e-mails will contain the correct content.
|
||||
to send out thousands of emails -- but you may want to validate that
|
||||
emails will be sent to the right people under the right conditions,
|
||||
and that those emails will contain the correct content.
|
||||
|
||||
The easiest way to test your project's use of e-mail is to use the ``console``
|
||||
e-mail backend. This backend redirects all e-mail to stdout, allowing you to
|
||||
The easiest way to test your project's use of email is to use the ``console``
|
||||
email backend. This backend redirects all email to stdout, allowing you to
|
||||
inspect the content of mail.
|
||||
|
||||
The ``file`` e-mail backend can also be useful during development -- this backend
|
||||
The ``file`` email backend can also be useful during development -- this backend
|
||||
dumps the contents of every SMTP connection to a file that can be inspected
|
||||
at your leisure.
|
||||
|
||||
Another approach is to use a "dumb" SMTP server that receives the e-mails
|
||||
Another approach is to use a "dumb" SMTP server that receives the emails
|
||||
locally and displays them to the terminal, but does not actually send
|
||||
anything. Python has a built-in way to accomplish this with a single command::
|
||||
|
||||
python -m smtpd -n -c DebuggingServer localhost:1025
|
||||
|
||||
This command will start a simple SMTP server listening on port 1025 of
|
||||
localhost. This server simply prints to standard output all e-mail headers and
|
||||
the e-mail body. You then only need to set the :setting:`EMAIL_HOST` and
|
||||
localhost. This server simply prints to standard output all email headers and
|
||||
the email body. You then only need to set the :setting:`EMAIL_HOST` and
|
||||
:setting:`EMAIL_PORT` accordingly, and you are set.
|
||||
|
||||
For a more detailed discussion of testing and processing of e-mails locally,
|
||||
For a more detailed discussion of testing and processing of emails locally,
|
||||
see the Python documentation on the `SMTP Server`_.
|
||||
|
||||
.. _SMTP Server: http://docs.python.org/library/smtpd.html
|
||||
|
|
@ -619,7 +619,7 @@ SMTPConnection
|
|||
|
||||
.. deprecated:: 1.2
|
||||
|
||||
The ``SMTPConnection`` class has been deprecated in favor of the generic e-mail
|
||||
The ``SMTPConnection`` class has been deprecated in favor of the generic email
|
||||
backend API.
|
||||
|
||||
For backwards compatibility ``SMTPConnection`` is still available in
|
||||
|
|
|
|||
|
|
@ -36,7 +36,7 @@ The library deals with these concepts:
|
|||
|
||||
Field
|
||||
A class that is responsible for doing validation, e.g.
|
||||
an ``EmailField`` that makes sure its data is a valid e-mail address.
|
||||
an ``EmailField`` that makes sure its data is a valid email address.
|
||||
|
||||
Form
|
||||
A collection of fields that knows how to validate itself and
|
||||
|
|
@ -163,7 +163,7 @@ Extending the above example, here's how the form data could be processed:
|
|||
send_mail(subject, message, sender, recipients)
|
||||
return HttpResponseRedirect('/thanks/') # Redirect after POST
|
||||
|
||||
For more on sending e-mail from Django, see :doc:`/topics/email`.
|
||||
For more on sending email from Django, see :doc:`/topics/email`.
|
||||
|
||||
Displaying a form using a template
|
||||
----------------------------------
|
||||
|
|
@ -224,7 +224,7 @@ above example::
|
|||
{{ form.non_field_errors }}
|
||||
<div class="fieldWrapper">
|
||||
{{ form.subject.errors }}
|
||||
<label for="id_subject">E-mail subject:</label>
|
||||
<label for="id_subject">Email subject:</label>
|
||||
{{ form.subject }}
|
||||
</div>
|
||||
<div class="fieldWrapper">
|
||||
|
|
@ -288,11 +288,11 @@ Within this loop, ``{{ field }}`` is an instance of :class:`BoundField`.
|
|||
templates:
|
||||
|
||||
``{{ field.label }}``
|
||||
The label of the field, e.g. ``E-mail address``.
|
||||
The label of the field, e.g. ``Email address``.
|
||||
|
||||
``{{ field.label_tag }}``
|
||||
The field's label wrapped in the appropriate HTML ``<label>`` tag,
|
||||
e.g. ``<label for="id_email">E-mail address</label>``
|
||||
e.g. ``<label for="id_email">Email address</label>``
|
||||
|
||||
``{{ field.html_name }}``
|
||||
The name of the field that will be used in the input element's name
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ This logging configuration does the following things:
|
|||
message to stdout. This handler uses the `simple` output
|
||||
format.
|
||||
|
||||
* ``mail_admins``, an AdminEmailHandler, which will e-mail any
|
||||
* ``mail_admins``, an AdminEmailHandler, which will email any
|
||||
``ERROR`` level message to the site admins. This handler uses
|
||||
the ``special`` filter.
|
||||
|
||||
|
|
@ -347,7 +347,7 @@ This logging configuration does the following things:
|
|||
handlers -- the ``console``, and ``mail_admins``. This
|
||||
means that all ``INFO`` level messages (or higher) will be
|
||||
printed to the console; ``ERROR`` and ``CRITICAL``
|
||||
messages will also be output via e-mail.
|
||||
messages will also be output via email.
|
||||
|
||||
.. admonition:: Custom handlers and circular imports
|
||||
|
||||
|
|
@ -474,17 +474,17 @@ Python logging module.
|
|||
|
||||
.. class:: AdminEmailHandler([include_html=False])
|
||||
|
||||
This handler sends an e-mail to the site admins for each log
|
||||
This handler sends an email to the site admins for each log
|
||||
message it receives.
|
||||
|
||||
If the log record contains a ``request`` attribute, the full details
|
||||
of the request will be included in the e-mail.
|
||||
of the request will be included in the email.
|
||||
|
||||
If the log record contains stack trace information, that stack
|
||||
trace will be included in the e-mail.
|
||||
trace will be included in the email.
|
||||
|
||||
The ``include_html`` argument of ``AdminEmailHandler`` is used to
|
||||
control whether the traceback e-mail includes an HTML attachment
|
||||
control whether the traceback email includes an HTML attachment
|
||||
containing the full content of the debug Web page that would have been
|
||||
produced if ``DEBUG`` were ``True``. To set this value in your
|
||||
configuration, include it in the handler definition for
|
||||
|
|
@ -498,12 +498,12 @@ Python logging module.
|
|||
}
|
||||
},
|
||||
|
||||
Note that this HTML version of the e-mail contains a full traceback,
|
||||
Note that this HTML version of the email contains a full traceback,
|
||||
with names and values of local variables at each level of the stack, plus
|
||||
the values of your Django settings. This information is potentially very
|
||||
sensitive, and you may not want to send it over e-mail. Consider using
|
||||
sensitive, and you may not want to send it over email. Consider using
|
||||
something such as `django-sentry`_ to get the best of both worlds -- the
|
||||
rich information of full tracebacks plus the security of *not* sending the
|
||||
information over e-mail.
|
||||
information over email.
|
||||
|
||||
.. _django-sentry: http://pypi.python.org/pypi/django-sentry
|
||||
|
|
|
|||
|
|
@ -184,7 +184,7 @@ registered more than once, and thus called multiples times for a single signal
|
|||
event.
|
||||
|
||||
If this behavior is problematic (such as when using signals to
|
||||
send an e-mail whenever a model is saved), pass a unique identifier as
|
||||
send an email whenever a model is saved), pass a unique identifier as
|
||||
the ``dispatch_uid`` argument to identify your receiver function. This
|
||||
identifier will usually be a string, although any hashable object will
|
||||
suffice. The end result is that your receiver function will only be
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ explained later in this document.::
|
|||
|
||||
Why use a text-based template instead of an XML-based one (like Zope's
|
||||
TAL)? We wanted Django's template language to be usable for more than
|
||||
just XML/HTML templates. At World Online, we use it for e-mails,
|
||||
just XML/HTML templates. At World Online, we use it for emails,
|
||||
JavaScript and CSV. You can use the template language for any text-based
|
||||
format.
|
||||
|
||||
|
|
@ -473,7 +473,7 @@ contain data that you *intend* to be rendered as raw HTML, in which case you
|
|||
don't want their contents to be escaped. For example, you might store a blob of
|
||||
HTML in your database and want to embed that directly into your template. Or,
|
||||
you might be using Django's template system to produce text that is *not* HTML
|
||||
-- like an e-mail message, for instance.
|
||||
-- like an email message, for instance.
|
||||
|
||||
For individual variables
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
|
|
|||
|
|
@ -1351,9 +1351,9 @@ Emptying the test outbox
|
|||
~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
If you use Django's custom ``TestCase`` class, the test runner will clear the
|
||||
contents of the test e-mail outbox at the start of each test case.
|
||||
contents of the test email outbox at the start of each test case.
|
||||
|
||||
For more detail on e-mail services during tests, see `E-mail services`_.
|
||||
For more detail on email services during tests, see `Email services`_.
|
||||
|
||||
Assertions
|
||||
~~~~~~~~~~
|
||||
|
|
@ -1463,30 +1463,30 @@ cause of an failure in your test suite.
|
|||
|
||||
.. _topics-testing-email:
|
||||
|
||||
E-mail services
|
||||
Email services
|
||||
---------------
|
||||
|
||||
If any of your Django views send e-mail using :doc:`Django's e-mail
|
||||
functionality </topics/email>`, you probably don't want to send e-mail each time
|
||||
If any of your Django views send email using :doc:`Django's email
|
||||
functionality </topics/email>`, you probably don't want to send email each time
|
||||
you run a test using that view. For this reason, Django's test runner
|
||||
automatically redirects all Django-sent e-mail to a dummy outbox. This lets you
|
||||
test every aspect of sending e-mail -- from the number of messages sent to the
|
||||
automatically redirects all Django-sent email to a dummy outbox. This lets you
|
||||
test every aspect of sending email -- from the number of messages sent to the
|
||||
contents of each message -- without actually sending the messages.
|
||||
|
||||
The test runner accomplishes this by transparently replacing the normal
|
||||
email backend with a testing backend.
|
||||
(Don't worry -- this has no effect on any other e-mail senders outside of
|
||||
(Don't worry -- this has no effect on any other email senders outside of
|
||||
Django, such as your machine's mail server, if you're running one.)
|
||||
|
||||
.. currentmodule:: django.core.mail
|
||||
|
||||
.. data:: django.core.mail.outbox
|
||||
|
||||
During test running, each outgoing e-mail is saved in
|
||||
During test running, each outgoing email is saved in
|
||||
``django.core.mail.outbox``. This is a simple list of all
|
||||
:class:`~django.core.mail.EmailMessage` instances that have been sent.
|
||||
The ``outbox`` attribute is a special attribute that is created *only* when
|
||||
the ``locmem`` e-mail backend is used. It doesn't normally exist as part of the
|
||||
the ``locmem`` email backend is used. It doesn't normally exist as part of the
|
||||
:mod:`django.core.mail` module and you can't import it directly. The code
|
||||
below shows how to access this attribute correctly.
|
||||
|
||||
|
|
@ -1741,7 +1741,7 @@ utility methods in the ``django.test.utils`` module.
|
|||
.. function:: teardown_test_environment()
|
||||
|
||||
Performs any global post-test teardown, such as removing the black
|
||||
magic hooks into the template system and restoring normal e-mail
|
||||
magic hooks into the template system and restoring normal email
|
||||
services.
|
||||
|
||||
The creation module of the database backend (``connection.creation``)
|
||||
|
|
|
|||
|
|
@ -631,7 +631,7 @@ class AdminViewPermissionsTest(TestCase):
|
|||
self.assertFalse(login.context)
|
||||
self.client.get('/test_admin/admin/logout/')
|
||||
|
||||
# Test if user enters e-mail address
|
||||
# Test if user enters email address
|
||||
request = self.client.get('/test_admin/admin/')
|
||||
self.assertEqual(request.status_code, 200)
|
||||
login = self.client.post('/test_admin/admin/', self.super_email_login)
|
||||
|
|
@ -641,7 +641,7 @@ class AdminViewPermissionsTest(TestCase):
|
|||
self.assertContains(login, "Please enter a correct username and password.")
|
||||
new_user = User(username='jondoe', password='secret', email='super@example.com')
|
||||
new_user.save()
|
||||
# check to ensure if there are multiple e-mail addresses a user doesn't get a 500
|
||||
# check to ensure if there are multiple email addresses a user doesn't get a 500
|
||||
login = self.client.post('/test_admin/admin/', self.super_email_login)
|
||||
self.assertContains(login, "Please enter a correct username and password.")
|
||||
|
||||
|
|
@ -1227,7 +1227,7 @@ class SecureViewTests(TestCase):
|
|||
# make sure the view removes test cookie
|
||||
self.assertEqual(self.client.session.test_cookie_worked(), False)
|
||||
|
||||
# Test if user enters e-mail address
|
||||
# Test if user enters email address
|
||||
request = self.client.get('/test_admin/admin/secure-view/')
|
||||
self.assertEqual(request.status_code, 200)
|
||||
login = self.client.post('/test_admin/admin/secure-view/', self.super_email_login)
|
||||
|
|
@ -1237,7 +1237,7 @@ class SecureViewTests(TestCase):
|
|||
self.assertContains(login, "Please enter a correct username and password.")
|
||||
new_user = User(username='jondoe', password='secret', email='super@example.com')
|
||||
new_user.save()
|
||||
# check to ensure if there are multiple e-mail addresses a user doesn't get a 500
|
||||
# check to ensure if there are multiple email addresses a user doesn't get a 500
|
||||
login = self.client.post('/test_admin/admin/secure-view/', self.super_email_login)
|
||||
self.assertContains(login, "Please enter a correct username and password.")
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue