Commits

Philipp Bosch committed 603e7a2

Hardcore renaming action.

  • Participants
  • Parent commits d36a382

Comments (0)

Files changed (156)

-The primary author of django-registration is James Bennett
+The primary author of django-signup is James Bennett
 <james@b-list.org>, who may be found online at
 <http://www.b-list.org/>.
 
 =============================
-django-registration changelog
+django-signup changelog
 =============================
 
 
 
 * Full Django 1.0 compatibility.
 
-* Registration and activation views now accept an ``extra_context``
+* Signup and activation views now accept an ``extra_context``
   argument, identical to the way that argument works in Django's
   generic views.
 
 * Added a custom management command for cleaning up expired
-  registrations; you can now run ``manage.py cleanupregistration`` to
+  signups; you can now run ``manage.py cleanupsignup`` to
   handle this.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: The "username" field in
-  ``RegistrationForm`` is now a ``RegexField``.
+  ``SignupForm`` is now a ``RegexField``.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: Removed the standalone script for
-  deleting expired user registrations; use the new management command
+  deleting expired user signups; use the new management command
   instead.
 
 
 * Packaged from revision 166 in Subversion.
 
 * Fixed a multiple-objects exception in
-  ``RegistrationFormUniqueEmail`` when multiple users already have the
+  ``SignupFormUniqueEmail`` when multiple users already have the
   same email address.
 
 * Changed the ``success_url`` of the ``register()`` view to use
 
 * BACKWARDS-INCOMPATIBLE CHANGE: Switched the admin declaration to be
   compliant with the newforms-admin refactor; the admin declaration
-  now lives in ``registration/admin.py``.
+  now lives in ``signup/admin.py``.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: Switched form imports from using
   ``django.newforms`` to using ``django.forms``; the old style now
 
 * Added German translation.
 
-* Fixed a mismatch between the default ``RegistrationForm``'s maximum
+* Fixed a mismatch between the default ``SignupForm``'s maximum
   length on email addresses and the actual maximum length on Django's
   ``User`` model.
 
 * Fixed a situation where bad input for the ``password1`` field on
-  ``RegistrationForm`` could cause validation of ``password2`` to fail
+  ``SignupForm`` could cause validation of ``password2`` to fail
   with an exception.
 
 
 -------------------------------
 
 Packaged from revision 89 in Subversion; download at
-http://django-registration.googlecode.com/files/registration-0.3.tar.gz
+http://django-signup.googlecode.com/files/signup-0.3.tar.gz
 
 * Changed ``register`` and ``activate`` views to accept
   ``template_name`` keyword argument for selecting a custom template.
   argument specifying the form to use.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: Changed
-  ``RegistrationManager.create_inactive_user`` to use a template for
+  ``SignupManager.create_inactive_user`` to use a template for
   the subject of the activation email.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: Removed the ``tos`` field from
-  ``RegistrationForm``; if you were relying on it, switch to using
-  ``RegistrationFormTermsOfService`` instead.
+  ``SignupForm``; if you were relying on it, switch to using
+  ``SignupFormTermsOfService`` instead.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: The activation email template now
   receives the current ``Site`` object as the context variable
 -------------------------
 
 Packaged from revision 76 in Subversion; download at
-http://django-registration.googlecode.com/files/registration-0.2.tar.gz
+http://django-signup.googlecode.com/files/signup-0.2.tar.gz
 
 * Added ability to specify a callback in
-  ``RegistrationManager.create_inactive_user`` or in the ``register``
+  ``SignupManager.create_inactive_user`` or in the ``register``
   view to enable creation of site-specific user profile.
 
 * Separated out the logic of creating the profile into a new method on
-  ``RegistrationManager``: ``create_profile``.
+  ``SignupManager``: ``create_profile``.
 
 * Added URLConf support for various useful views in
   ``django.contrib.auth``.
 
 * BACKWARDS-INCOMPATIBLE CHANGE: removed the ``key_generated`` field
-  from ``RegistrationProfile``; activation key expiration is now
+  from ``SignupProfile``; activation key expiration is now
   calculated based on the ``date_joined`` field in the ``User`` model.
   Drop the ``key_generated`` column from your database when upgrading
   from 0.1.
 -------------------------
 
 Packaged from revision 56 in Subversion; download at
-http://django-registration.googlecode.com/files/registration-0.1.tar.gz
+http://django-signup.googlecode.com/files/signup-0.1.tar.gz
 
 * First packaged version using distutils.
 
-Thanks for downloading django-registration.
+Thanks for downloading django-signup.
 
 To install it, run the following command inside this directory:
 
 If you have the Python ``easy_install`` utility available, you can
 also type the following to download and install in one step::
 
-   easy_install -Z django-registration
+   easy_install -Z django-signup
 
 (the ``-Z`` flag is required to force ``easy_install`` to do a normal
-source install rather than a zipped egg; django-registration cannot be
+source install rather than a zipped egg; django-signup cannot be
 used from a zipped egg install)
 
 Or if you're using ``pip``::
 
-    pip install django-registration
+    pip install django-signup
 
-Or if you'd prefer you can simply place the included ``registration``
+Or if you'd prefer you can simply place the included ``signup``
 directory somewhere on your Python path, or symlink to it from
 somewhere on your Python path; this is useful if you're working from a
 Mercurial checkout.
 include README
 include AUTHORS
 recursive-include docs *
-recursive-include registration/locale *
+recursive-include signup/locale *
 ========================
-Django user registration
+Django user signup
 ========================
 
-This is a fairly simple user-registration application for Django_,
+This is a fairly simple user-signup application for Django_,
 designed to make allowing user signups as painless as possible. It
 requires a functional installation of Django 1.1 or newer, but has no
 other dependencies.

File docs/Makefile

 	@echo
 	@echo "Build finished; now you can run "qcollectiongenerator" with the" \
 	      ".qhcp project file in _build/qthelp, like this:"
-	@echo "# qcollectiongenerator _build/qthelp/django-registration.qhcp"
+	@echo "# qcollectiongenerator _build/qthelp/django-signup.qhcp"
 	@echo "To view the help file:"
-	@echo "# assistant -collectionFile _build/qthelp/django-registration.qhc"
+	@echo "# assistant -collectionFile _build/qthelp/django-signup.qhc"
 
 latex:
 	$(SPHINXBUILD) -b latex $(ALLSPHINXOPTS) _build/latex

File docs/backend-api.rst

 .. _backend-api:
 
-User registration backends
+User signup backends
 ==========================
 
-At its core, django-registration is built around the idea of pluggable
+At its core, django-signup is built around the idea of pluggable
 backends which can implement different workflows for user
-registration. Although :ref:`the default backend <default-backend>`
-uses a common two-phase system (registration followed by activation),
+signup. Although :ref:`the default backend <default-backend>`
+uses a common two-phase system (signup followed by activation),
 backends are generally free to implement any workflow desired by their
 authors.
 
 `pluggable authentication backends
 <http://docs.djangoproject.com/en/dev/topics/auth/#other-authentication-sources>`_;
 a site which uses an OpenID authentication backend, for example, can
-and should make use of a registration backend which handles signups
-via OpenID. And, like a Django authentication backend, a registration
+and should make use of a signup backend which handles signups
+via OpenID. And, like a Django authentication backend, a signup
 backend is simply a class which implements a particular standard API
 (described below).
 
 This allows for a great deal of flexibility in the actual workflow of
-registration; backends can, for example, implement any of the
+signup; backends can, for example, implement any of the
 following (not an exhaustive list):
 
 * One-step (register, and done) or multi-step (register and activate)
   signup.
 
-* Invitation-based registration.
+* Invitation-based signup.
 
