More documentation cleanup.

docs/activation-workflow.rst

@@ -5,7 +5,7 @@ The two-step activation workflow
 ================================
 
 The two-step activation workflow, found in
-`django_registration.backends.activation`, implements a two-step registration
+``django_registration.backends.activation``, implements a two-step registration
 process: a user signs up, an inactive account is created, and an email is sent
 containing an activation link which must be clicked to make the account active.
 
@@ -15,8 +15,8 @@ Behavior and configuration
 
 A default URLconf is provided, which you can :func:`~django.urls.include` in
 your URL configuration; that URLconf is
-`django_registration.backends.activation.urls`. For example, to place user
-registration under the URL prefix `/accounts/`, you could place the following
+``django_registration.backends.activation.urls``. For example, to place user
+registration under the URL prefix ``/accounts/``, you could place the following
 in your root URLconf:
 
 .. code-block:: python
@@ -30,7 +30,7 @@ in your root URLconf:
        # More URL patterns ...
    ]
 
-That also sets up the views from `django.contrib.auth` (login, logout, password
+That also sets up the views from ``django.contrib.auth`` (login, logout, password
 reset, etc.).
 
 This workflow makes use of up to three settings (click for details on each):
@@ -45,7 +45,7 @@ This workflow makes use of up to three settings (click for details on each):
 By default, this workflow uses
 :class:`~django_registration.forms.RegistrationForm` as its form class for user
 registration; this can be overridden by passing the keyword argument
-`form_class` to the registration view.
+``form_class`` to the registration view.
 
 
 Views
@@ -75,7 +75,7 @@ specified below), and their context variables, see :ref:`the quick start guide
 
       Creates and returns an inactive user account, and calls
       :meth:`send_activation_email()` to send the email with the activation
-      key. The argument `form` is a valid registration form instance passed
+      key. The argument ``form`` is a valid registration form instance passed
       from :meth:`~django_registration.views.RegistrationView.register()`.
 
       :param django_registration.forms.RegistrationForm form: The registration form.
@@ -108,13 +108,13 @@ specified below), and their context variables, see :ref:`the quick start guide
    .. attribute:: email_body_template
 
       A string specifying the template to use for the body of the activation
-      email. Default is `"django_registration/activation_email_body.txt"`.
+      email. Default is ``"django_registration/activation_email_body.txt"``.
 
    .. attribute:: email_subject_template
 
       A string specifying the template to use for the subject of the activation
       email. Default is
-      `"django_registration/activation_email_subject.txt"`. Note that, to avoid
+      ``"django_registration/activation_email_subject.txt"``. Note that, to avoid
       `header-injection vulnerabilities
       <https://en.wikipedia.org/wiki/Email_injection>`_, the result of
       rendering this template will be forced into a single line of text,
@@ -127,19 +127,19 @@ specified below), and their context variables, see :ref:`the quick start guide
 
    Errors in activating the user account will raise
    :exc:`~django_registration.exceptions.ActivationError`, with one of the
-   following values for the exception's `code`:
+   following values for the exception's ``code``:
 
-   `"already_activated"`
+   ``"already_activated"``
        Indicates the account has already been activated.
 
-   `"bad_username"`
+   ``"bad_username"``
        Indicates the username decoded from the activation key is invalid (does
        not correspond to any user account).
 
-   `"expired"`
+   ``"expired"``
        Indicates the account/activation key has expired.
 
-   `"invalid_key"`
+   ``"invalid_key"``
       Generic indicator that the activation key was invalid.
 
    Important customization points unique to this class are:
@@ -153,7 +153,7 @@ specified below), and their context variables, see :ref:`the quick start guide
       :attr:`~django.contrib.auth.models.User.is_active` field to avoid
       re-activating already-active accounts, and raises
       :exc:`~django_registration.exceptions.ActivationError` with code
-      `already_activated` to indicate this case.
+      ``already_activated`` to indicate this case.
 
       :param str username: The username of the new user account.
       :rtype: django.contrib.auth.models.AbstractUser
