docs: Replace links to Django 1.11 docs with 2.2 links.

docs/production/management-commands.md

@@ -5,7 +5,7 @@ line.  To help with this, Zulip ships with over 100 command-line tools
 implemented using the [Django management commands
 framework][django-management].
 
-[django-management]: https://docs.djangoproject.com/en/1.11/ref/django-admin/#django-admin-and-manage-py
+[django-management]: https://docs.djangoproject.com/en/2.2/ref/django-admin/#django-admin-and-manage-py
 
 ## Running management commands
 

docs/subsystems/logging.md

@@ -179,7 +179,7 @@ a new view:
 * The time when the browser was idle again after switching views
   (intended to catch issues where we generate a lot of deferred work).
 
-[django-errors]: https://docs.djangoproject.com/en/1.11/howto/error-reporting/
+[django-errors]: https://docs.djangoproject.com/en/2.2/howto/error-reporting/
 [python-logging]: https://docs.python.org/3/library/logging.html
-[django-logging]: https://docs.djangoproject.com/en/1.11/topics/logging/
+[django-logging]: https://docs.djangoproject.com/en/2.2/topics/logging/
 [sentry]: https://sentry.io

docs/subsystems/management-commands.md

@@ -56,4 +56,4 @@ project.
   functions used by the UI are maintained to correctly live-update the
   UI if needed.
 
-[django-docs]: https://docs.djangoproject.com/en/1.11/howto/custom-management-commands/
+[django-docs]: https://docs.djangoproject.com/en/2.2/howto/custom-management-commands/

docs/subsystems/settings.md

@@ -25,7 +25,7 @@ from shareable configuration.
 ## Server settings
 
 Zulip uses the [Django settings
-system](https://docs.djangoproject.com/en/1.11/topics/settings/), which
+system](https://docs.djangoproject.com/en/2.2/topics/settings/), which
 means that the settings files are Python programs that set a lot of
 variables with all-capital names like EMAIL_GATEWAY_PATTERN.  You can
 access these anywhere in the Zulip Django code using e.g.:
@@ -123,7 +123,7 @@ accessed in initialization of Django (or Zulip) internals
 (e.g. `DATABASES`).  See the [Django docs on overriding settings in
 tests][django-test-settings] for more details.
 
-[django-test-settings]: https://docs.djangoproject.com/en/1.11/topics/testing/tools/#overriding-settings
+[django-test-settings]: https://docs.djangoproject.com/en/2.2/topics/testing/tools/#overriding-settings
 
 ## Realm settings
 

docs/tutorials/new-feature-tutorial.md

@@ -20,7 +20,7 @@ tests, use Django's tooling.
 Zulip's [directory structure](../overview/directory-structure.md)
 will also be helpful to review when creating a new feature. Many
 aspects of the structure will be familiar to Django developers. Visit
-[Django's documentation](https://docs.djangoproject.com/en/1.11/#index-first-steps)
+[Django's documentation](https://docs.djangoproject.com/en/2.2/#index-first-steps)
 for more information about how Django projects are typically
 organized.  And finally, the
 [message sending](../subsystems/sending-messages.md) documentation on

zproject/default_settings.py

@@ -312,7 +312,7 @@ STATSD_HOST = ''
 # Configuration for JWT auth.
 JWT_AUTH_KEYS = {}  # type: Dict[str, str]
 
-# https://docs.djangoproject.com/en/1.11/ref/settings/#std:setting-SERVER_EMAIL
+# https://docs.djangoproject.com/en/2.2/ref/settings/#std:setting-SERVER_EMAIL
 # Django setting for what from address to use in error emails.
 SERVER_EMAIL = ZULIP_ADMINISTRATOR
 # Django setting for who receives error emails.

zproject/prod_settings_template.py

@@ -42,7 +42,7 @@ EXTERNAL_HOST = 'zulip.example.com'
 # representing the host/domain names that your users can enter in
 # their browsers to access Zulip.  This is a security measure; for
 # details, see the Django documentation:
-# https://docs.djangoproject.com/en/1.11/ref/settings/#allowed-hosts
+# https://docs.djangoproject.com/en/2.2/ref/settings/#allowed-hosts
 #
 # Zulip automatically adds to this list 'localhost', '127.0.0.1', and
 # patterns representing EXTERNAL_HOST and subdomains of it.  If you are

zproject/settings.py

@@ -221,7 +221,7 @@ SILENCED_SYSTEM_CHECKS = [
     # `unique=True`.  For us this is `email`, and it's unique only per-realm.
     # Per Django docs, this is perfectly fine so long as our authentication
     # backends support the username not being unique; and they do.
-    # See: https://docs.djangoproject.com/en/1.11/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD
+    # See: https://docs.djangoproject.com/en/2.2/topics/auth/customizing/#django.contrib.auth.models.CustomUser.USERNAME_FIELD
     "auth.W004",
     # urls.W003 warns against using colons in the name in url(..., name) because colons are used
     # for namespaces. We need to override a url entry in the social: namespace, so we use