From 1024b5e74a7166313ad4e4975a15e90dccd3ec5f Mon Sep 17 00:00:00 2001 From: David Smith Date: Fri, 23 Jul 2021 07:48:16 +0100 Subject: Fixed 32956 -- Lowercased spelling of "web" and "web framework" where appropriate. --- docs/ref/models/fields.txt | 4 ++-- docs/ref/models/instances.txt | 2 +- docs/ref/models/querysets.txt | 6 +++--- 3 files changed, 6 insertions(+), 6 deletions(-) (limited to 'docs/ref/models') diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt index 9847560504..d7336d7001 100644 --- a/docs/ref/models/fields.txt +++ b/docs/ref/models/fields.txt @@ -857,7 +857,7 @@ takes a few steps: full path to a directory where you'd like Django to store uploaded files. (For performance, these files are not stored in the database.) Define :setting:`MEDIA_URL` as the base public URL of that directory. Make sure - that this directory is writable by the Web server's user account. + that this directory is writable by the web server's user account. #. Add the :class:`FileField` or :class:`ImageField` to your model, defining the :attr:`~FileField.upload_to` option to specify a subdirectory of @@ -900,7 +900,7 @@ Note that whenever you deal with uploaded files, you should pay close attention to where you're uploading them and what type of files they are, to avoid security holes. *Validate all uploaded files* so that you're sure the files are what you think they are. For example, if you blindly let somebody upload files, -without validation, to a directory that's within your Web server's document +without validation, to a directory that's within your web server's document root, then somebody could upload a CGI or PHP script and execute that script by visiting its URL on your site. Don't allow that. diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt index 6cf861638b..ea503b6c26 100644 --- a/docs/ref/models/instances.txt +++ b/docs/ref/models/instances.txt @@ -9,7 +9,7 @@ material presented in the :doc:`model ` and :doc:`database query ` guides, so you'll probably want to read and understand those documents before reading this one. -Throughout this reference we'll use the :ref:`example Weblog models +Throughout this reference we'll use the :ref:`example blog models ` presented in the :doc:`database query guide `. diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt index efa28ee145..4dafa7b3bf 100644 --- a/docs/ref/models/querysets.txt +++ b/docs/ref/models/querysets.txt @@ -9,7 +9,7 @@ material presented in the :doc:`model ` and :doc:`database query ` guides, so you'll probably want to read and understand those documents before reading this one. -Throughout this reference we'll use the :ref:`example Weblog models +Throughout this reference we'll use the :ref:`example blog models ` presented in the :doc:`database query guide `. @@ -2685,7 +2685,7 @@ For example, to delete all the entries in a particular blog:: # Delete all the entries belonging to this Blog. >>> Entry.objects.filter(blog=b).delete() - (4, {'weblog.Entry': 2, 'weblog.Entry_authors': 2}) + (4, {'blog.Entry': 2, 'blog.Entry_authors': 2}) By default, Django's :class:`~django.db.models.ForeignKey` emulates the SQL constraint ``ON DELETE CASCADE`` — in other words, any objects with foreign @@ -2696,7 +2696,7 @@ For example:: # This will delete all Blogs and all of their Entry objects. >>> blogs.delete() - (5, {'weblog.Blog': 1, 'weblog.Entry': 2, 'weblog.Entry_authors': 2}) + (5, {'blog.Blog': 1, 'blog.Entry': 2, 'blog.Entry_authors': 2}) This cascade behavior is customizable via the :attr:`~django.db.models.ForeignKey.on_delete` argument to the -- cgit v1.3