@@ -164,7 +164,7 @@ specified below), and their context variables, see :ref:`the quick start guide
 
       Given the activation key, verifies that it carries a valid signature and
       a timestamp no older than the number of days specified in the setting
-      `ACCOUNT_ACTIVATION_DAYS`, and returns the username from the activation
+      ``ACCOUNT_ACTIVATION_DAYS``, and returns the username from the activation
       key. Raises :exc:`~django_registration.exceptions.ActivationError`, as
       described above, if the activation key has an invalid signature or if the
       timestamp is too old.
@@ -183,21 +183,21 @@ specified below), and their context variables, see :ref:`the quick start guide
       URL) is produced by :func:`django.core.signing.dumps()`, which
       base64-encodes its output. Thus, the only characters this pattern needs
       to match are those from `the URL-safe base64 alphabet
-      <http://tools.ietf.org/html/rfc4648#section-5>`_, plus the colon ("`:`")
+      <http://tools.ietf.org/html/rfc4648#section-5>`_, plus the colon ("``:``")
       which is used as a separator.
 
       The default URL pattern for the activation view in
-      `django_registration.backends.activation.urls` handles this for you.
+      ``django_registration.backends.activation.urls`` handles this for you.
 
 
 How it works
 ------------
 
 When a user signs up, the activation workflow creates a new user instance to
-represent the account, and sets the `is_active` field to :data:`False`. It then
+represent the account, and sets the ``is_active`` field to :data:`False`. It then
 sends an email to the address provided during signup, containing a link to
 activate the account. When the user clicks the link, the activation view sets
-`is_active` to :data:`True`, after which the user can log in.
+``is_active`` to :data:`True`, after which the user can log in.
 
 The activation key is the username of the new account, signed using `Django's
 cryptographic signing tools
@@ -219,8 +219,8 @@ of the form::
 
     encoded_username:timestamp:signature
 
-where `encoded_username` is the username of the new account, `timestamp` is the
-timestamp of the time the user registered, and `signature` is an HMAC of the
+where ``encoded_username`` is the username of the new account, ``timestamp`` is the
+timestamp of the time the user registered, and ``signature`` is an HMAC of the
 username and timestamp. The username and HMAC will be URL-safe base64 encoded;
 the timestamp will be base62 encoded.
 
@@ -233,7 +233,7 @@ additionally, it permits the specification of a salt value which can be used to
 
 The activation workflow will use the value (a string) of the setting
 :data:`~django.conf.settings.REGISTRATION_SALT` as the salt, defaulting to the
-string `"registration"` if that setting is not specified. This value does *not*
+string ``"registration"`` if that setting is not specified. This value does *not*
 need to be kept secret (only :data:`~django.conf.settings.SECRET_KEY` does); it
 serves only to ensure that other parts of a site which also produce signed
 values from user input could not be used as a way to generate activation keys

docs/custom-user.rst

@@ -77,7 +77,7 @@ automatically handled for you.
 
 If your custom user model defines additional fields beyond the minimum
 requirements, you'll either need to ensure that all of those fields are
-optional (i.e., can be `NULL` in your database, or provide a suitable default
+optional (i.e., can be ``NULL`` in your database, or provide a suitable default
 value defined in the model), or specify the correct list of fields to display
 in your :class:`~django_registration.forms.RegistrationForm` subclass.
 
@@ -92,7 +92,7 @@ requirements on your user model:
   :attr:`~django.contrib.auth.models.CustomUser.USERNAME_FIELD` to indicate the
   field used as the username.
 
-* It must define a textual field named `password` for storing the user's
+* It must define a textual field named ``password`` for storing the user's
   password.
 
 Also note that the base :class:`~django_registration.forms.RegistrationForm`
@@ -109,7 +109,7 @@ automatically handled for you.
 
 If your custom user model defines additional fields beyond the minimum
 requirements, you'll either need to ensure that all of those fields are
-optional (i.e., can be `NULL` in your database, or provide a suitable default
+optional (i.e., can be ``NULL`` in your database, or provide a suitable default
 value defined in the model), or specify the correct list of fields to display
 in your :class:`~django_registration.forms.RegistrationForm` subclass.
 
@@ -119,7 +119,7 @@ creating it, you also must either use Django's
 backend
 <https://docs.djangoproject.com/en/stable/topics/auth/customizing/#other-authentication-sources>`_,
 or use an authentication backend which accepts a combination of
-`USERNAME_FIELD` and `password` as sufficient credentials to authenticate a
+``USERNAME_FIELD`` and ``password`` as sufficient credentials to authenticate a
 user.
 
 
