Update all refs to 5.1 -> 5.2 in the text

Author: hjwp

chapter_01.asciidoc

@@ -227,7 +227,7 @@ You have 18 unapplied migration(s). Your project may not work properly until
 you apply the migrations for app(s): admin, auth, contenttypes, sessions.
 Run 'python manage.py migrate' to apply them.
 March 17, 2023 - 18:07:30
-Django version 5.1.4, using settings 'superlists.settings'
+Django version 5.2.4, using settings 'superlists.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 ----

chapter_03_unit_test_first_view.asciidoc

@@ -282,7 +282,7 @@ and the view part is actually provided by the templates,
 but you can see the general idea is there!
 
 If you're interested, you can look up the finer points of the discussion
-https://docs.djangoproject.com/en/5.1/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names[in the Django FAQs].
+https://docs.djangoproject.com/en/5.2/faq/general/#django-appears-to-be-a-mvc-framework-but-you-call-the-controller-the-view-and-the-view-the-template-how-come-you-don-t-use-the-standard-names[in the Django FAQs].
 
 Irrespective of any of that, as with any web server, Django's main job is to
 decide what to do when a user asks for a particular URL on our site.
@@ -692,7 +692,7 @@ How can we write a test for URL resolution?
 At the moment we just test the view function directly by importing it and calling it.
 But we want to test more layers of the Django stack.
 Django, like most web frameworks, supplies a tool for doing just that, called the
-https://docs.djangoproject.com/en/5.1/topics/testing/tools/#the-test-client[Django Test Client].
+https://docs.djangoproject.com/en/5.2/topics/testing/tools/#the-test-client[Django Test Client].
 
 // CSANAD: it might be a little confusing first why we add a _unit_ test, considering this second
 //         test case is closer to a user's point of view. We could point out this to be one example
@@ -864,7 +864,7 @@ Let's go take a look:
 URL configuration for superlists project.
 
 The `urlpatterns` list routes URLs to views. For more information please see:
-    https://docs.djangoproject.com/en/5.1/topics/http/urls/
+    https://docs.djangoproject.com/en/5.2/topics/http/urls/
 Examples:
 Function views
     1. Add an import:  from my_app import views

chapter_04_philosophy_and_refactoring.asciidoc

@@ -399,7 +399,7 @@ Some people like to use another subfolder named after the app
 This is called "template namespacing".
 I figured it was overcomplicated for this small project, but it may be worth it on larger projects.
 There's more in the
-https://docs.djangoproject.com/en/5.1/intro/tutorial03/#write-views-that-actually-do-something[Django tutorial].]
+https://docs.djangoproject.com/en/5.2/intro/tutorial03/#write-views-that-actually-do-something[Django tutorial].]
 
 [role="sourcecode"]
 .lists/templates/home.html (ch04l002)

chapter_05_post_and_database.asciidoc

@@ -1052,9 +1052,9 @@ Django has many other field types, like `IntegerField`, `CharField`,
 `DateField`, and so on.  I've chosen `TextField` rather than `CharField` because
 the latter requires a length restriction, which seems arbitrary at this point.
 You can read more on field types in the Django
-https://docs.djangoproject.com/en/5.1/intro/tutorial02/#creating-models[tutorial]
+https://docs.djangoproject.com/en/5.2/intro/tutorial02/#creating-models[tutorial]
 and in the
-https://docs.djangoproject.com/en/5.1/ref/models/fields/[documentation].
+https://docs.djangoproject.com/en/5.2/ref/models/fields/[documentation].
 
 
 
@@ -1694,7 +1694,7 @@ will render with multiple `<tr>` rows, one for each item in the variable
 `items`.  Pretty neat!  I'll introduce a few more bits of Django template
 magic as we go, but at some point you'll want to go and read up on the rest of
 them in the
-https://docs.djangoproject.com/en/5.1/topics/templates/[Django docs].
+https://docs.djangoproject.com/en/5.2/topics/templates/[Django docs].
 
 Just changing the template doesn't get our tests to green; we need to actually
 pass the items to it from our home page view:
@@ -1762,7 +1762,7 @@ called 'db.sqlite3' in the base project directory:
 ----
 [...]
 # Database