-* Selectively allowing or disallowing registration (e.g., by requiring
+* Selectively allowing or disallowing signup (e.g., by requiring
   particular credentials to register).
 
-* Enabling/disabling registration entirely.
+* Enabling/disabling signup entirely.
 
 * Registering via sources other than a standard username/password,
   such as OpenID.
 
-* Selective customization of the registration process (e.g., using
+* Selective customization of the signup process (e.g., using
   different forms or imposing different requirements for different
   types of users).
 
 -----------------------------
 
 To determine which backend to use, the :ref:`views in
-django-registration <views>` accept a keyword argument ``backend``; in
+django-signup <views>` accept a keyword argument ``backend``; in
 all cases, this should be a string containing the full dotted Python
 import path to the backend class to be used. So, for example, to use
 the default backend, you'd pass the string
-``'registration.backends.default.DefaultBackend'`` as the value of the
+``'signup.backends.default.DefaultBackend'`` as the value of the
 ``backend`` argument (and the default URLconf included with that
 backend does so). The specified backend class will then be imported
 and instantiated (by calling its constructor with no arguments), and
 the resulting instance will be used for all backend-specific
 functionality.
 
-If the specified backend class cannot be imported, django-registration
+If the specified backend class cannot be imported, django-signup
 will raise ``django.core.exceptions.ImproperlyConfigured``.
 
 
 Backend API
 -----------
 
-To be used as a registration backend, a class must implement the
+To be used as a signup backend, a class must implement the
 following methods. For many cases, subclassing the default backend and
 selectively overriding behavior will be suitable, but for other
 situations (e.g., workflows significantly different from the default)
 After creating the new user account, this method should create or
 obtain an instance of ``django.contrib.auth.models.User`` representing
 that account. It should then send the signal
-:data:`registration.signals.user_registered`, with three arguments:
+:data:`signup.signals.user_registered`, with three arguments:
 
 ``sender``
     The backend class (e.g., ``self.__class__``).
 ``**kwargs``
     A dictionary of any additional arguments (e.g., information
     captured from the URL, such as an activation key) received by the
-    :func:`~registration.views.activate` view. The combination of the
+    :func:`~signup.views.activate` view. The combination of the
     ``HttpRequest`` and this additional information must be sufficient
     to identify the account which will be activated.
 
 If the account is successfully activated, this method should create or
 obtain an instance of ``django.contrib.auth.models.User`` representing
 the activated account. It should then send the signal
-:data:`registration.signals.user_activated`, with three arguments:
+:data:`signup.signals.user_activated`, with three arguments:
 
 ``sender``
     The backend class.
 method can and should raise ``NotImplementedError``.
 
 
-registration_allowed(request)
+signup_allowed(request)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This method returns a boolean value indicating whether the given
 ``HttpRequest`` is permitted to register a new account (``True`` if
-registration is permitted, ``False`` otherwise). It may determine this
+signup is permitted, ``False`` otherwise). It may determine this
 based on some aspect of the ``HttpRequest`` (e.g., the presence or
 absence of an invitation code in the URL), based on a setting (in the
-default backend, a setting can be used to disable registration),
+default backend, a setting can be used to disable signup),
 information in the database or any other information it can access.
 
 Arguments to this method are:
     attempting to register.
 
 If this method returns ``False``, the
-:func:`~registration.views.register` view will not display a form for
+:func:`~signup.views.register` view will not display a form for
 account creation; instead, it will issue a redirect to a URL
-explaining that registration is not permitted.
+explaining that signup is not permitted.
 
 
 get_form_class(request)
     attempting to register.
 
 
-post_registration_redirect(request, user)
+post_signup_redirect(request, user)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 This method should return a location to which the user will be
-redirected after successful registration. This should be a tuple of
+redirected after successful signup. This should be a tuple of
 ``(to, args, kwargs)``, suitable for use as the arguments to `Django's
 "redirect" shortcut
 <http://docs.djangoproject.com/en/dev/topics/http/shortcuts/#redirect>`_.

File docs/conf.py

 # -*- coding: utf-8 -*-
 #
-# django-registration documentation build configuration file, created by
+# django-signup documentation build configuration file, created by
 # sphinx-quickstart on Mon Jun 22 02:57:42 2009.
 #
 # This file is execfile()d with the current directory set to its containing dir.
 master_doc = 'index'
 
 # General information about the project.
-project = u'django-registration'
+project = u'django-signup'
 copyright = u'2009, James Bennett'
 
 # The version info for the project you're documenting, acts as replacement for
 #html_file_suffix = ''
 
 # Output file base name for HTML help builder.
-htmlhelp_basename = 'django-registrationdoc'
+htmlhelp_basename = 'django-signupdoc'
 
 
 # -- Options for LaTeX output --------------------------------------------------
 # Grouping the document tree into LaTeX files. List of tuples
 # (source start file, target name, title, author, documentclass [howto/manual]).
 latex_documents = [
-  ('index', 'django-registration.tex', u'django-registration Documentation',
+  ('index', 'django-signup.tex', u'django-signup Documentation',
    u'James Bennett', 'manual'),
 ]
 

File docs/default-backend.rst

 .. _default-backend:
-.. module:: registration.backends.default
+.. module:: signup.backends.default
 
 The default backend
 ===================
 
-A default :ref:`registration backend <backend-api>` is bundled with
-django-registration, as the class
-``registration.backends.default.DefaultBackend``, and implements a
+A default :ref:`signup backend <backend-api>` is bundled with
+django-signup, as the class
+``signup.backends.default.DefaultBackend``, and implements a
 simple two-step workflow in which a new user first registers, then
 confirms and activates the new account by following a link sent to the
-email address supplied during registration.
+email address supplied during signup.
 
 
 Default behavior and configuration
 
 ``REGISTRATION_OPEN``
     A boolean (either ``True`` or ``False``) indicating whether
-    registration of new accounts is currently permitted. This setting
+    signup of new accounts is currently permitted. This setting
     is optional, and a default of ``True`` will be assumed if it is
     not supplied.
 
 By default, this backend uses
-:class:`registration.forms.RegistrationForm` as its form class for
-user registration; this can be overridden by passing the keyword
-argument ``form_class`` to the :func:`~registration.views.register`
+:class:`signup.forms.SignupForm` as its form class for
+user signup; this can be overridden by passing the keyword
+argument ``form_class`` to the :func:`~signup.views.register`
 view.
 
-Upon successful registration -- not activation -- the default redirect
-is to the URL pattern named ``registration_complete``; this can be
+Upon successful signup -- not activation -- the default redirect
+is to the URL pattern named ``signup_complete``; this can be
 overridden by passing the keyword argument ``success_url`` to the
-:func:`~registration.views.register` view.
+:func:`~signup.views.register` view.
 
 Upon successful activation, the default redirect is to the URL pattern
-named ``registration_activation_complete``; this can be overridden by
+named ``signup_activation_complete``; this can be overridden by
 passing the keyword argument ``success_url`` to the
-:func:`~registration.views.activate` view.
+:func:`~signup.views.activate` view.
 
 
 How account data is stored for activation
 -----------------------------------------
 
-During registration, a new instance of
+During signup, a new instance of
 ``django.contrib.auth.models.User`` is created to represent the new
 account, with the ``is_active`` field set to ``False``. An email is
 then sent to the email address of the account, containing a link the
 the database, using the following model:
 
 
-.. currentmodule:: registration.models
+.. currentmodule:: signup.models
 
-.. class:: RegistrationProfile
+.. class:: SignupProfile
 
    A simple representation of the information needed to activate a new
    user account. This is **not** a user profile; it simply provides a
          has already been activated and so the key is considered to
          have expired.
 
-      2. Otherwise, the date of registration (obtained from the
+      2. Otherwise, the date of signup (obtained from the
          ``date_joined`` field of :attr:`user`) is compared to the
          current date; if the span between them is greater than the
          value of the setting ``ACCOUNT_ACTIVATION_DAYS``, the key is
       Sends an activation email to the address of the account.
 
       The activation email will make use of two templates:
-      ``registration/activation_email_subject.txt`` and
-      ``registration/activation_email.txt``, which are used for the
+      ``signup/activation_email_subject.txt`` and
+      ``signup/activation_email.txt``, which are used for the
       subject of the email and the body of the email,
       respectively. Each will receive the following context:
 
           for details regarding these objects' interfaces.
 
       Because email subjects must be a single line of text, the
-      rendered output of ``registration/activation_email_subject.txt``
+      rendered output of ``signup/activation_email_subject.txt``
       will be forcibly condensed to a single line.
 
       :param site: An object representing the site on which account
       :rtype: ``None``
 
 
-Additionally, :class:`RegistrationProfile` has a custom manager
-(accessed as ``RegistrationProfile.objects``):
+Additionally, :class:`SignupProfile` has a custom manager
+(accessed as ``SignupProfile.objects``):
 
 
-.. class:: RegistrationManager
+.. class:: SignupManager
 
    This manager provides several convenience methods for creating and
-   working with instances of :class:`RegistrationProfile`:
+   working with instances of :class:`SignupProfile`:
 
    .. method:: activate_user(activation_key)
 
       Validates ``activation_key`` and, if valid, activates the
       associated account by setting its ``is_active`` field to
       ``True``. To prevent re-activation of accounts, the
-      :attr:`~RegistrationProfile.activation_key` of the
-      :class:`RegistrationProfile` for the account will be set to
-      :attr:`RegistrationProfile.ACTIVATED` after successful
+      :attr:`~SignupProfile.activation_key` of the
+      :class:`SignupProfile` for the account will be set to
+      :attr:`SignupProfile.ACTIVATED` after successful
       activation.
 
       Returns the ``User`` instance representing the account if
 
    .. method:: delete_expired_users
 
-      Removes expired instances of :class:`RegistrationProfile`, and
+      Removes expired instances of :class:`SignupProfile`, and
       their associated user accounts, from the database. This is
       useful as a periodic maintenance task to clean out accounts
       which registered but never activated.
 
       Accounts to be deleted are identified by searching for instances
-      of :class:`RegistrationProfile` with expired activation keys and
+      of :class:`SignupProfile` with expired activation keys and
       with associated user accounts which are inactive (have their
       ``is_active`` field set to ``False``). To disable a user account
       without having it deleted, simply delete its associated
-      :class:`RegistrationProfile`; any ``User`` which does not have
-      an associated :class:`RegistrationProfile` will not be deleted.
+      :class:`SignupProfile`; any ``User`` which does not have
+      an associated :class:`SignupProfile` will not be deleted.
 
       A custom management command is provided which will execute this
       method, suitable for use in cron jobs or other scheduled
-      maintenance tasks: ``manage.py cleanupregistration``.
+      maintenance tasks: ``manage.py cleanupsignup``.
 
       :rtype: ``None``
 
    .. method:: create_inactive_user(username, email, password, site[, send_email])
 
       Creates a new, inactive user account and an associated instance
-      of :class:`RegistrationProfile`, sends the activation email and
+      of :class:`SignupProfile`, sends the activation email and
       returns the new ``User`` object representing the account.
 
       :param username: The username to use for the new account.
          ``django.contrib.sites.models.RequestSite``
       :param send_email: If ``True``, the activation email will be
          sent to the account (by calling
-         :meth:`RegistrationProfile.send_activation_email`). If
+         :meth:`SignupProfile.send_activation_email`). If
          ``False``, no email will be sent (but the account will still
          be inactive)
       :type send_email: bool
 
    .. method:: create_profile(user)
 
-      Creates and returns a :class:`RegistrationProfile` instance for
+      Creates and returns a :class:`SignupProfile` instance for
       the account represented by ``user``.
 
-      The ``RegistrationProfile`` created by this method will have its
-      :attr:`~RegistrationProfile.activation_key` set to a SHA1 hash
+      The ``SignupProfile`` created by this method will have its
+      :attr:`~SignupProfile.activation_key` set to a SHA1 hash
       generated from a combination of the account's username and a
       random salt.
 
       :param user: The user account; an instance of
          ``django.contrib.auth.models.User``.
       :type user: ``User``
-      :rtype: ``RegistrationProfile``
+      :rtype: ``SignupProfile``

File docs/faq.rst

 ==========================
 
 The following are miscellaneous common questions and answers related
-to installing/using django-registration, culled from bug reports,
+to installing/using django-signup, culled from bug reports,
 emails and other sources.
 
 
 General
 -------
 
-**What license is django-registration under?**
-    django-registration is offered under a three-clause BSD-style
+**What license is django-signup under?**
+    django-signup 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 modifiying and redistributing the
     code. For the full terms, see the file ``LICENSE`` which came with
-    your copy of django-registration; if you did not receive a copy of
+    your copy of django-signup; if you did not receive a copy of
     this file, you can view it online at
-    <http://bitbucket.org/ubernostrum/django-registration/src/tip/LICENSE>.
+    <http://bitbucket.org/ubernostrum/django-signup/src/tip/LICENSE>.
 
 **Why are the forms and models for the default backend not in the default backend?**
     The model and manager used by :ref:`the default backend
-    <default-backend>` are in ``registration.models``, and the default
-    form class (and various subclasses) are in ``registration.forms``;
+    <default-backend>` are in ``signup.models``, and the default
+    form class (and various subclasses) are in ``signup.forms``;
     logically, they might be expected to exist in
-    ``registration.backends.default``, but there are several reasons
+    ``signup.backends.default``, but there are several reasons
     why that's not such a good idea:
 
-    1. Older versions of django-registration made use of the model and
+    1. Older versions of django-signup made use of the model and
        form classes, and moving them would create an unnecessary
        backwards incompatibility: ``import`` statements would need to
        be changed, and some database updates would be needed to
        reflect the new location of the
-       :class:`~registration.models.RegistrationProfile` model.
+       :class:`~signup.models.SignupProfile` model.
 
-    2. Due to the design of Django's ORM, the ``RegistrationProfile``
+    2. Due to the design of Django's ORM, the ``SignupProfile``
        model would end up with an ``app_label`` of ``default``, which
        isn't particularly descriptive and may conflict with other
-       applications. By keeping it in ``registration.models``, it
-       retains an ``app_label`` of ``registration``, which more
+       applications. By keeping it in ``signup.models``, it
+       retains an ``app_label`` of ``signup``, which more
        accurately reflects what it does and is less likely to cause
        problems.
 
-    3. Although the ``RegistrationProfile`` model and the various
+    3. Although the ``SignupProfile`` model and the various
        :ref:`form classes <forms>` are used by the default backend,
        they can and are meant to be reused as needed by other
        backends. Any backend which uses an activation step should feel
-       free to reuse the ``RegistrationProfile`` model, for example,
-       and the registration form classes are in no way tied to a
+       free to reuse the ``SignupProfile`` model, for example,
+       and the signup form classes are in no way tied to a
        specific backend (and cover a number of common use cases which
        will crop up regardless of the specific backend logic in use).
 
 Installation and setup
 ----------------------
 
-**How do I install django-registration?**
+**How do I install django-signup?**
     Full instructions are available in :ref:`the quick start guide <quickstart>`.
 
-**Do I need to put a copy of django-registration in every project I use it in?**
+**Do I need to put a copy of django-signup in every project I use it in?**
     No; putting applications in your project directory is a very bad
     habit, and you should stop doing it. If you followed the
-    instructions mentioned above, django-registration was installed
+    instructions mentioned above, django-signup was installed
     into a location that's on your Python import path, so you'll only
-    ever need to add ``registration`` to your ``INSTALLED_APPS``
+    ever need to add ``signup`` to your ``INSTALLED_APPS``
     setting (in any project, or in any number of projects), and it
     will work.
 
-**Does django-registration come with any sample templates I can use right away?**
+**Does django-signup come with any sample templates I can use right away?**
     No, for two reasons:
 
     1. Providing default templates with an application is generally
        provide templates which would work with all the possibilities
        would probably end up working with none of them.
 
-    2. A number of things in django-registration depend on the
-       specific :ref:`registration backend <backend-api>` you use,
+    2. A number of things in django-signup depend on the
+       specific :ref:`signup backend <backend-api>` you use,
        including the variables which end up in template
-       contexts. Since django-registration has no way of knowing in
+       contexts. Since django-signup has no way of knowing in
        advance what backend you're going to be using, it also has no
        way of knowing what your templates will need to look like.
     
-    Fortunately, however, django-registration has good documentation
+    Fortunately, however, django-signup has good documentation
     which explains what context variables will be available to
     templates, and so it should be easy for anyone who knows Django's
     template system to create templates which integrate with their own
     making any changes whatsoever:
 
     * Pass custom arguments -- e.g., to specify forms, template names,
-      etc. -- to :ref:`the registration views <views>`.
+      etc. -- to :ref:`the signup views <views>`.
 
     * Use the :ref:`signals <signals>` sent by the views to add custom
       behavior.
 
-    * Write a custom :ref:`registration backend <backend-api>` which
+    * Write a custom :ref:`signup backend <backend-api>` which
       implements the behavior you need, and have the views use your
       backend.
 
     If none of these are sufficient, your best option is likely to
     simply write your own views; however, it is hoped that the level
     of customization exposed by these options will be sufficient for
-    nearly all user-registration workflows.
+    nearly all user-signup workflows.
 
 **How do I pass custom arguments to the views?**
     Part 3 of the official Django tutorial, when it `introduces
     covers the necessary mechanism: simply provide a dictionary of
     keyword arguments in your URLconf.
 
-**Does that mean I should rewrite django-registration's default URLconf?**
-    No; if you'd like to pass custom arguments to the registration
+**Does that mean I should rewrite django-signup's default URLconf?**
+    No; if you'd like to pass custom arguments to the signup
     views, simply write and include your own URLconf instead of
-    including the default one provided with django-registration.
+    including the default one provided with django-signup.
 
 **I don't want to write my own URLconf because I don't want to write patterns for all the auth views!**
-    You're in luck, then; django-registration provides a URLconf which
+    You're in luck, then; django-signup provides a URLconf which
     *only* contains the patterns for the auth views, and which you can
     include in your own URLconf anywhere you'd like; it lives at
-    ``registration.auth_urls``.
+    ``signup.auth_urls``.
 
 **I don't like the names you've given to the URL patterns!**
     In that case, you should feel free to set up your own URLconf
 Troubleshooting
 ---------------
 
-**I've got functions listening for the registration/activation signals, but they're not getting called!**
+**I've got functions listening for the signup/activation signals, but they're not getting called!**
 
-    The most common cause of this is placing django-registration in a
+    The most common cause of this is placing django-signup in a
     sub-directory that's on your Python import path, rather than
     installing it directly onto the import path as normal. Importing
-    from django-registration in that case can cause various issues,
+    from django-signup in that case can cause various issues,
     including incorrectly connecting signal handlers. For example, if
-    you were to place django-registration inside a directory named
+    you were to place django-signup inside a directory named
     ``django_apps``, and refer to it in that manner, you would end up
     with a situation where your code does this::
 
-        from django_apps.registration.signals import user_registered
+        from django_apps.signup.signals import user_registered
 
-    But django-registration will be doing::
+    But django-signup will be doing::
 
-        from registration.signals import user_registered
+        from signup.signals import user_registered
 
     From Python's point of view, these import statements refer to two
     different objects in two different modules, and so signal handlers
     when the signal is sent using the second import.
 
     To avoid this problem, follow the standard practice of installing
-    django-registration directly on your import path and always
-    referring to it by its own module name: ``registration`` (and in
+    django-signup directly on your import path and always
+    referring to it by its own module name: ``signup`` (and in
     general, it is always a good idea to follow normal Python
     practices for installing and using Django applications).
 
 Tips and tricks
 ---------------
 
-**How do I log a user in immediately after registration or activation?**
+**How do I log a user in immediately after signup or activation?**
     You can most likely do this simply by writing a function which
     listens for the appropriate :ref:`signal <signals>`; your function
     should set the ``backend`` attribute of the user to the correct
     <default-backend>`, a `custom admin action
     <http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/>`_
     is provided for this; in the admin for the
-    :class:`~registration.models.RegistrationProfile` model, simply
+    :class:`~signup.models.SignupProfile` model, simply
     click the checkbox for the user(s) you'd like to re-send the email
     for, then select the "Re-send activation emails" action.
 
 **How do I manually activate a user?**
     In the default backend, a custom admin action is provided for
-    this. In the admin for the ``RegistrationProfile`` model, click
+    this. In the admin for the ``SignupProfile`` model, click
     the checkbox for the user(s) you'd like to activate, then select
     the "Activate users" action.

File docs/forms.rst

 .. _forms:
-.. module:: registration.forms
+.. module:: signup.forms
 
-Forms for user registration
+Forms for user signup
 ===========================
 
-Several form classes are provided with django-registration, covering
+Several form classes are provided with django-signup, covering
 common cases for gathering account information and implementing common
-constraints for user registration. These forms were designed with
-django-registration's :ref:`default backend <default-backend>` in
+constraints for user signup. These forms were designed with
+django-signup's :ref:`default backend <default-backend>` in
 mind, but may also be useful in other situations.
 
 
-.. class:: RegistrationForm
+.. class:: SignupForm
 
    A simple form for registering an account. Has the following fields,
    all of which are required:
    ``non_field_errors()`` method.
 
 
-.. class:: RegistrationFormTermsOfService
+.. class:: SignupFormTermsOfService
 
-   A subclass of :class:`RegistrationForm` which adds one additional,
+   A subclass of :class:`SignupForm` which adds one additional,
    required field:
 
    ``tos``
        service/user agreement.
 
 
-.. class:: RegistrationFormUniqueEmail
+.. class:: SignupFormUniqueEmail
 
-   A subclass of :class:`RegistrationForm` which enforces uniqueness
+   A subclass of :class:`SignupForm` which enforces uniqueness
    of email addresses in addition to uniqueness of usernames.
 
 
-.. class:: RegistrationFormNoFreeEmail
+.. class:: SignupFormNoFreeEmail
 
-   A subclass of :class:`RegistrationForm` which disallows
-   registration using addresses from some common free email
+   A subclass of :class:`SignupForm` which disallows
+   signup using addresses from some common free email
    providers. This can, in some cases, cut down on automated
-   registration by spambots.
+   signup by spambots.
 
    By default, the following domains are disallowed for email
    addresses:

File docs/index.rst

-.. django-registration documentation master file, created by
+.. django-signup documentation master file, created by
    sphinx-quickstart on Mon Jun 22 02:57:42 2009.
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
-django-registration 0.8 documentation
+django-signup 0.8 documentation
 =====================================
 
-This documentation covers the 0.8 release of django-registration, a
-simple but extensible application providing user registration
+This documentation covers the 0.8 release of django-signup, a
+simple but extensible application providing user signup
 functionality for `Django <http://www.djangoproject.com>`_-powered
 websites.
 
-Although nearly all aspects of the registration process are
-customizable, the default setup of django-registration attempts to
-cover the most common use case: two-phase registration, consisting of
+Although nearly all aspects of the signup process are
+customizable, the default setup of django-signup attempts to
+cover the most common use case: two-phase signup, consisting of
 initial signup followed by a confirmation email which contains
 instructions for activating the new account.
 
 To get up and running quickly, consult the :ref:`quick-start guide
 <quickstart>`, which describes all the necessary steps to install
-django-registration and configure it for the default workflow. For
-more detailed information, including how to customize the registration
-process (and support for alternate registration systems), read through
+django-signup and configure it for the default workflow. For
+more detailed information, including how to customize the signup
+process (and support for alternate signup systems), read through
 the documentation listed below.
 
 If you are upgrading from a previous release, please read the
 
    * `Django's authentication documentation
      <http://docs.djangoproject.com/en/dev/topics/auth/>`_; Django's
-     authentication system is used by django-registration's default
+     authentication system is used by django-signup's default
      configuration.
 
    * `django-profiles

File docs/make.bat

 	echo.
 	echo.Build finished; now you can run "qcollectiongenerator" with the ^
 .qhcp project file in _build/qthelp, like this:
-	echo.^> qcollectiongenerator _build\qthelp\django-registration.qhcp
+	echo.^> qcollectiongenerator _build\qthelp\django-signup.qhcp
 	echo.To view the help file:
-	echo.^> assistant -collectionFile _build\qthelp\django-registration.ghc
+	echo.^> assistant -collectionFile _build\qthelp\django-signup.ghc
 	goto end
 )
 

File docs/quickstart.rst

 Quick start guide
 =================
 
-Before installing django-registration, you'll need to have a copy of
+Before installing django-signup, you'll need to have a copy of
 `Django <http://www.djangoproject.com>`_ already installed. For the
 |version| release, Django 1.1 or newer is required.
 
 packaged downloads and installation instructions.
 
 
-Installing django-registration
+Installing django-signup
 ------------------------------
 
-There are several ways to install django-registration:
+There are several ways to install django-signup:
 
 * Automatically, via a package manager.
 
 the most popular are `easy_install
 <http://peak.telecommunity.com/DevCenter/EasyInstall>`_ and `pip
 <http://pip.openplans.org/>`_. Either can be used to install
-django-registration.
+django-signup.
 
 Using ``easy_install``, type::
 
-    easy_install -Z django-registration
+    easy_install -Z django-signup
 
 Note that the ``-Z`` flag is required, to tell ``easy_install`` not to
 create a zipped package; zipped packages prevent certain features of
 
 Using ``pip``, type::
 
-    pip install django-registration
+    pip install django-signup
 
 It is also possible that your operating system distributor provides a
-packaged version of django-registration (for example, `Debian
+packaged version of django-signup (for example, `Debian
 GNU/Linux <http://debian.org/>`_ provides a package, installable via
-``apt-get-install python-django-registration``). Consult your
+``apt-get-install python-django-signup``). Consult your
 operating system's package list for details, but be aware that
 third-party distributions may be providing older versions of
-django-registration, and so you should consult the documentation which
+django-signup, and so you should consult the documentation which
 comes with your operating system's package.
 
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you prefer not to use an automated package installer, you can
-download a copy of django-registration and install it manually. The
-latest release package can be downloaded from `django-registration's
+download a copy of django-signup and install it manually. The
+latest release package can be downloaded from `django-signup's
 listing on the Python Package Index
-<http://pypi.python.org/pypi/django-registration/>`_.
+<http://pypi.python.org/pypi/django-signup/>`_.
 
 Once you've downloaded the package, unpack it (on most operating
 systems, simply double-click; alternately, type ``tar zxvf
-django-registration-0.8.tar.gz`` at a command line on Linux, Mac OS X
+django-signup-0.8.tar.gz`` at a command line on Linux, Mac OS X
 or other Unix-like systems). This will create the directory
-``django-registration-0.8``, which contains the ``setup.py``
+``django-signup-0.8``, which contains the ``setup.py``
 installation script. From a command line in that directory, type::
 
     python setup.py install
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you'd like to try out the latest in-development code, you can
-obtain it from the django-registration repository, which is hosted at
+obtain it from the django-signup repository, which is hosted at
 `Bitbucket <http://bitbucket.org/>`_ and uses `Mercurial
 <http://www.selenic.com/mercurial/wiki/>`_ for version control. To
 obtain the latest code and documentation, you'll need to have
 Mercurial installed, at which point you can type::
 
-    hg clone http://bitbucket.org/ubernostrum/django-registration/
+    hg clone http://bitbucket.org/ubernostrum/django-signup/
 
 You can also obtain a copy of a particular release of
-django-registration by specifying the ``-r`` argument to ``hg clone``;
+django-signup by specifying the ``-r`` argument to ``hg clone``;
 each release is given a tag of the form ``vX.Y``, where "X.Y" is the
 release number. So, for example, to check out a copy of the 0.8
 release, type::
 
-    hg clone -r v0.8 http://bitbucket.org/ubernostrum/django-registration/
+    hg clone -r v0.8 http://bitbucket.org/ubernostrum/django-signup/
 
-In either case, this will create a copy of the django-registration
+In either case, this will create a copy of the django-signup
 Mercurial repository on your computer; you can then add the
-``django-registration`` directory inside the checkout your Python
+``django-signup`` directory inside the checkout your Python
 import path, or use the ``setup.py`` script to install as a package.
 
 
 Basic configuration and use
 ---------------------------
 
-Once installed, you can add django-registration to any Django-based
+Once installed, you can add django-signup to any Django-based
 project you're developing. The default setup will enable user
-registration with the following workflow:
+signup with the following workflow:
 
 1. A user signs up for an account by supplying a username, email
    address and password.
 Required settings
 ~~~~~~~~~~~~~~~~~
 
-Begin by adding ``registration`` to the ``INSTALLED_APPS`` setting of
+Begin by adding ``signup`` to the ``INSTALLED_APPS`` setting of
 your project, and specifying one additional setting:
 
 ``ACCOUNT_ACTIVATION_DAYS``
     This is the number of days users will have to activate their
     accounts after registering. If a user does not activate within
     that period, the account will remain permanently inactive and may
-    be deleted by maintenance scripts provided in django-registration.
+    be deleted by maintenance scripts provided in django-signup.
 
 For example, you might have something like the following in your
 Django settings file::
     INSTALLED_APPS = (
         'django.contrib.auth',
         'django.contrib.sites',
-        'registration',
+        'signup',
         # ...other installed applications...
     )
     
 
 The :ref:`default backend <default-backend>` includes a Django
 ``URLconf`` which sets up URL patterns for :ref:`the views in
-django-registration <views>`, as well as several useful views in
+django-signup <views>`, as well as several useful views in
 ``django.contrib.auth`` (e.g., login, logout, password
 change/reset). This ``URLconf`` can be found at
-``registration.backends.default.urls``, and so can simply be included
+``signup.backends.default.urls``, and so can simply be included
 in your project's root URL configuration. For example, to place the
 URLs under the prefix ``/accounts/``, you could add the following to
 your project's root ``URLconf``::
 
-    (r'^accounts/', include('registration.backends.default.urls')),
+    (r'^accounts/', include('signup.backends.default.urls')),
 
 Users would then be able to register by visiting the URL
 ``/accounts/register/``, login (once activated) at
 ~~~~~~~~~~~~~~~~~~
 
 In the default setup, you will need to create several templates
-required by django-registration, and possibly additional templates
+required by django-signup, and possibly additional templates
 required by views in ``django.contrib.auth``. The templates requires
-by django-registration are as follows; note that, with the exception
+by django-signup are as follows; note that, with the exception
 of the templates used for account activation emails, all of these are
 rendered using a ``RequestContext`` and so will also receive any
 additional variables provided by `context processors
 <http://docs.djangoproject.com/en/dev/ref/templates/api/#id1>`_.
 
-**registration/registration_form.html**
+**signup/signup_form.html**
 
 Used to show the form users will fill out to register. By default, has
 the following context:
 
 ``form``
-    The registration form. This will be an instance of some subclass
+    The signup form. This will be an instance of some subclass
     of ``django.forms.Form``; consult `Django's forms documentation
     <http://docs.djangoproject.com/en/dev/topics/forms/>`_ for
     information on how to display this in a template.
 
-**registration/registration_complete.html**
+**signup/signup_complete.html**
 
-Used after successful completion of the registration form. This
+Used after successful completion of the signup form. This
 template has no context variables of its own, and should simply inform
 the user that an email containing account-activation information has
 been sent.
 
-**registration/activate.html**
+**signup/activate.html**
 
 Used if account activation fails. With the default setup, has the following context:
 
 ``activation_key``
     The activation key used during the activation attempt.
 
-**registration/activation_complete.html**
+**signup/activation_complete.html**
 
 Used after successful account activation. This template has no context
 variables of its own, and should simply inform the user that their
 account is now active.
 
-**registration/activation_email_subject.txt**
+**signup/activation_email_subject.txt**
 
 Used to generate the subject line of the activation email. Because the
 subject line of an email must be a single line of text, any output
     <http://docs.djangoproject.com/en/dev/ref/contrib/sites/>`_ for
     details regarding these objects' interfaces.
 
-**registration/activation_email.txt**
+**signup/activation_email.txt**
 
 Used to generate the body of the activation email. Should display a
 link the user can click to activate the account. This template has the
 Note that the templates used to generate the account activation email
 use the extension ``.txt``, not ``.html``. Due to widespread antipathy
 toward and interoperability problems with HTML email,
-django-registration defaults to plain-text email, and so these
+django-signup defaults to plain-text email, and so these
 templates should simply output plain text rather than HTML.
 
 To make use of the views from ``django.contrib.auth`` (which are set

File docs/release-notes.rst

 Release notes
 =============
 
-The |version| release of django-registration represents a complete
+The |version| release of django-signup represents a complete
 rewrite of the previous codebase, and as such introduces a number of
 new features and greatly enhances the flexibility and customizability
-of django-registration. This document summarizes those features; for a
+of django-signup. This document summarizes those features; for a
 list of changes which impact existing installations, consult :ref:`the
 upgrade guide <upgrade>`.
 
 ------------------
 
 The largest overall change consists of factoring out the logic of user
-registration into pluggable/swappable backend classes. The
-:ref:`registration views <views>` now accept a (required) argument,
+signup into pluggable/swappable backend classes. The
+:ref:`signup views <views>` now accept a (required) argument,
 ``backend``, which indicates the backend class to use, and that class
-has full control over the registration (and, if needed, activation)
+has full control over the signup (and, if needed, activation)
 process, including:
 
-* Determining whether registration will be allowed at all, on a
+* Determining whether signup will be allowed at all, on a
   per-request basis.
 
-* Specifying a form class to use for account registration.
+* Specifying a form class to use for account signup.
 
 * Implementing the actual process of account creation.
 
   what it will entail.
 
 * Specifying actions to take (e.g., redirects, automatic login, etc.)
-  following successful registration or activation.
+  following successful signup or activation.
 
 For full details, see the documentation for :ref:`the backend API
 <backend-api>`.
 
-The workflow used by previous releases of django-registration
-(two-step registration/activation) has been implemented using this
+The workflow used by previous releases of django-signup
+(two-step signup/activation) has been implemented using this
 system, and is shipped as :ref:`the default backend <default-backend>`
-in django-registration |version|.
+in django-signup |version|.
 
 
 Other new features
 ------------------
 
-An alternate :ref:`one-step registration system <simple-backend>` is
+An alternate :ref:`one-step signup system <simple-backend>` is
 provided, for use by sites which do not require a two-step
-registration/activation system.
+signup/activation system.
 
-During the registration and (optional) activation process,
+During the signup and (optional) activation process,
 :ref:`custom signals <signals>` are now sent, allowing easy injection
-of custom processing into the registration workflow without needing to
+of custom processing into the signup workflow without needing to
 write a full backend.
 
 The default backend now supplies several `custom admin actions
 <http://docs.djangoproject.com/en/dev/ref/contrib/admin/actions/>`_ to
-make the process of administering a site with django-registration
+make the process of administering a site with django-signup
 simpler.
 
-The :func:`~registration.views.activate` view now supplies any
+The :func:`~signup.views.activate` view now supplies any
 captured keyword arguments from the URL (in the case of the default
 backend, this is the activation key) to its template in case of
 unsuccessful activation; this greatly simplifies the process of

File docs/signals.rst

 .. _signals:
-.. module:: registration.signals
+.. module:: signup.signals
 
 
-Custom signals used by django-registration
+Custom signals used by django-signup
 ==========================================
 
-Much of django-registration's customizability comes through the
-ability to write and use :ref:`registration backends <backend-api>`
-implementing different workflows for user registration. However, there
+Much of django-signup's customizability comes through the
+ability to write and use :ref:`signup backends <backend-api>`
+implementing different workflows for user signup. However, there
 are many cases where only a small bit of additional logic needs to be
-injected into the registration process, and writing a custom backend
+injected into the signup process, and writing a custom backend
 to support this represents an unnecessary amount of work. A more
 lightweight customization option is provided through two custom
 signals which backends are required to send at specific points during
-the registration process; functions listening for these signals can
+the signup process; functions listening for these signals can
 then add whatever logic is needed.
 
 For general documentation on signals and the Django dispatcher,

File docs/simple-backend.rst

 .. _simple-backend:
-.. module:: registration.backends.simple
+.. module:: signup.backends.simple
 
 The "simple" (one-step) backend
 ===============================
 
 As an alternative to :ref:`the default backend <default-backend>`, and
-an example of writing :ref:`registration backends <backend-api>`,
-django-registration bundles a one-step registration system in
-``registration.backend.simple``. This backend's workflow is
+an example of writing :ref:`signup backends <backend-api>`,
+django-signup bundles a one-step signup system in
+``signup.backend.simple``. This backend's workflow is
 deliberately as simple as possible:
 
-1. A user signs up by filling out a registration form.
+1. A user signs up by filling out a signup form.
 
 2. The user's account is created and is active immediately, with no
    intermediate confirmation or activation step.
 -------------
 
 To use this backend, simply include the URLconf
-``registration.backends.simple.urls`` somewhere in your site's own URL
+``signup.backends.simple.urls`` somewhere in your site's own URL
 configuration. For example::
 
-    (r'^accounts/', include('registration.backends.simple.urls')),
+    (r'^accounts/', include('signup.backends.simple.urls')),
 
 No additional settings are required, but one optional setting is
 supported:
 
 ``REGISTRATION_OPEN``
     A boolean (either ``True`` or ``False``) indicating whether
-    registration of new accounts is currently permitted. A default of
+    signup of new accounts is currently permitted. A default of
     ``True`` will be assumed if this setting is not supplied.
 
-Upon successful registration, the default redirect is to the URL
+Upon successful signup, the default redirect is to the URL
 specified by the ``get_absolute_url()`` method of the newly-created
 ``User`` object; by default, this will be ``/users/<username>/``,
 although it can be overridden in either of two ways:
 
 1. Specify a custom URL pattern for the
-   :func:`~registration.views.register` view, passing the keyword
+   :func:`~signup.views.register` view, passing the keyword
    argument ``success_url``.
 
 2. Override the default ``get_absolute_url()`` of the ``User`` model
    documentation
    <http://docs.djangoproject.com/en/dev/ref/settings/#absolute-url-overrides>`_.
 
-The default form class used for account registration will be
-:class:`registration.forms.RegistrationForm`, although this can be
+The default form class used for account signup will be
+:class:`signup.forms.SignupForm`, although this can be
 overridden by supplying a custom URL pattern for the ``register()``
 view and passing the keyword argument ``form_class``.
 
 Note that because this backend does not use an activation step,
-attempting to use the :func:`~registration.views.activate` view with
+attempting to use the :func:`~signup.views.activate` view with
 this backend or calling the backend's ``activate()`` or
 ``post_activation_redirect()`` methods will raise
 ``NotImplementedError``.

File docs/upgrade.rst

 Upgrade guide
 =============
 
-The |version| release of django-registration represents a complete
+The |version| release of django-signup represents a complete
 rewrite of the previous codebase, and introduces several new features
 which greatly enhance the customizability and extensibility of
-django-registration. Whenever possible, changes were made in ways
+django-signup. Whenever possible, changes were made in ways
 which preserve backwards compatibility with previous releases, but
 some changes to existing installations will still be required in order
 to upgrade to |version|. This document provides a summary of those
 Django version requirement
 --------------------------
 
-As of |version|, django-registration requires Django 1.1 or newer;
-older Django releases will not work, as django-registration |version|
+As of |version|, django-signup requires Django 1.1 or newer;
+older Django releases will not work, as django-signup |version|
 takes advantage of several Django features which are only present as
 of 1.1.
 
 Backwards-incompatible changes
 ------------------------------
 
-If you're upgrading from an older release of django-registration, and
+If you're upgrading from an older release of django-signup, and
 if you were using the default setup (i.e., the included default
 URLconf and no custom URL patterns or custom arguments to views), most
 things will continue to work as normal (although you will need to
 create one new template; see the section on views below). However, the
 old default URLconf has been deprecated and will be removed in version
-1.0 of django-registration, so it is recommended that you begin
-migrating now. To do so, change any use of ``registration.urls`` to
-``registration.backends.default.urls``. For example, if you had the
+1.0 of django-signup, so it is recommended that you begin
+migrating now. To do so, change any use of ``signup.urls`` to
+``signup.backends.default.urls``. For example, if you had the
 following in your root URLconf::
 
-    (r'^accounts/', include('registration.urls')),
+    (r'^accounts/', include('signup.urls')),
 
 you should change it to::
 
-    (r'^accounts/', include('registration.backends.default.urls')),
+    (r'^accounts/', include('signup.backends.default.urls')),
 
-The older include will continue to work until django-registration 1.0;
+The older include will continue to work until django-signup 1.0;
 in |version| it raises a ``PendingDeprecationWarning`` (which is
 ignored by default in Python), in 0.9 it will raise
 ``DeprecationWarning`` (which will begin printing warning messages on
 import) and in 1.0 it will be removed entirely.
 
 
-Changes to registration views
+Changes to signup views
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-:ref:`The views used to handle user registration <views>` have changed
-significantly as of django-registration |version|. Both views now
+:ref:`The views used to handle user signup <views>` have changed
+significantly as of django-signup |version|. Both views now
 require the keyword argument ``backend``, which specifies the
-:ref:`registration backend <backend-api>` to use, and so any URL
+:ref:`signup backend <backend-api>` to use, and so any URL
 pattern for these views must supply that argument. The URLconf
 provided with :ref:`the default backend <default-backend>` properly
 passes this argument.
 
 The ``profile_callback`` argument of the
-:func:`~registration.views.register` view has been removed; the
+:func:`~signup.views.register` view has been removed; the
 functionality it provided can now be implemented easily via a custom
 backend, or by connecting listeners to :ref:`the signals sent during
-the registration process <signals>`.
+the signup process <signals>`.
 
-The :func:`~registration.views.activate` view now issues a redirect
+The :func:`~signup.views.activate` view now issues a redirect
 upon successful activation; in the default backend this is to the URL
-pattern named ``registration_activation_complete``; in the default
+pattern named ``signup_activation_complete``; in the default
 setup, this will redirect to a view which renders the template
-``registration/activation_complete.html``, and so this template should
+``signup/activation_complete.html``, and so this template should
 be present when using the default backend and default
 configuration. Other backends can specify the location to redirect to
 through their ``post_activation_redirect()`` method, and this can be
 keyword arguments captured in the URL and passed to the view.
 
 
-Changes to registration forms
+Changes to signup forms
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Previously, the form used to collect data during registration was
+Previously, the form used to collect data during signup was
 expected to implement a ``save()`` method which would create the new
 user account. This is no longer the case; creating the account is
 handled by the backend, and so any custom logic should be moved into a
 custom backend, or by connecting listeners to :ref:`the signals sent
-during the registration process <signals>`.
+during the signup process <signals>`.
 
 
-Changes to the :class:`~registration.models.RegistrationProfile` model
+Changes to the :class:`~signup.models.SignupProfile` model
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 The
-:meth:`~registration.models.RegistrationManager.create_inactive_user`
-method of :class:`~registration.models.RegistrationManager` now has an
+:meth:`~signup.models.SignupManager.create_inactive_user`
+method of :class:`~signup.models.SignupManager` now has an
 additional required argument: ``site``. This allows
-django-registration to easily be used regardless of whether
+django-signup to easily be used regardless of whether
 ``django.contrib.sites`` is installed, since a ``RequestSite`` object
 can be passed in place of a regular ``Site`` object.
 
-The :data:`~registration.signals.user_registered` signal is no longer
+The :data:`~signup.signals.user_registered` signal is no longer
 sent by ``create_inactive_user()``, and the
-:data:`~registration.signals.user_activated` signal is no longer sent
-by :meth:`~registration.models.RegistrationManager.activate_user`;
+:data:`~signup.signals.user_activated` signal is no longer sent
+by :meth:`~signup.models.SignupManager.activate_user`;
 these signals are now sent by the backend after these methods have
 been called. Note that :ref:`these signals <signals>` were added after
-the django-registration 0.7 release but before the refactoring which
+the django-signup 0.7 release but before the refactoring which
 introduced :ref:`the backend API <backend-api>`, so only installations
 which were tracking the in-development codebase will have made use of
 them.
 
 The sending of activation emails has been factored out of
 ``create_inactive_user()``, and now exists as the method
-:meth:`~registration.models.RegistrationProfile.send_activation_email`
-on instances of ``RegistrationProfile``.
+:meth:`~signup.models.SignupProfile.send_activation_email`
+on instances of ``SignupProfile``.

File docs/views.rst

 .. _views:
-.. module:: registration.views
+.. module:: signup.views
 
-Registration views
+Signup views
 ==================
 
 In order to allow users to register using whatever workflow is
-implemented by the :ref:`registration backend <backend-api>` in use,
-django-registration provides two views. Both are designed to allow
+implemented by the :ref:`signup backend <backend-api>` in use,
+django-signup provides two views. Both are designed to allow
 easy configurability without writing or rewriting view code.
 
 .. function:: activate(request, backend[, template_name[, success_url[, extra_context[, **kwargs]]]])
    ``success_url`` (see below).
 
    On unsuccessful activation, will render the template
-   ``registration/activate.html`` to display an error message; to
+   ``signup/activate.html`` to display an error message; to
    override thise, pass the argument ``template_name`` (see below).
 
    **Context**
    :type extra_context: dict
    :param template_name: Optional. A custom template name to use. If
       not specified, this will default to
-      ``registration/activate.html``.
+      ``signup/activate.html``.
    :type template_name: string
    :param **kwargs: Any keyword arguments captured from the URL, such
       as an activation key, which will be passed to the backend's
 
    Allow a new user to register an account.
 
-   The actual registration of the account will be delegated to the
+   The actual signup of the account will be delegated to the
    backend specified by the ``backend`` keyword argument. The backend
    is used as follows:
 
-   1. The backend's ``registration_allowed()`` method will be called,
-      passing the ``HttpRequest``, to determine whether registration
+   1. The backend's ``signup_allowed()`` method will be called,
+      passing the ``HttpRequest``, to determine whether signup
       of an account is to be allowed; if not, a redirect is issued to
-      a page indicating that registration is not permitted.
+      a page indicating that signup is not permitted.
 
-   2. The form to use for account registration will be obtained by
+   2. The form to use for account signup will be obtained by
       calling the backend's ``get_form_class()`` method, passing the
       ``HttpRequest``. To override this, pass the keyword argument
       ``form_class``.
       ``register()`` method, which should return a ``User`` object
       representing the new account.
 
-   4. Upon successful registration, the backend's
-      ``post_registration_redirect()`` method will be called, passing
+   4. Upon successful signup, the backend's
+      ``post_signup_redirect()`` method will be called, passing
       the ``HttpRequest`` and the new ``User``, to determine the URL
       to redirect to. To override this, pass the keyword argument
       ``success_url``.
    **Context**
 
    ``form``
-        The form instance being used to collect registration data.
+        The form instance being used to collect signup data.
 
    This view uses ``RequestContext``, so variables populated by
    context processors will also be present in the context.
 
    :param backend: The dotted Python path to the backend class to use.
    :type backend: string
-   :param disallowed_url: The URL to redirect to if registration is
-      not permitted (e.g., if registration is closed). This should be
+   :param disallowed_url: The URL to redirect to if signup is
+      not permitted (e.g., if signup is closed). This should be
       a string suitable for passing as the ``to`` argument to
       `Django's "redirect" shortcut
       <http://docs.djangoproject.com/en/dev/topics/http/shortcuts/#redirect>`_. If
-      not specified, this will default to ``registration_disallowed``.
+      not specified, this will default to ``signup_disallowed``.
    :type disallowed_url: string
    :param extra_context: Optionally, variables to add to the template
       context. Any callable object in this dictionary will be called
       to produce the final result which appears in the context.
    :type extra_context: dict
-   :param form_class: The form class to use for registration; this
+   :param form_class: The form class to use for signup; this
       should be some subclass of ``django.forms.Form``. If not
       specified, the backend's ``get_form_class()`` method will be
       called to obtain the form class.
    :type form_class: subclass of ``django.forms.Form``
    :param success_url: The URL to redirect to after successful
-      registration. This should be a string suitable for passing as
+      signup. This should be a string suitable for passing as
       the ``to`` argument to `Django's "redirect" shortcut
       <http://docs.djangoproject.com/en/dev/topics/http/shortcuts/#redirect>`_. If
-      not specified, the backend's ``post_registration_redirect()``
+      not specified, the backend's ``post_signup_redirect()``
       method will be called to obtain the URL.
    :type success_url: string
    :param template_name: Optional. A custom template name to use. If
       not specified, this will default to
-      ``registration/registration_form.html``.
+      ``signup/signup_form.html``.
    :type template_name: string

File registration/__init__.py

-VERSION = (0, 8, 0, 'alpha', 1)
-
-def get_version():
-    version = '%s.%s' % (VERSION[0], VERSION[1])
-    if VERSION[2]:
-        version = '%s.%s' % (version, VERSION[2])
-    if VERSION[3:] == ('alpha', 0):
-        version = '%s pre-alpha' % version
-    else:
-        if VERSION[3] != 'final':
-            version = "%s %s" % (version, VERSION[3])
-            if VERSION[4] != 0:
-                version = '%s %s' % (version, VERSION[4])
-    return version

File registration/admin.py

-from django.contrib import admin
-from django.contrib.sites.models import RequestSite
-from django.contrib.sites.models import Site
-from django.utils.translation import ugettext_lazy as _
-
-from registration.models import RegistrationProfile
-
-
-class RegistrationAdmin(admin.ModelAdmin):
-    actions = ['activate_users', 'resend_activation_email']
-    list_display = ('user', 'activation_key_expired')
-    raw_id_fields = ['user']
-    search_fields = ('user__username', 'user__first_name')
-
-    def activate_users(self, request, queryset):
-        """
-        Activates the selected users, if they are not alrady
-        activated.
-        
-        """
-        for profile in queryset:
-            RegistrationProfile.objects.activate_user(profile.activation_key)
-    activate_users.short_description = _("Activate users")
-
-    def resend_activation_email(self, request, queryset):
-        """
-        Re-sends activation emails for the selected users.
-
-        Note that this will *only* send activation emails for users
-        who are eligible to activate; emails will not be sent to users
-        whose activation keys have expired or who have already
-        activated.
-        
-        """
-        if Site._meta.installed:
-            site = Site.objects.get_current()
-        else:
-            site = RequestSite(request)
-
-        for profile in queryset:
-            if not profile.activation_key_expired():
-                profile.send_activation_email(site)
-    resend_activation_email.short_description = _("Re-send activation emails")
-
-
-admin.site.register(RegistrationProfile, RegistrationAdmin)

File registration/auth_urls.py

-"""
-URL patterns for the views included in ``django.contrib.auth``.
-
-Including these URLs (via the ``include()`` directive) will set up the
-following patterns based at whatever URL prefix they are included
-under:
-
-* User login at ``login/``.
-
-* User logout at ``logout/``.
-
-* The two-step password change at ``password/change/`` and
-  ``password/change/done/``.
-
-* The four-step password reset at ``password/reset/``,
-  ``password/reset/confirm/``, ``password/reset/complete/`` and
-  ``password/reset/done/``.
-
-The default registration backend already has an ``include()`` for
-these URLs, so under the default setup it is not necessary to manually
-include these views. Other backends may or may not include them;
-consult a specific backend's documentation for details.
-
-"""
-
-from django.conf.urls.defaults import *
-
-from django.contrib.auth import views as auth_views
-
-
-urlpatterns = patterns('',
-                       url(r'^login/$',
-                           auth_views.login,
-                           {'template_name': 'registration/login.html'},
-                           name='auth_login'),
-                       url(r'^logout/$',
-                           auth_views.logout,
-                           {'template_name': 'registration/logout.html'},
-                           name='auth_logout'),
-                       url(r'^password/change/$',
-                           auth_views.password_change,
-                           name='auth_password_change'),
-                       url(r'^password/change/done/$',
-                           auth_views.password_change_done,
-                           name='auth_password_change_done'),
-                       url(r'^password/reset/$',
-                           auth_views.password_reset,
-                           name='auth_password_reset'),
-                       url(r'^password/reset/confirm/(?P<uidb36>[0-9A-Za-z]+)-(?P<token>.+)/$',
-                           auth_views.password_reset_confirm,
-                           name='auth_password_reset_confirm'),
-                       url(r'^password/reset/complete/$',
-                           auth_views.password_reset_complete,
-                           name='auth_password_reset_complete'),
-                       url(r'^password/reset/done/$',
-                           auth_views.password_reset_done,
-                           name='auth_password_reset_done'),
-)

File registration/backends/__init__.py

-from django.core.exceptions import ImproperlyConfigured
-
-
-# Python 2.7 has an importlib with import_module; for older Pythons,
-# Django's bundled copy provides it.
-try:
-    from importlib import import_module
-except ImportError:
-    from django.utils.importlib import import_module
-
-def get_backend(path):
-    """
-    Return an instance of a registration backend, given the dotted
-    Python import path (as a string) to the backend class.
-
-    If the backend cannot be located (e.g., because no such module
-    exists, or because the module does not contain a class of the
-    appropriate name), ``django.core.exceptions.ImproperlyConfigured``
-    is raised.
-    
-    """
-    i = path.rfind('.')
-    module, attr = path[:i], path[i+1:]
-    try:
-        mod = import_module(module)
-    except ImportError, e:
-        raise ImproperlyConfigured('Error loading registration backend %s: "%s"' % (module, e))
-    try:
-        backend_class = getattr(mod, attr)
-    except AttributeError:
-        raise ImproperlyConfigured('Module "%s" does not define a registration backend named "%s"' % (module, attr))
-    return backend_class()

File registration/backends/default/__init__.py

-from django.conf import settings
-from django.contrib.sites.models import RequestSite
-from django.contrib.sites.models import Site
-
-from registration import signals
-from registration.forms import RegistrationForm
-from registration.models import RegistrationProfile
-
-
-class DefaultBackend(object):
-    """
-    A registration backend which follows a simple workflow:
-
-    1. User signs up, inactive account is created.
-
-    2. Email is sent to user with activation link.
-
-    3. User clicks activation link, account is now active.
-
-    Using this backend requires that
-
-    * ``registration`` be listed in the ``INSTALLED_APPS`` setting
-      (since this backend makes use of models defined in this
-      application).
-
-    * The setting ``ACCOUNT_ACTIVATION_DAYS`` be supplied, specifying
-      (as an integer) the number of days from registration during
-      which a user may activate their account (after that period
-      expires, activation will be disallowed).
-
-    * The creation of the templates
-      ``registration/activation_email_subject.txt`` and
-      ``registration/activation_email.txt``, which will be used for
-      the activation email. See the notes for this backends
-      ``register`` method for details regarding these templates.
-
-    Additionally, registration can be temporarily closed by adding the
-    setting ``REGISTRATION_OPEN`` and setting it to
-    ``False``. Omitting this setting, or setting it to ``True``, will
-    be interpreted as meaning that registration is currently open and
-    permitted.
-
-    Internally, this is accomplished via storing an activation key in
-    an instance of ``registration.models.RegistrationProfile``. See
-    that model and its custom manager for full documentation of its
-    fields and supported operations.
-    
-    """
-    def register(self, request, **kwargs):
-        """
-        Given a username, email address and password, register a new
-        user account, which will initially be inactive.
-
-        Along with the new ``User`` object, a new
-        ``registration.models.RegistrationProfile`` will be created,
-        tied to that ``User``, containing the activation key which
-        will be used for this account.
-
-        An email will be sent to the supplied email address; this
-        email should contain an activation link. The email will be
-        rendered using two templates. See the documentation for
-        ``RegistrationProfile.send_activation_email()`` for
-        information about these templates and the contexts provided to
-        them.
-
-        After the ``User`` and ``RegistrationProfile`` are created and
-        the activation email is sent, the signal
-        ``registration.signals.user_registered`` will be sent, with
-        the new ``User`` as the keyword argument ``user`` and the
-        class of this backend as the sender.
-
-        """
-        username, email, password = kwargs['username'], kwargs['email'], kwargs['password1']
-        if Site._meta.installed:
-            site = Site.objects.get_current()
-        else:
-            site = RequestSite(request)
-        new_user = RegistrationProfile.objects.create_inactive_user(username, email,
-                                                                    password, site)
-        signals.user_registered.send(sender=self.__class__,
-                                     user=new_user,
-                                     request=request)
-        return new_user
-