@@ -148,7 +148,7 @@ django-registration, you will be able to subclass
 :class:`~django_registration.forms.RegistrationForm`, set it to use your custom
 user model as the model, and then configure the views in django-registration to
 use your form subclass. For example, you might do the following (in a
-`forms.py` module somewhere in your codebase -- do **not** directly edit
+``forms.py`` module somewhere in your codebase -- do **not** directly edit
 django-registration's code):
 
 .. code-block:: python
@@ -203,7 +203,7 @@ One is to subclass the built-in form and view classes of django-registration
 and make the necessary adjustments to achieve compatibility with your user
 model. For example, if you want to use the two-step activation workflow, but
 your user model uses a completely different way of marking accounts
-active/inactive (compared to the the assumed `is_active` field), you might
+active/inactive (compared to the the assumed ``is_active`` field), you might
 write subclasses of that workflow's
 :class:`~django_registration.backends.activation.views.RegistrationView` and
 :class:`~django_registration.backends.activation.views.ActivationView` which

docs/faq.rst

@@ -31,7 +31,7 @@ By using `django-allauth <https://pypi.python.org/pypi/django-allauth>`_. No
 single application can or should provide a universal API for every
 authentication system ever developed; django-registration sticks to making it
 easy to implement typical signup workflows using Django's default model-based
-authentication system, while apps like `django-allauth` handle integration with
+authentication system, while apps like ``django-allauth`` handle integration with
 third-party authentication services far more effectively.
 
 What license is django-registration under?
@@ -41,7 +41,7 @@ django-registration is offered under a three-clause BSD-style license; this is
 `an OSI-approved open-source license
 <http://www.opensource.org/licenses/bsd-license.php>`_, and allows you a large
 degree of freedom in modifying and redistributing the code. For the full terms,
-see the file `LICENSE` which came with your copy of django-registration; if you
+see the file ``LICENSE`` which came with your copy of django-registration; if you
 did not receive a copy of this file, you can view it online at
 <https://github.com/ubernostrum/django-registration/blob/master/LICENSE>.
 
@@ -107,7 +107,7 @@ django-registration's tests are run using `nox <https://nox.thea.codes/>`_, but
 typical installation of django-registration (via ``pip install
 django-registration``) will not install the tests.
 
-To run the tests, download the source (`.tar.gz`) distribution of
+To run the tests, download the source (``.tar.gz``) distribution of
 django-registration |release| from `its page on the Python Package Index
 <https://pypi.org/project/django-registration/>`_, unpack it (``tar zxvf
 django-registration-|version|.tar.gz`` on most Unix-like operating systems),
@@ -204,7 +204,7 @@ I don't want to write my own URLconf because I don't want to write patterns for
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 You're in luck, then; Django provides a URLconf for this, at
-`django.contrib.auth.urls`.
+``django.contrib.auth.urls``.
 
 I don't like the names you've given to the URL patterns!
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -228,8 +228,8 @@ If you haven't modified the behavior of the
 :meth:`~django_registration.views.RegistrationView.registration_allowed` method
 in :class:`~django_registration.views.RegistrationView`, you can use the
 setting :data:`~django.conf.settings.REGISTRATION_OPEN` to control this; when
-the setting is `True`, or isn't supplied, user registration will be
-permitted. When the setting is `False`, user registration will not be
+the setting is :data:`True`, or isn't supplied, user registration will be
+permitted. When the setting is :data:`False`, user registration will not be
 permitted.
 
 How do I log a user in immediately after registration or activation?
@@ -242,24 +242,15 @@ How do I manually activate a user?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 In :ref:`the two-step activation workflow <activation-workflow>`, toggle the
-`is_active` field of the user in the admin.
+``is_active`` field of the user in the admin.
 
 How do I delete expired unactivated accounts?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Perform a query for those accounts, and call the `delete()` method of the
-resulting `QuerySet`. Since django-registration doesn't know in advance what
+Perform a query for those accounts, and call the ``delete()`` method of the
+resulting ``QuerySet``. Since django-registration doesn't know in advance what
 your definition of "expired" will be, it leaves this step to you.
 
-How do I allow Unicode in usernames?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Use Python 3. Django's username validation allows any word character plus some
-additional characters, but the definition of "word character" depends on the
-Python version in use. On Python 2, only ASCII will be permitted; on Python 3,
-usernames containing word characters matched by a regex with the
-:data:`re.UNICODE` flag will be accepted.
-
 How do I tell why an account's activation failed?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 

docs/forms.rst

@@ -17,24 +17,24 @@ situations.
    :class:`~django.contrib.auth.forms.UserCreationForm`, and has the following
    fields, all of which are required:
 
-   `username`
+   ``username``
        The username to use for the new account.
 
-   `email`
+   ``email``
       The email address to use for the new account.
 
-   `password1`
+   ``password1``
       The password to use for the new account.
 
-   `password2`
+   ``password2``
       The password to use for the new account, repeated to catch typos.
 
    .. note:: **Validation of usernames**
 
       Django supplies a default regex-based validator for usernames in its base
       :class:`~django.contrib.auth.models.AbstractBaseUser` implementation,
       allowing any word character along with the following set of additional
-      characters: `.`, `@`, `+`, and `-`.
+      characters: ``.``, ``@``, ``+``, and ``-``.
 
       Because it's a subclass of Django's
       :class:`~django.contrib.auth.forms.UserCreationForm`,
@@ -52,7 +52,7 @@ situations.
 
       The HTML5 validator uses `the HTML5 email-validation rule
       <https://html.spec.whatwg.org/multipage/input.html#e-mail-state-(type=email)>`_
-      (as implemented on HTML's `input type="email"`), which is more
+      (as implemented on HTML's ``input type="email"``), which is more
       restrictive than the email RFCs. The purpose of this validator is
       twofold: to match the behavior of HTML5, and to simplify
       django-registration's other validators. The full RFC grammar for email
@@ -82,7 +82,7 @@ situations.
 
      This form will normalize the username value to form NFKC, matching
      Django's default approach to Unicode normalization. it will then case fold
-     the value, and use a case-insensitive (`iexact`) lookup to determine if a
+     the value, and use a case-insensitive (``iexact``) lookup to determine if a
      user with the same username already exists; the results of this query may
      depend on the quality of your database's Unicode implementation, and on
      configuration details. The results may also be surprising to developers
@@ -95,7 +95,7 @@ situations.
    A subclass of :class:`RegistrationForm` which adds one additional, required
    field:
 
-   `tos`
+   ``tos``
        A checkbox indicating agreement to the site's terms of service/user
        agreement.
 

docs/one-step-workflow.rst

@@ -6,7 +6,7 @@ The one-step workflow
 
 As an alternative to :ref:`the two-step (registration and activation) workflow
 <activation-workflow>`, django-registration bundles a one-step registration
-workflow in `django_registration.backends.one_step`. This workflow consists of
+workflow in ``django_registration.backends.one_step``. This workflow consists of
 as few steps as possible:
 
 1. A user signs up by filling out a registration form.
@@ -21,7 +21,7 @@ Configuration
 -------------
 
 To use this workflow, include the URLconf
-`django_registration.backends.one_step.urls` somewhere in your site's own URL
+``django_registration.backends.one_step.urls`` somewhere in your site's own URL
 configuration. For example:
 
 .. code-block:: python
@@ -39,7 +39,7 @@ To control whether registration of new accounts is allowed, you can specify the
 setting :data:`~django.conf.settings.REGISTRATION_OPEN`.
 
 Upon successful registration, the user will be redirected to the site's home
-page -- the URL `/`. This can be changed by subclassing
+page -- the URL ``/``. This can be changed by subclassing
 :class:`django_registration.backends.one_step.views.RegistrationView` and
 overriding the method
 :meth:`~django_registration.views.RegistrationView.get_success_url` or setting
@@ -66,7 +66,7 @@ do this in a URLconf. For example:
 The default form class used for account registration will be
 :class:`django_registration.forms.RegistrationForm`, although this can be
 overridden by supplying a custom URL pattern for the registration view and
-passing the keyword argument `form_class`, or by subclassing
+passing the keyword argument ``form_class``, or by subclassing
 :class:`django_registration.backends.one_step.views.RegistrationView` and
 either overriding
 :attr:`~django_registration.views.RegistrationView.form_class` or implementing
@@ -79,8 +79,8 @@ Templates
 
 The one-step workflow uses two templates:
 
-* `django_registration/registration_form.html`.
-* `django_registration/registration_closed.html`
+* ``django_registration/registration_form.html``.
+* ``django_registration/registration_closed.html``
 
 See :ref:`the quick start guide <default-form-template>` for details of these
 templates.