-# https://docs.djangoproject.com/en/5.1/ref/settings/#databases
+# https://docs.djangoproject.com/en/5.2/ref/settings/#databases
 
 DATABASES = {
     "default": {

chapter_07_working_incrementally.asciidoc

@@ -1115,7 +1115,7 @@ TIP: This is another place to pay attention to trailing slashes, incidentally.
 // as we can have different methods on the same URL.
 // Also, the way our Django app is configured, it will automatically redirect to a URL
 // with the slash appended, so I'm not sure this makes much sense.
-// https://docs.djangoproject.com/en/5.1/ref/settings/#append-slash
+// https://docs.djangoproject.com/en/5.2/ref/settings/#append-slash
 
 Try running that:
 
@@ -2352,7 +2352,7 @@ which is what we were trying to do anyway:
 <1> There's our new form action.
 
 <2> `.item_set` is called a
-    https://docs.djangoproject.com/en/5.1/topics/db/queries/#following-relationships-backward[reverse lookup].
+    https://docs.djangoproject.com/en/5.2/topics/db/queries/#following-relationships-backward[reverse lookup].
     It's one of Django's incredibly useful bits of ORM that lets you look up an
     object's related items from a different table.
     ((("reverse lookups")))

chapter_08_prettification.asciidoc

@@ -649,7 +649,7 @@ It's defined in _settings.py_:
 [...]
 
 # Static files (CSS, JavaScript, Images)
-# https://docs.djangoproject.com/en/5.1/howto/static-files/
+# https://docs.djangoproject.com/en/5.2/howto/static-files/
 
 STATIC_URL = "static/"
 ----
@@ -696,7 +696,7 @@ To get it to work, we need to change it to:
 ====
 
 // DAVID: Django best practice would be to use the static tag instead.
-// https://docs.djangoproject.com/en/5.1/howto/static-files/#configuring-static-files
+// https://docs.djangoproject.com/en/5.2/howto/static-files/#configuring-static-files
 
 Now when `runserver` sees the request,
 it knows that it's for a static file because it begins with `/static/`.
@@ -729,7 +729,7 @@ That's because, although `runserver` automagically finds static files,
 Never fear, though:
 the Django developers have made an even more magical test class
 called `StaticLiveServerTestCase`
-(see https://docs.djangoproject.com/en/5.1/ref/contrib/staticfiles/#django.contrib.staticfiles.testing.StaticLiveServerTestCase[the docs]).
+(see https://docs.djangoproject.com/en/5.2/ref/contrib/staticfiles/#django.contrib.staticfiles.testing.StaticLiveServerTestCase[the docs]).
 
 // JAN: Maybe you could mention that StaticLiveServerTestCase inherits from LiveServerTestCase - so all previous should work + static files. After reading the name, I imagined StaticLiveServerTestCase as some special test class for testing only static-related stuff
 
@@ -1010,7 +1010,7 @@ making it relative to the location of the project base directory:
 [source,python]
 ----
 # Static files (CSS, JavaScript, Images)
-# https://docs.djangoproject.com/en/5.1/howto/static-files/
+# https://docs.djangoproject.com/en/5.2/howto/static-files/
 
 STATIC_URL = "static/"
 STATIC_ROOT = BASE_DIR / "static"

chapter_09_docker.asciidoc

@@ -882,7 +882,7 @@ System check identified no issues (0 silenced).
 
 You have 19 unapplied migration(s). Your project may not [...]
 [...]
-Django version 5.1.4, using settings 'superlists.settings'
+Django version 5.2.4, using settings 'superlists.settings'
 Starting development server at http://127.0.0.1:8000/
 Quit the server with CONTROL-C.
 ----

chapter_10_production_readiness.asciidoc

@@ -298,7 +298,7 @@ $ *pip freeze*
 asgiref==3.8.1
 attrs==23.2.0
 certifi==2024.2.2
-django==5.1.4
+django==5.2.4
 gunicorn==21.2.0
 h11==0.14.0
 idna==3.6
@@ -326,7 +326,7 @@ Django, Gunicorn and Whitenoise:
 [subs="specialcharacters,quotes"]
 ----
 $ *pip freeze | grep -i django*
-Django==5.1.[...]
+Django==5.2.[...]
 
 $ *pip freeze | grep -i django >> requirements.txt*
 $ *pip freeze | grep -i gunicorn >> requirements.txt*
@@ -341,7 +341,7 @@ That should give us a requirements.txt file that looks like this:
 ====
 [source,python]
 ----
-django==5.1.4
+django==5.2.4
 gunicorn==21.2.0
 whitenoise==6.6.0
 ----
@@ -459,7 +459,7 @@ _settings.py_ that we want to change for production:
   because that code might be visible to strangers.
   We'll want to generate a new, random one
   but then keep it the same for the foreseeable future
-  (find out more in the https://docs.djangoproject.com/en/5.1/topics/signing/[Django docs]).
+  (find out more in the https://docs.djangoproject.com/en/5.2/topics/signing/[Django docs]).
 
 Development, staging and production sites always have some differences
 in their configuration.
@@ -641,7 +641,7 @@ By default, when DEBUG=True, `ALLOWED_HOSTS` effectively allows _localhost_,
 our own machine, so that's why it was working OK until now.
 
 There's more information in the
-https://docs.djangoproject.com/en/5.1/ref/settings/#allowed-hosts[Django docs].
+https://docs.djangoproject.com/en/5.2/ref/settings/#allowed-hosts[Django docs].
 
 The upshot is that we need to adjust `ALLOWED_HOSTS` in _settings.py_.
 Let's use another environment variable for that:
@@ -860,7 +860,7 @@ but it's more of shock to see that they are no longer appearing in the terminal
 If you're like me you might find yourself wondering if we really _did_ see them earlier
 and starting to doubt your own sanity.
 But the explanation is that Django's
-https://docs.djangoproject.com/en/5.1/ref/logging/#default-logging-configuration[default logging configuration]
+https://docs.djangoproject.com/en/5.2/ref/logging/#default-logging-configuration[default logging configuration]
 changes when DEBUG is turned off.
 
 This means we need to interact with the standard library's `logging` module,

chapter_14_database_layer_validation.asciidoc

@@ -150,7 +150,7 @@ But all is not quite as it seems,
 because _this test should already pass_.
 
 If you take a look at the
-https://docs.djangoproject.com/en/5.1/ref/models/fields/#blank[docs for the Django model fields],
+https://docs.djangoproject.com/en/5.2/ref/models/fields/#blank[docs for the Django model fields],
 you'll see under _Field options_ that the default setting for _all_ fields is
 `blank=False`.
 Since TextField is a type of Field, it _should_ already disallow empty values.
@@ -289,7 +289,7 @@ Django models don't run full validation on save.
 ((("full_clean method")))
 Django does have a method to manually run full validation, however,
 called `full_clean` (more info in
-https://docs.djangoproject.com/en/5.1/ref/models/instances/#django.db.models.Model.full_clean[the docs]).
+https://docs.djangoproject.com/en/5.2/ref/models/instances/#django.db.models.Model.full_clean[the docs]).
 Let's swap that for the `.save()` and see if it works:
 
 
@@ -559,7 +559,7 @@ self.assertContains(response, expected_error)
 ====
 
 ...will show us the cause—Django has
-https://docs.djangoproject.com/en/5.1/ref/templates/builtins/#autoescape[HTML-escaped]
+https://docs.djangoproject.com/en/5.2/ref/templates/builtins/#autoescape[HTML-escaped]
 the apostrophe:
 
 [subs="specialcharacters,macros"]
@@ -1225,7 +1225,7 @@ a [keep-together]#parameter#:
 ====
 
 See the
-https://docs.djangoproject.com/en/5.1/topics/http/urls/#reverse-resolution-of-urls[Django
+https://docs.djangoproject.com/en/5.2/topics/http/urls/#reverse-resolution-of-urls[Django
 docs on reverse URL resolution] for more info. We run the tests again, and check that they all pass:
 
 [subs="specialcharacters,macros"]
@@ -1309,7 +1309,7 @@ AttributeError: 'List' object has no attribute 'get_absolute_url'
 The implementation is to use Django's `reverse` function, which
 essentially does the reverse of what Django normally does with _urls.py_
 (see the
-https://docs.djangoproject.com/en/5.1/topics/http/urls/#reverse-resolution-of-urls[docs]):
+https://docs.djangoproject.com/en/5.2/topics/http/urls/#reverse-resolution-of-urls[docs]):
 
 
 [role="sourcecode"]
@@ -1343,7 +1343,7 @@ def new_list(request):
 ====
 
 There's more info in the
-https://docs.djangoproject.com/en/5.1/topics/http/shortcuts/#redirect[Django docs].
+https://docs.djangoproject.com/en/5.2/topics/http/shortcuts/#redirect[Django docs].
 Quick check that the unit tests still pass:
 
 [subs="specialcharacters,macros"]

chapter_15_simple_form.asciidoc

@@ -249,7 +249,7 @@ and which fields we want it to use.
 like assigning sensible HTML form input types to different types of field,
 and applying default validation.
 Check out the
-https://docs.djangoproject.com/en/5.1/topics/forms/modelforms/[docs]
+https://docs.djangoproject.com/en/5.2/topics/forms/modelforms/[docs]
 for more info.
 
 We now have some different-looking form HTML:
@@ -1208,7 +1208,7 @@ using a form is a nice way of encapsulating that logic.
 // DAVID: I wonder if this is slightly missing the point.
 // Our functional tests here are very high level - using a headless browser.
 // But many developers use the Django test client
-// (https://docs.djangoproject.com/en/5.1/topics/testing/tools/#the-test-client)
+// (https://docs.djangoproject.com/en/5.2/topics/testing/tools/#the-test-client)
 // for this kind of thing, which doesn't have browser validation built in.
 // So we could use that if we really wanted to test the server side validation.
 //

chapter_16_advanced_forms.asciidoc

@@ -277,7 +277,7 @@ class Item(models.Model):
 ====
 
 You might want to take a quick peek at the
-https://docs.djangoproject.com/en/5.1/ref/models/options/[Django docs on model
+https://docs.djangoproject.com/en/5.2/ref/models/options/[Django docs on model
 `Meta` attributes] at this point.
 
 // DAVID: Should we get them to run the tests to see they pass?
@@ -644,9 +644,9 @@ AssertionError: True is not false
 
 The next step requires a little knowledge of Django's internals, but you
 can read up on it in the Django docs on
-https://docs.djangoproject.com/en/5.1/ref/models/instances/#validating-objects[model
+https://docs.djangoproject.com/en/5.2/ref/models/instances/#validating-objects[model
 validation] and
-https://docs.djangoproject.com/en/5.1/ref/forms/validation/[form validation].
+https://docs.djangoproject.com/en/5.2/ref/forms/validation/[form validation].
 
 Django uses a method called `validate_unique`, both on forms and models, and
 we can use both, in conjunction with the `instance` attribute:
@@ -1114,7 +1114,7 @@ in our test:
 // SEBASTIAN: If it's not too much of Django internals, maybe it's worth to mention
 //      how models instances are compared (or at least leave a link for curious readers)
 //      That said, if it wasn't shown before in the book
-//      https://docs.djangoproject.com/en/5.1/topics/db/queries/#comparing-objects
+//      https://docs.djangoproject.com/en/5.2/topics/db/queries/#comparing-objects
 
 That works; we get a fully passing unit test suite:
 

chapter_17_javascript.asciidoc

@@ -1432,7 +1432,7 @@ with the right selectors:
 ----
 ====
 // DAVID: Really we should be using the static tag here.
-// https://docs.djangoproject.com/en/5.1/howto/static-files/
+// https://docs.djangoproject.com/en/5.2/howto/static-files/
 
 Aaaand we run our FT:
 

chapter_19_spiking_custom_auth.asciidoc

@@ -5,7 +5,7 @@
 *******************************************************************************
 
 🚧 This chapter has recently been updated for the third edition.
-Its listings now use Django 5.1 and Python 3.13.
+Its listings now use Django 5.2 and Python 3.13.
 
 Please send feedback!  [email protected]
 
@@ -236,7 +236,7 @@ The login in theory will be something like this:
 // "...and if so, we authorize/approve the request to authenticate/log in as the
 // associated user"
 
-// https://docs.djangoproject.com/en/5.1/topics/auth/customizing/
+// https://docs.djangoproject.com/en/5.2/topics/auth/customizing/
 
 
 First let's prep an app for our accounts stuff:
@@ -345,7 +345,7 @@ with our 'base.html' in the real version.)
 
 ==== Email Server Config for Django
 
-The https://docs.djangoproject.com/en/5.1/topics/email/[django docs on email]
+The https://docs.djangoproject.com/en/5.2/topics/email/[django docs on email]
 explain how `send_mail()` works, as well as how you configure it
 by telling Django what email server to use,
 and how to authenticate with it.
@@ -541,7 +541,7 @@ we need to sort out user authentication in Django.
 // reason behind it.
 The first thing we'll need is a user model.
 I took a dive into the
-https://docs.djangoproject.com/en/5.1/topics/auth/customizing[Django
+https://docs.djangoproject.com/en/5.2/topics/auth/customizing[Django
 auth documentation] and tried to hack in the simplest possible one:
 
 [role="sourcecode"]
@@ -697,7 +697,7 @@ The `authenticate()` function invokes Django's authentication framework,
 which we configure using a "custom authentication backend",
 // CSANAD: why the quote marks? If it's because this is a reference to the
 // official Django docs, we could just make it a link instead to
-// https://docs.djangoproject.com/en/5.1/topics/auth/customizing/#writing-an-authentication-backend
+// https://docs.djangoproject.com/en/5.2/topics/auth/customizing/#writing-an-authentication-backend
 whose job it is to validate the UID and return a user with the right email.
 
 We could have done this stuff directly in the view,

chapter_20_mocking_1.asciidoc

@@ -618,7 +618,7 @@ We'll use Django's "messages framework",
 which is often used to display ephemeral "success" or "warning" messages
 to show the results of an action.
 Have a look at the
-https://docs.djangoproject.com/en/5.1/ref/contrib/messages/[django messages docs]
+https://docs.djangoproject.com/en/5.2/ref/contrib/messages/[django messages docs]
 if you haven't come across it already.
 
 Testing Django messages is a bit contorted--we have to pass `follow=True`

chapter_21_mocking_2.asciidoc

@@ -83,7 +83,7 @@ We call `django.contrib.auth.authenticate`, and then,
 if it returns a user, we call `django.contrib.auth.login`.
 
 TIP: This is a good time to check out the
-    https://docs.djangoproject.com/en/5.1/topics/auth/default/#how-to-log-a-user-in[Django docs on authentication]
+    https://docs.djangoproject.com/en/5.2/topics/auth/default/#how-to-log-a-user-in[Django docs on authentication]
     for a little more context.
     ((("Django framework", "documentation")))
 
@@ -1538,7 +1538,7 @@ element: #id_logout; [...]
 
 Implementing a logout URL is actually very simple:
 we can use Django's
-https://docs.djangoproject.com/en/5.1/topics/auth/default/#module-django.contrib.auth.views[built-in logout view],
+https://docs.djangoproject.com/en/5.2/topics/auth/default/#module-django.contrib.auth.views[built-in logout view],
 which clears down the user's session and redirects them to a page of our choice:
 
 [role="sourcecode small-code"]

chapter_22_fixtures_and_wait_decorator.asciidoc

@@ -86,7 +86,7 @@ class MyListsTest(FunctionalTest):
     primary key of the user object (which is actually the user's email address).
 // CSANAD: there is a different suggested way of importing SessionStore, using
 // the SESSION_ENGINE from the `settings`:
-// https://docs.djangoproject.com/en/5.1/topics/http/sessions/#using-sessions-out-of-views
+// https://docs.djangoproject.com/en/5.2/topics/http/sessions/#using-sessions-out-of-views
 //
 // Also, I would mention what the Django docs say about what the SessionStore is
 // or why it is useful ("when we need to use Django sessions manually, outside
@@ -216,7 +216,7 @@ as a way of temporarily keeping track of some state.
 This works for non–logged-in users too.
 Just use `request.session` inside any view, and it works as a dict.
 There's more information in the
-https://docs.djangoproject.com/en/5.1/topics/http/sessions/[Django docs on sessions].
+https://docs.djangoproject.com/en/5.2/topics/http/sessions/[Django docs on sessions].
 
 **********************************************************************