From 8f186daeabcd155a66f99319c7ca6ae9c9cac5f6 Mon Sep 17 00:00:00 2001
From: David Barnes <barnesdavidj@gmail.com>
Date: Mon, 11 Jul 2022 15:57:54 -0400
Subject: [PATCH] Use Grammarly to fix lots of english issues in documentation.
---
README.md | 24 ++++-----
docs/source/authorization/class_views.rst | 40 +++++++-------
docs/source/authorization/function_views.rst | 42 +++++++--------
docs/source/authorization/policies.rst | 56 ++++++++++----------
docs/source/configuration/admin.rst | 6 +--
docs/source/configuration/home.rst | 18 +++----
docs/source/configuration/menu.rst | 6 +--
docs/source/index.rst | 2 +-
docs/source/menu/admin.rst | 8 +--
docs/source/menu/advanced.rst | 6 +--
docs/source/menu/building_blocks.rst | 50 ++++++++---------
docs/source/menu/general_information.rst | 6 +--
docs/source/quickstart.rst | 8 +--
docs/source/templates/fields.rst | 30 +++++------
docs/source/templates/forms.rst | 4 +-
docs/source/templates/template_filters.rst | 20 +++----
docs/source/templates/template_tags.rst | 14 ++---
docs/source/templates/templates.rst | 12 ++---
18 files changed, 176 insertions(+), 176 deletions(-)
diff --git a/README.md b/README.md
index a32fe87..4344427 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ Features include:
* Automatic menu link hiding based on user permissions to views.
* Template filters to aid in manual styling.
* Template tags for form rendering that matches AdminLTE2.
-* Automatic form error and messages styling.
+* Automatic form error and message styling.
* [Font Awesome 4](https://fontawesome.com/v4/icons/)
& [Font Awesome 5](https://fontawesome.com/v5/search) integration.
* Highly configurable functionality, via project
@@ -47,7 +47,7 @@ The full documentation can be found on [Read The Docs](#) (coming soon).
---
:information_source: **NOTE**
- The **django_adminlte_2** app should be listed before any django apps so
+ The **django_adminlte_2** app should be listed before any Django apps so
that template overriding works correctly. Additionally, if you plan to
override any Django-AdminLTE-2 templates, they should be listed above
the **django_adminlte_2 app**.
@@ -75,7 +75,7 @@ The full documentation can be found on [Read The Docs](#) (coming soon).
---
:information_source: **NOTE**
- Django-AdminLTE-2 has been configured out of the box to get you setup
+ Django-AdminLTE-2 has been configured out of the box to get you set up
and running as fast as possible. As a result, the settings surrounding
authentication and authorization are not as strict as they could be.
We **strongly** encourage you to read the Authentication and Authorization
@@ -138,13 +138,13 @@ ADMINLTE2_HOME_ROUTE = 'django_adminlte_2:home'
```
Set the Logo text for your site. This will be shown in the top left of the top
-bar, when the side bar is expanded.
+bar when the sidebar is expanded.
```python
ADMINLTE2_LOGO_TEXT = 'My Awesome Site'
```
Set the small Logo text for your site. This will be shown in the top left of the
-top bar, when the side bar is collapsed.
+top bar when the sidebar is collapsed.
```python
ADMINLTE2_LOGO_TEXT = 'MAS'
```
@@ -158,7 +158,7 @@ ADMINLTE2_SKIN_CLASS = 'skin-green-light'
### Menu
-By default the main navigation (non-admin) menu is not part of the sidebar when
+By default, the main navigation (non-admin) menu is not part of the sidebar when
the user is viewing a
[Django Admin page](https://docs.djangoproject.com/en/dev/ref/contrib/admin/)
If you would like users to be able to see all of the main nav links regardless
@@ -176,7 +176,7 @@ regardless of what page they are on, set this value to ``True``.
ADMINLTE2_INCLUDE_ADMIN_NAV_ON_MAIN_PAGES = (True/False)
```
-By default there will be a implicit separator bar rendered between each menu
+By default, there will be an implicit separator bar rendered between each menu
group.
These groups include: **MENU_FIRST**, **MENU**, **MENU_LAST**, and the
**Admin Menu**.
@@ -189,7 +189,7 @@ ADMINLTE2_USE_MENU_GROUP_SEPARATOR = (True/False)
This setting is the definition for the main navigation menu.
There are a lot of options when creating this menu.
-See the [Read The Docs Menu page](#) for a detailed explanation on how to
+See the [Read The Docs Menu page](#) for a detailed explanation of how to
create this menu and all of the available options that can be used.
```python
ADMINLTE2_MENU = []
@@ -197,14 +197,14 @@ ADMINLTE2_MENU = []
### Admin
-By default the admin menu sidebar will not have a link to the admin index page.
+By default, the admin menu sidebar will not have a link to the admin index page.
If you would like to append a link to the admin index page in the sidebar,
set this value to ``True``.
```python
ADMINLTE2_INCLUDE_ADMIN_HOME_LINK = (True/False)
```
-By default Django-AdminLTE-2 will put the Apps on the Admin Index page
+By default, Django-AdminLTE-2 will put the Apps on the Admin Index page
into AdminLTE Info Boxes. Setting this to ``True`` will change that look
to the traditional Django list view, but still within the main AdminLTE site
styling.
@@ -217,10 +217,10 @@ ADMINLTE2_ADMIN_INDEX_USE_APP_LIST = (True/False)
Whether routes with no defined permission should be hidden unless added to a
Whitelist.
-If this setting is set to False, then all routes without a defined permission
+If this setting is set to False, then all routes without defined permissions
are still visible on the sidebar menu.
-If this setting is set to True, then all routes without a defined permission
+If this setting is set to True, then all routes without defined permissions
are hidden on the sidebar menu unless the route is found in the
``ADMINLTE2_STRICT_POLICY_WHITELIST`` setting.
```python
diff --git a/docs/source/authorization/class_views.rst b/docs/source/authorization/class_views.rst
index d77f759..c2b00b0 100644
--- a/docs/source/authorization/class_views.rst
+++ b/docs/source/authorization/class_views.rst
@@ -34,10 +34,10 @@ Login Required Mixin
This mixin will enforce that a user is logged into the system before they
can access the view. Django's default
`LoginRequiredMixin <https://docs.djangoproject.com/en/dev/topics/auth/default/#the-loginrequired-mixin>`_
-is used behind the scenes and is only recreated in this package in order to add
+is used behind the scenes and is only recreated in this package to add
the magic of automatic sidebar link rendering.
-When using this mixin on a class based view, if the user in not logged in,
+When using this mixin on a class based view, if the user is not logged in,
the user will not be able to access this view nor will they see a sidebar menu
entry that maps to this view. However, if the user is logged in,
they will see the sidebar link and have access.
@@ -62,7 +62,7 @@ Permission Required Mixin
This mixin will enforce that a user has either all or one of a list of
permissions before they can access the view. Django's default
`PermissionRequired <https://docs.djangoproject.com/en/dev/topics/auth/default/#the-permissionrequiredmixin-mixin>`_
-is used behind the scenes and is only recreated in this package in order to add
+is used behind the scenes and is only recreated in this package to add
the magic of automatic sidebar link rendering.
There are two class attributes used in conjunction with this mixin.
@@ -99,7 +99,7 @@ Permission Required One Attribute
.. note::
Django does not provide a similar class level attribute by default.
- This attribute and it's functionality is exclusive to this package.
+ This attribute and its functionality are exclusive to this package.
.. tip::
@@ -134,7 +134,7 @@ Mixin Examples
Loose Mixin Example
-------------------
-In this example there are five routes, views, and sidebar entries. To
+In this example, there are five routes, views, and sidebar entries. To
demonstrate how our package works, we intentionally mess up the **Sample 2**
permissions at first, then show how to correct it. The views are as follows:
@@ -144,7 +144,7 @@ permissions at first, then show how to correct it. The views are as follows:
* **Sample 1** - Requires two permissions (and thus being logged in) to see and
access.
* **Sample 2** - Should require at least one of the listed permissions
- (and being logged in) to see and access. But we intentionally
+ (and be logged in) to see and access. But we intentionally
forgot to add that permission to demonstrate what will happen.
* **Demo CSS** - Should be visible to all users, regardless of being logged in
or having permission.
@@ -152,7 +152,7 @@ permissions at first, then show how to correct it. The views are as follows:
.. note::
In the below files, we have purposely made a mistake in regards to the
- **Sample2** view in order to not only demonstrate how the various files and
+ **Sample2** view to not only demonstrate how the various files and
contents work, but also to show what sort of side effects to expect when
using the **Loose Policy**.
@@ -162,7 +162,7 @@ permissions at first, then show how to correct it. The views are as follows:
.. important::
- For the purposes of this example we have turned off the global
+ For this example, we have turned off the global
:ref:`authorization/policies:login required` setting and instead choose
to define whether or not a view requires being logged in directly on
the view rather than globally. This way we can demonstrate all three options
@@ -303,10 +303,10 @@ permissions at first, then show how to correct it. The views are as follows:
We wanted to prevent the **Sample2** view from being accessed by people that
do not have at least one permission, but forgot to add that to our view.
- Because we are using a Loose policy, everyone can see and have access this
+ Because we are using a Loose policy, everyone can see and have access to this
view. This is the **"Loose"** part of the loose policy as it defaults to
everyone being able to see every view unless a permission is explicitly
- set on that view to add security.
+ set on that view.
Let's fix our mistake so that **Sample2** is protected and see the difference.
@@ -361,9 +361,9 @@ The pages in our example are now displaying as they're supposed to be.
Strict Mixin Example
--------------------
-In this example there are five routes, views, and sidebar entries. To
+In this example, there are five routes, views, and sidebar entries. To
demonstrate how our package works, we intentionally mess up the **Sample2** and
-**Demo CSS** routes at first, then show how to correct it. The views are as
+**Demo CSS** routes at first, then show how to correct them. The views are as
follows:
* **Home** - Should be shown to all users, regardless of being logged in or
@@ -372,27 +372,27 @@ follows:
* **Sample 1** - Requires two permissions (and thus being logged in) to see and
access.
* **Sample 2** - Should require at least one of the listed permissions
- (and being logged in) to see and access. But we intentionally
+ (and be logged in) to see and access. But we intentionally
forgot to add that permission to demonstrate what will happen.
* **Demo CSS** - Should be visible to all users, regardless of being logged in
or having permission. But we intentionally forgot to add that view's route to
the
:ref:`configuration/authorization:ADMINLTE2_STRICT_POLICY_WHITELIST`
- in order to demonstrate what will happen.
+ to demonstrate what will happen.
.. note::
In the below files, we have purposely made a mistake in regards to the
- **Sample2** and **Demo CSS** views in order to not only demonstrate how the
+ **Sample2** and **Demo CSS** views to not only demonstrate how the
various files and contents work, but also to show what sort of side effects
to expect when using the **Strict Policy**.
- Below this initial attempt we correct our mistake and show the proper
+ Below this initial attempt, we correct our mistake and show the proper
configuration as well as what users will see.
.. important::
- For the purposes of this example we have turned off the global
+ For this example, we have turned off the global
:ref:`authorization/policies:login required` setting and instead choose
to define whether or not a view requires being logged in directly on
the view rather than globally. This way we can demonstrate all three of
@@ -511,7 +511,7 @@ follows:
As seen in the following screenshots, the **Home** route still works and
the user still has access to it.
- This is because the **Home** route is one of the routes that is
+ This is because the **Home** route is one of the routes that are
automatically included as part of the
:ref:`configuration/authorization:adminlte2_strict_policy_whitelist`.
For more information about the automatically included routes, check out
@@ -569,8 +569,8 @@ follows:
In the case of **Sample2**, we are going to add the missing permissions that
we accidentally omitted earlier.
-Let's fix our mistake so that **Demo CSS** and **Sample2** are visible to who
-they are supposed to be.
+Let's fix our mistake so that **Demo CSS** and **Sample2** are visible to those
+who they are supposed to be.
.. _strict_mixin_fixed_settings.py:
diff --git a/docs/source/authorization/function_views.rst b/docs/source/authorization/function_views.rst
index 7b92fdd..f52aecb 100644
--- a/docs/source/authorization/function_views.rst
+++ b/docs/source/authorization/function_views.rst
@@ -42,8 +42,8 @@ Login Required Decorator
This decorator will enforce that a user is logged into the system before they
can access the view. Django's default
`login_required <https://docs.djangoproject.com/en/dev/topics/auth/default/#the-login-required-decorator>`_
-decorator is used behind the scenes and is only recreated in this package in
-order to add the magic of automatic sidebar link rendering.
+decorator is used behind the scenes and is only recreated in this package
+to add the magic of automatic sidebar link rendering.
When using this decorator on a function view, if the user is not logged in,
the user will not be able to access this view, nor will they see a sidebar menu
@@ -69,8 +69,8 @@ Permission Required Decorator
This decorator will list all required permissions for the view. Django's default
`permission_required <https://docs.djangoproject.com/en/dev/topics/auth/default/#the-permission-required-decorator>`_
-decorator is used behind the scenes and is only recreated in this package in
-order to add the magic of automatic sidebar link rendering.
+decorator is used behind the scenes and is only recreated in this package
+to add the magic of automatic sidebar link rendering.
When using this decorator on a function view, if the user does not have all of
the permissions that we define in this decorator, the user will not be able to
@@ -98,7 +98,7 @@ Permission Required One Decorator
``@permission_required_one``
This decorator will list the permissions that a user must have at least one
-of in order to access the view and see the associated sidebar Link.
+of to be able to access the view and see the associated sidebar link.
.. note::
@@ -113,8 +113,8 @@ permissions, they will see the sidebar link and have access.
.. tip::
- This decorator is good when you have a landing page for a section of your
- site and don't care whether the user can only read or has full edit
+ This decorator is good when you have a landing page for a section of
+ your site and don't care whether the user can only read or has full edit
permissions. Either one should allow the user to see the sidebar link and
gain access to the landing page where further restrictions can be used
as needed.
@@ -139,7 +139,7 @@ Decorator Examples
Loose Decorator Example
-----------------------
-In this example there are five routes, views, and sidebar entries. To
+In this example, there are five routes, views, and sidebar entries. To
demonstrate how our package works, we intentionally mess up the **Sample 2**
permissions at first, then show how to correct it. The views are as follows:
@@ -149,7 +149,7 @@ permissions at first, then show how to correct it. The views are as follows:
* **Sample 1** - Requires two permissions (and thus being logged in) to see and
access.
* **Sample 2** - Should require at least one of the listed permissions
- (and being logged in) to see and access. But we intentionally
+ (and be logged in) to see and access. But we intentionally
forgot to add that permission to demonstrate what will happen.
* **Demo CSS** - Should be visible to all users regardless of being logged in
or having permission.
@@ -159,7 +159,7 @@ Below is all the code required to generate these views.
.. note::
In the below files, we have purposely made a mistake in regards to the
- **Sample2** view in order to not only demonstrate how the various files and
+ **Sample2** view to not only demonstrate how the various files and
contents work, but also to show what sort of side effects to expect when
using the **Loose Policy**.
@@ -168,7 +168,7 @@ Below is all the code required to generate these views.
.. important::
- For the purposes of this example we have turned off the global
+ For this example, we have turned off the global
:ref:`authorization/policies:login required` setting and instead choose
to define whether or not a view requires being logged in directly on
the view rather than globally. This way we can demonstrate all three of
@@ -357,9 +357,9 @@ The pages in our example are now displaying as they're supposed to be.
Strict Decorator Example
------------------------
-In this example there are five routes, views, and sidebar entries. To
+In this example, there are five routes, views, and sidebar entries. To
demonstrate how our package works, we intentionally mess up the **Sample2** and
-**Demo CSS** routes at first, then show how to correct it. The views are as
+**Demo CSS** routes at first, then show how to correct them. The views are as
follows:
* **Home** - Should be visible to all users, regardless of being logged in or
@@ -368,29 +368,29 @@ follows:
* **Sample 1** - Requires two permissions (and thus being logged in) to see and
access.
* **Sample 2** - Should require at least one of the listed permissions
- (and being logged in) to see and access. But we intentionally
+ (and be logged in) to see and access. But we intentionally
forgot to add that permission to demonstrate what will happen.
* **Demo CSS** - Should be visible to all users, regardless of being logged in
or having permission. But we intentionally forgot to add that view's route to
the
:ref:`configuration/authorization:ADMINLTE2_STRICT_POLICY_WHITELIST`
- in order to demonstrate what will happen.
+ to demonstrate what will happen.
Below is all the code required to generate these views.
.. note::
In the below files, we have purposely made a mistake in regards to the
- **Sample2** and **Demo CSS** views in order to not only demonstrate how the
+ **Sample2** and **Demo CSS** views to not only demonstrate how the
various files and contents work, but also to show what sort of side effects
to expect when using the **Strict Policy**.
- Below this initial attempt we correct our mistake and show the proper
+ Below this initial attempt, we correct our mistake and show the proper
configuration as well as what users will see.
.. important::
- For the purposes of this example we have turned off the global
+ For this example, we have turned off the global
:ref:`authorization/policies:login required` setting and instead choose
to define whether or not a view requires being logged in directly on
the view rather than globally. This way we can demonstrate all three of
@@ -505,7 +505,7 @@ Below is all the code required to generate these views.
As seen in the following screenshots, the **Home** route still works and
the user still has access to it.
- This is because the **Home** route is one of the routes that is
+ This is because the **Home** route is one of the routes that are
automatically included as part of the
:ref:`configuration/authorization:adminlte2_strict_policy_whitelist`.
@@ -560,8 +560,8 @@ Below is all the code required to generate these views.
In the case of **Sample2**, we are going to add the missing permissions that
we accidentally omitted earlier.
-Let's fix our mistake so that **Demo CSS** and **Sample2** are visible to who
-they are supposed to be.
+Let's fix our mistake so that **Demo CSS** and **Sample2** are visible to those
+who they are supposed to be.
.. _strict_decorator_fixed_settings.py:
diff --git a/docs/source/authorization/policies.rst b/docs/source/authorization/policies.rst
index 09184db..b86bbc3 100644
--- a/docs/source/authorization/policies.rst
+++ b/docs/source/authorization/policies.rst
@@ -33,7 +33,7 @@ or anonymous.
Setting up authentication for the package requires choosing if your site will:
-* Require users be logged in to gain access to the majority of site views.
+* Require users to be logged in to gain access to the majority of site views.
* Allow anonymous users to see site views by default (this is the default Django
handling).
@@ -57,7 +57,7 @@ file to ``True``.
ADMINLTE2_USE_LOGIN_REQUIRED = True
When enabled, the included middleware will redirect all requests made by an
-anonymous user to the login page unless the url that they are trying to access
+anonymous user to the login page unless the URL that they are trying to access
is explicitly listed in a whitelist.
The default whitelist contains the following standard anonymous routes:
@@ -69,7 +69,7 @@ The default whitelist contains the following standard anonymous routes:
* password_reset_complete
If you would like to add additional routes to this list, you can do so by
-adding either the route name or url for the endpoint to the
+adding either the route name or URL for the endpoint to the
``ADMINLTE2_LOGIN_EXEMPT_WHITELIST`` setting in your ``settings.py`` file.
**settings.py**
@@ -83,7 +83,7 @@ adding either the route name or url for the endpoint to the
.. tip::
If the majority of your routes do not require being logged in and you only
- have a handful that do, it is better to leave the
+ have a handful of routes that do, it is better to leave the
``ADMINLTE2_USE_LOGIN_REQUIRED`` undefined or set to ``False`` and instead
use the
:ref:`authorization/function_views:login required decorator` or
@@ -106,11 +106,11 @@ provided by this package to set permissions on various views.
Setting the permissions on the view with the
:ref:`authorization/function_views:Decorators` and
:ref:`authorization/class_views:Mixins`
-provided by this package will still prevent a user from accessing a view that
-they do not have permission to access. Just like the ones provided by
+provided by this package will prevent a user from accessing a view that
+they do not have permission to. Just like the ones provided by
`Django <https://docs.djangoproject.com/en/dev/topics/auth/default/#limiting-access-to-logged-in-users>`_.
But they will additionally dynamically show/hide any menu sidebar links for the
-protected view, in the provided AdminLTE menus.
+protected view, in the, provided AdminLTE menus.
.. note::
@@ -127,7 +127,7 @@ Choosing a Policy
-----------------
The first step in using and configuring authorization for views and sidebar
-menu links is to determine what general policy you want to adhere to.
+menu links are to determine what general policy you want to adhere to.
Regardless of whether you have the global
:ref:`authorization/policies:login required`
turned on or off, knowing what type of policy you want to achieve is critical.
@@ -139,7 +139,7 @@ Your choices are:
* Majority of sidebar links and associated views are visible to all users.
* Sidebar links and associated views will still be visible and accessible
- if you set a required permission or the login required criteria on that
+ if you set required permissions or the login required criteria on that
route's view and that user meets the required criteria to access that
view.
* Sidebar links and associated views will be hidden / blocked if you set a
@@ -152,7 +152,7 @@ Your choices are:
setting turned off and you opt for the
:ref:`authorization/policies:Loose Policy`
you will be allowing all users, both logged in and anonymous, access
- to every view in your site that does not have a required permission
+ to every view on your site that does not have a required permission
or the login required criteria defined on the view.
@@ -161,7 +161,7 @@ Your choices are:
* Majority of sidebar links and associated views are hidden to all users.
* Sidebar links and associated views will become visible and accessible if
- you set a required permission or the login required criteria on a route's
+ you set required permissions or the login required criteria on a route's
view and the user meets the required criteria.
* Sidebar links and associated views will become visible and accessible if
you put the route in an explicit whitelist defined in the settings.
@@ -169,13 +169,13 @@ Your choices are:
.. note::
With the :ref:`authorization/policies:Strict Policy`, if you forget to
- add a permission to a view, the view will be inaccessible to everyone
- except superusers.
- This is a good way to ensure that you don't accidentally create a
- feature that everyone automatically has access to.
- You have to explicitly think about what permission is required for the
- feature, set it on the view, and give the permission to the users that
- need it before anyone can gain access to it.
+ add permissions to a view, the view will be inaccessible to everyone
+ except for superusers.
+ This is a good way to ensure that you don't accidentally create
+ features that everyone automatically has access to.
+ You have to explicitly think about what permissions are required for
+ each feature, set them on the view, and then assign the permissions to
+ the users that need them before anyone can gain access to it.
Once you have determined what general policy you want to follow, use
the corresponding section to properly set up and configure authorization.
@@ -190,7 +190,7 @@ by default.
When enabled, all views that do not use one of the included
:ref:`authorization/function_views:Decorators` or
:ref:`authorization/class_views:Mixins` will be accessible to everyone.
-Additionally, if the sidebar menu contains a entry for the view, the link to
+Additionally, if the sidebar menu contains an entry for the view, the link to
that view will be visible to everyone.
Views will only be hidden if one of the
@@ -251,9 +251,9 @@ as the :ref:`configuration/home:adminlte2_home_route`:
The Home route is included in the whitelist because we believe that there
should be at least one view that a logged in user can access after logging
in.
- Even if they do not have any permissions to see anything else in the site.
+ Even if they do not have any required permissions to see anything else on the site.
The alternative would be to send them to the login page after a successful
- log in, which we believe, even with messages, would be confusing to the
+ login, which we believe, even with messages, would be confusing to the
user.
Additionally, if a view does have required permissions or login required
@@ -286,7 +286,7 @@ the specific settings in settings.py mentioned below.
:ref:`authorization/class_views:Strict Mixin Example` section to add
view permissions that require permission to access.
-4. Add any routes that do not require a specific permission and should
+4. Add any routes that do not require specific permissions and should
be available to everyone to the ``ADMINLTE2_STRICT_POLICY_WHITELIST``
in ``settings.py``
@@ -295,7 +295,7 @@ the specific settings in settings.py mentioned below.
.. code:: python
ADMINLTE2_STRICT_POLICY_WHITELIST = [
- 'tutorial' # url_name of route to tutorial view.
+ 'tutorial' # url_name of the route to the tutorial view.
]
Handling 404s and Permission Denied
@@ -304,7 +304,7 @@ Handling 404s and Permission Denied
This section shows a common way that you could handle 404 errors and
a Permission Denied exception being thrown (403).
-For starters, Permission Denied can be raised one of two ways.
+For starters, Permission Denied can be raised in one of two ways.
1. You are using the :ref:`authorization/policies:strict policy`
and you have not defined any permissions on a view that a user is
@@ -315,7 +315,7 @@ For starters, Permission Denied can be raised one of two ways.
When this happens, we believe that it is good to do something different than
the default behavior that Django provides of just returning a 403 error.
-In fact, we believe that it may be better to handle it as if it were a 404 so
+We believe that it may be better to handle it as if it were a 404 so
that users are unaware that the location they are trying to access has an
actual endpoint that they do not have permission to access. It will make it
harder for bad actors to phish for endpoints that they should not know exist.
@@ -323,7 +323,7 @@ harder for bad actors to phish for endpoints that they should not know exist.
This package comes with a view that can be used for 404s and optionally 403s.
This view will add a warning message via the
`Django messages framework <https://docs.djangoproject.com/en/dev/ref/contrib/messages/>`_
-indicating that the page does not exist as well as add a debug message with
+indicating that the page does not exist as well as adding a debug message with
specifics about what caused the exception. It then redirects to the
:ref:`configuration/home:adminlte2_home_route`
where the user can see those messages.
@@ -335,7 +335,7 @@ where the user can see those messages.
debug messages can see it, but in production where debug messages should
not be shown, it will be not rendered.
-If you like this behavior and would like to enable it in your site, you can
+If you like this behavior and would like to enable it on your site, you can
add the following to your root urls.py file:
**urls.py**
@@ -350,7 +350,7 @@ add the following to your root urls.py file:
.. note::
- It must be added to the root urls.py file. It can not be in an apps urls.py
+ It must be added to the root urls.py file. It can not be in an app's urls.py
file. More information can be found in the
`Django Docs <https://docs.djangoproject.com/en/dev/topics/http/urls/#error-handling>`_
diff --git a/docs/source/configuration/admin.rst b/docs/source/configuration/admin.rst
index 8a013e0..4934f14 100644
--- a/docs/source/configuration/admin.rst
+++ b/docs/source/configuration/admin.rst
@@ -17,7 +17,7 @@ Admin Configuration
ADMINLTE2_INCLUDE_ADMIN_HOME_LINK
=================================
-By default the admin menu sidebar will not have a link to the admin index page.
+By default, the admin menu sidebar will not have a link to the admin index page.
If you would like to append a link to the admin index page in the sidebar,
set this value to ``True``.
@@ -40,7 +40,7 @@ Example::
ADMINLTE2_ADMIN_INDEX_USE_APP_LIST
==================================
-By default Django-AdminLTE-2 will put the Apps on the Admin Index page
+By default, Django-AdminLTE-2 will put the Apps on the Admin Index page
into AdminLTE Info Boxes. Setting this to ``True`` will change that look
to the traditional Django list view, but still within the main AdminLTE site
styling.
@@ -112,7 +112,7 @@ look at and potentially override are:
See the project
`GitHub files <https://github.com/DJBarnes/django-adminlte-2/tree/master/django_adminlte_2/templates>`_
-for current implementation.
+for the current implementation.
:Type: ``dict``
diff --git a/docs/source/configuration/home.rst b/docs/source/configuration/home.rst
index 44d2417..2cbeb4e 100644
--- a/docs/source/configuration/home.rst
+++ b/docs/source/configuration/home.rst
@@ -7,9 +7,9 @@ the **Django-AdminLTE-2** package.
All settings are listed here for reference, even though some of these settings
(such as the :doc:`../menu/general_information` and
-:doc:`Authorization <../authorization/policies>`) can become quite complex, to
-the point that they have dedicated documentation pages to better explain the
-full extent of these settings.
+:doc:`Authorization <../authorization/policies>`) can become quite complex,
+to the point that they have dedicated documentation pages to better explain
+the full extent of these settings.
----
@@ -42,13 +42,13 @@ ADMINLTE2_LOGO_TEXT
-------------------
Set the Logo text for your site. This will be shown in the top left of the top
-bar, when the side bar is expanded.
+bar, when the sidebar is expanded.
.. note::
- If you would like to include html in your text, you will need to import
+ If you would like to include HTML in your text, you will need to import
and use ``mark_safe`` from ``django.utils.safestring``. Otherwise, your
- html will be escaped.
+ HTML will be escaped.
:Type: ``string``
:Default: ``AdminLTE``
@@ -62,13 +62,13 @@ ADMINLTE2_LOGO_TEXT_SMALL
-------------------------
Set the small Logo text for your site. This will be shown in the top left of the
-top bar, when the side bar is collapsed.
+top bar, when the sidebar is collapsed.
.. note::
- If you would like to include html in your text, you will need to import
+ If you would like to include HTML in your text, you will need to import
and use ``mark_safe`` from ``django.utils.safestring``. Otherwise, your
- html will be escaped.
+ HTML will be escaped.
:Type: ``string``
:Default: ``ALTE``
diff --git a/docs/source/configuration/menu.rst b/docs/source/configuration/menu.rst
index 4b3cf0e..954a5b0 100644
--- a/docs/source/configuration/menu.rst
+++ b/docs/source/configuration/menu.rst
@@ -5,7 +5,7 @@ Menu Configuration
ADMINLTE2_INCLUDE_MAIN_NAV_ON_ADMIN_PAGES
=========================================
-By default the main navigation (non-admin) menu is not part of the sidebar when
+By default, the main navigation (non-admin) menu is not part of the sidebar when
the user is viewing a
`Django Admin page <https://docs.djangoproject.com/en/dev/ref/contrib/admin/>`_.
If you would like users to be able to see all of the main nav links regardless
@@ -45,7 +45,7 @@ Example::
ADMINLTE2_USE_MENU_GROUP_SEPARATOR
==================================
-By default there will be a implicit separator bar rendered between each menu
+By default, there will be an implicit separator bar rendered between each menu
group.
These groups include: **MENU_FIRST**, **MENU**, **MENU_LAST**, and the
**Admin Menu**.
@@ -67,7 +67,7 @@ ADMINLTE2_MENU
This setting is the definition for the main navigation menu.
There are a lot of options when creating this menu.
-See the :doc:`../menu/admin` section for a detailed explanation on how to
+See the :doc:`../menu/admin` section for a detailed explanation of how to
create this menu and all of the available options that can be used.
:Type: ``list``
diff --git a/docs/source/index.rst b/docs/source/index.rst
index b403953..00ad1c3 100644
--- a/docs/source/index.rst
+++ b/docs/source/index.rst
@@ -26,7 +26,7 @@ Features include:
* Automatic menu link hiding based on user permissions to views.
* Template filters to aid in manual styling.
* Template tags for form rendering that matches AdminLTE2.
-* Automatic form error and messages styling.
+* Automatic form error and message styling.
* `Font Awesome 4 <https://fontawesome.com/v4/icons/>`_
& `Font Awesome 5 <https://fontawesome.com/v5/search>`_ integration.
* Highly configurable functionality, via project
diff --git a/docs/source/menu/admin.rst b/docs/source/menu/admin.rst
index a9d284d..b40dba2 100644
--- a/docs/source/menu/admin.rst
+++ b/docs/source/menu/admin.rst
@@ -8,7 +8,7 @@ Displaying the Admin Menu
As mentioned previously, the Django-AdminLTE-2 package can
:ref:`Auto-Build an Admin Page menu<menu/general_information:Auto-Built Admin Menu>`.
By default, this will appear on all
-`Django Admin pages <https://docs.djangoproject.com/en/dev/ref/contrib/admin/>`_,.
+`Django Admin pages <https://docs.djangoproject.com/en/dev/ref/contrib/admin/>`_.
To configure this admin menu to also show on non-admin pages, refer to
:ref:`configuration/menu:adminlte2_include_admin_nav_on_main_pages`.
@@ -124,13 +124,13 @@ shown, depending on the value defined for
Each of these three sections will show different content. If only one section is
enabled, then it automatically spans the area of the entire sidebar. If more
-than one section is displayed, then navigational tabs are automatically created
+then one section is displayed, then navigational tabs are automatically created
at the top of the sidebar, to allow easy switching between the displayed
sections.
-If all of the tabs are turned off, the entire tri-cog icon and associated
+If all of the tabs are turned off, the entire tri-cog icon and its associated
button will be removed and the user dropdown will shift to the right.
The default behavior is to populate this popup sidebar with the
-"Recent Activity" section of the django admin. The other two sections are hidden
+"Recent Activity" section of the Django admin. The other two sections are hidden
by default.
diff --git a/docs/source/menu/advanced.rst b/docs/source/menu/advanced.rst
index acbb5e7..cc6dcf6 100644
--- a/docs/source/menu/advanced.rst
+++ b/docs/source/menu/advanced.rst
@@ -37,7 +37,7 @@ Moving The Menu Outside Settings
More than likely, your menu will grow in size over time and become a little
large to be living directly in the settings file. Although the menu variable
-does technically have to live in the settings, there are some workarounds that
+does technically have to live in the settings, some workarounds
allow defining the menu outside of the direct settings file.
The most common approach is to make a separate file that will contain your
@@ -77,14 +77,14 @@ Example
Making Part Of The Menu Dynamic
===============================
-It's possible to make the menu dynamic, and generate from the database (or
+It's possible to make the menu dynamic and generate it from the database (or
some other dynamic data source) on each page load. This is accomplished by
sending the dynamic menu to the template, via the page context.
If the menu is defined in both settings and the context, the context version
will always take precedence and override the settings version.
-In addition, there are two menu sections that are specifically meant to be
+In addition, two menu sections are specifically meant to be
dynamic, and can only be delivered by a template's context. Those sections are
called ``ADMINLTE2_MENU_FIRST`` and ``ADMINLTE2_MENU_LAST``.
diff --git a/docs/source/menu/building_blocks.rst b/docs/source/menu/building_blocks.rst
index 5a1c6bf..c580a1a 100644
--- a/docs/source/menu/building_blocks.rst
+++ b/docs/source/menu/building_blocks.rst
@@ -30,7 +30,7 @@ For Example:
* You can have text with no nodes if you only want a header.
* You can have nodes without text if you want a blank header.
-Generally speaking, most common implementation will consist of defining both
+Generally speaking, the most common implementation will consist of defining both
text and nodes.
@@ -45,7 +45,7 @@ The following are accepted keys used when defining a section menu block.
**text**
-A string representing the section text that a user will see.
+A string that represents the section text that a user will see.
:Key: ``text``
:Type: ``string``
@@ -155,8 +155,8 @@ The following are accepted keys used when defining a node menu block.
**route**
-A valid django route. If you are scaffolding your menu out and do
-not have a valid route yet, just enter a ``#`` as a place holder.
+A valid Django route. If you are scaffolding your menu out and do
+not have a valid route yet, just enter a ``#`` as a placeholder.
:Key: ``route``
:Type: ``string``
@@ -183,7 +183,7 @@ Any required kwargs needed to be able to reverse the route.
**text**
-A string representing what will be rendered for the user to see.
+A string that represents what will be rendered for the user to see.
:Key: ``text``
:Type: ``string``
@@ -203,8 +203,8 @@ All required classes needed to make the icon show up must be listed.
**hook**
-An optional string representing the name of a fully qualified function. This
-function will be called to return the text to render for the node.
+An optional string that represents the name of a fully qualified function.
+This function will be called to return the text to render for the node.
This allows the ability to dynamically create the node's text.
:Key: ``hook``
@@ -214,7 +214,7 @@ This allows the ability to dynamically create the node's text.
.. note::
Django-AdminLTE-2 will try to import the value for this key as a function
- and then invoke the function and use it's results as the text for the node.
+ and then invoke the function and use its results as the text for the node.
The function should return either a string that will be used for both the
text and the title text of the node, or a 2-tuple with string values for
@@ -229,8 +229,8 @@ This allows the ability to dynamically create the node's text.
**url**
-An optional string representing the url for the link. If provided, it will take
-precedence over the url generated from the required route key.
+An optional string representing the URL for the link. If provided, it will take
+precedence over the URL generated from the required route key.
:Key: ``url``
:Type: ``string``
@@ -238,14 +238,14 @@ precedence over the url generated from the required route key.
.. warning::
- This key is generally reserved for providing external urls.
+ This key is generally reserved for providing external URLs.
- When defining internal urls, it is **strongly** recommended that you avoid
+ When defining internal URLs, it is **strongly** recommended that you avoid
this key and instead, use the node's route key.
.. note::
- If you decide to use the url key, you must still provide the route key with
+ If you decide to use the ``url`` key, you must still provide the route key with
a value of ``"#"`` as well since the sidebar is expecting that every node
will have a route key.
@@ -253,8 +253,8 @@ precedence over the url generated from the required route key.
.. tip::
- This url key is useful if you need to link to an external website rather
- than an internal link. External links must define any permissions directly
+ This ``url`` key is useful if you need to link to an external website rather
+ then an internal link. External links must define any permissions directly
on the node as there is no associated view to be able to pull permissions
from. See the :doc:`../authorization/policies` page for more information.
@@ -262,7 +262,7 @@ precedence over the url generated from the required route key.
**permissions**
An optional list of permissions as strings. The user must have all listed
-permissions in order to see the node.
+permissions to see the node.
:Key: ``url``
:Type: ``list``
@@ -272,8 +272,8 @@ permissions in order to see the node.
In general, you should use the functionality defined on the
:doc:`Authorization <../authorization/policies>` pages to add permissions
- to a view rather than directly to a node. Defining on the view will handle
- both:
+ to a view rather than directly to a node. Defining the permissions directly
+ on the view will handle both:
* Hiding a node in the sidebar.
* Preventing direct URL navigation, without the need to additionally set the
@@ -301,8 +301,8 @@ these order to see the node.
In general, you should use the functionality defined on the
:doc:`Authorization <../authorization/policies>` pages to add permissions
- to a view rather than directly to a node. Defining on the view will handle
- both:
+ to a view rather than directly to a node. Defining the permissions directly
+ on the view will handle both:
* Hiding a node in the sidebar.
* Preventing direct URL navigation, without the need to additionally set the
@@ -320,7 +320,7 @@ these order to see the node.
**login_required**
An optional key on the node specifying whether a user must be logged in to
-the system in order to see the node.
+the system to see the node.
:Key: ``url``
:Type: ``bool``
@@ -330,8 +330,8 @@ the system in order to see the node.
In general, you should use the functionality defined on the
:doc:`Authorization <../authorization/policies>` pages to add a login
- required criteria to a view, rather than directly to a node. Defining on the
- view will handle both:
+ required criteria to a view, rather than directly to a node. Defining
+ login_required on the view will handle both:
* Hiding a node in the sidebar.
* Preventing direct URL navigation without the need to additionally define
@@ -343,7 +343,7 @@ the system in order to see the node.
.. tip::
This key may be useful when you have an external link that needs to also
- be shown or hidden based on a the user being logged in.
+ be shown or hidden based on the user being logged in.
Node Example
@@ -409,7 +409,7 @@ Tree Keys
**text**
-A string representing what will be rendered for the user to see.
+A string that represents what will be rendered for the user to see.
:Key: ``text``
:Type: ``string``
diff --git a/docs/source/menu/general_information.rst b/docs/source/menu/general_information.rst
index 36ce99c..743f8f1 100644
--- a/docs/source/menu/general_information.rst
+++ b/docs/source/menu/general_information.rst
@@ -2,7 +2,7 @@ General Information
*******************
In the context of the **Django-AdminLTE-2** package, the "menu" is the set of
-navigational elements, displayed on the left-hand side of the default page
+navigational elements displayed on the left-hand side of the default page
layout.
There are three possible configurations (which can be used together) for
@@ -56,8 +56,8 @@ so that they match the same
`AdminLTE2 <https://adminlte.io/themes/AdminLTE/index2.html>`_ theme used by the
rest of the site.
-As such, it makes sense that the Django-AdminLTE-2 package will generate a
-corresponding set of menu nav elements, to allow navigation of these admin
+As such, it makes sense that the Django-AdminLTE-2 package will generate
+a corresponding set of menu nav elements, to allow navigation of the admin
pages.
By default, these admin menu entries will only be seen when the user is on a
diff --git a/docs/source/quickstart.rst b/docs/source/quickstart.rst
index 63c7891..9f67894 100644
--- a/docs/source/quickstart.rst
+++ b/docs/source/quickstart.rst
@@ -19,10 +19,10 @@ Quickstart
.. important::
- The **django_adminlte_2** app should be listed before any django apps so
+ The **django_adminlte_2** app should be listed before any Django apps so
that template overriding works correctly. Additionally, if you plan to
override any Django-AdminLTE-2 templates, they should be listed above
- the **django_adminlte_2 app**.
+ the **django_adminlte_2** app.
3. Django-AdminLTE-2 provides a middleware that is required for some of the
@@ -46,7 +46,7 @@ Quickstart
.. note::
- Django-AdminLTE-2 has been configured out of the box to get you setup
+ Django-AdminLTE-2 has been configured out of the box to get you set up
and running as fast as possible. As a result, the settings surrounding
authentication and authorization are not as strict as they could be.
We **strongly** encourage you to read the section on
@@ -54,7 +54,7 @@ Quickstart
once you get the basics of this package working.
-4. Django-AdminLTE-2 provides templates for django's account routes and some
+4. Django-AdminLTE-2 provides templates for Django's account routes and some
sample routes. Add the routes to your URLconf if you want to use them.
.. code-block:: python
diff --git a/docs/source/templates/fields.rst b/docs/source/templates/fields.rst
index 6be5bc2..567d49c 100644
--- a/docs/source/templates/fields.rst
+++ b/docs/source/templates/fields.rst
@@ -5,7 +5,7 @@ There are no additional fields provided by this package.
However, there are some :ref:`templates/fields:Enhancements` to existing
`Django Fields <https://docs.djangoproject.com/en/dev/ref/forms/fields/>`_
as well as a few :ref:`templates/fields:Text Field Properties` that can be set
-on a django field to add additional rendered functionality.
+on a Django field to add additional rendered functionality.
Those enhancements and properties are explained below.
.. warning::
@@ -22,7 +22,7 @@ DateTimeField
-------------
Any `DateTimeField <https://docs.djangoproject.com/en/dev/ref/forms/fields/#datetimefield>`_
will be rendered out with the input type set to
-``datetime-local``, which will allow an automatic datetime picker widget
+``datetime-local``, which will allow an automatic DateTime picker widget
provided by the browser per the HTML5 spec.
@@ -65,32 +65,32 @@ phone_info
----------
If you would like to make a text field render as a phone input, you can add a
-``phone_info`` property defined as a dictionary with keys ``inputmask`` and
-``pattern``.
+``phone_info`` property that is defined as a dictionary with keys ``inputmask``
+and ``pattern``.
This property will make the field render with both
an inputmask and regex phone pattern to use as validation.
The ``pattern`` key will have a value that is a JavaScript regular expression
-that the entered phone number must pass in order to be submitted.
+that the entered phone number must pass to be submitted.
More information about ``pattern`` can be found via the
`Mozilla Pattern Documentation <https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/tel#pattern>`_
The ``inputmask`` is specified as a string.
-Information about making a valid format can be found at the repository for
+Information about making a valid format can be found in the repository for
`Inputmask <https://github.com/RobinHerbots/Inputmask>`_.
.. warning::
The pattern and inputmask should not be a replacement for server-side
validation. You should still use a clean method on the phone field
- server-side to ensure that the field does in fact have a correct value.
+ server-side to ensure that the field does have a correct value.
The enhancements provided by this property are all client-side and can be
circumvented. Thus it cannot be fully trusted to be accurate.
.. note::
There are two examples below. One sets the property in the form class.
- The other in the View class. You should choose one way or the other.
+ The other sets it in the View class. You should choose one way or the other.
You do **NOT** need to set the property in both locations.
@@ -130,8 +130,8 @@ range_min_max
-------------
If you would like to make a text field render as a range input, you can add a
-``range_min_max`` property defined as a dictionary with keys ``min`` and
-``max``.
+``range_min_max`` property that is defined as a dictionary with keys ``min``
+and ``max``.
This property will make the field render with both a min and max value
that can be selected via the range.
@@ -148,7 +148,7 @@ that can be selected via the range.
.. note::
There are two examples below. One sets the property in the form class.
- The other in the View class. You should choose one way or the other.
+ The other sets it in the View class. You should choose one way or the other.
You do **NOT** need to set the property in both locations.
@@ -189,7 +189,7 @@ More information about ``color`` can be found via the
.. note::
There are two examples below. One sets the property in the form class.
- The other in the View class. You should choose one way or the other.
+ The other sets it in the View class. You should choose one way or the other.
You do **NOT** need to set the property in both locations.
@@ -221,7 +221,7 @@ Setting is_color in a View class
datalist
--------
-If you would like add a datalist to a text field, you can add a
+If you would like to add a datalist to a text field, you can add a
``datalist`` property with a value of dictionary with keys ``name`` and
``data``.
@@ -251,7 +251,7 @@ If you would like add a datalist to a text field, you can add a
.. note::
There are two examples below. One sets the property in the form class.
- The other in the View class. You should choose one way or the other.
+ The other sets it in the View class. You should choose one way or the other.
You do **NOT** need to set the property in both locations.
@@ -304,7 +304,7 @@ both properties on the field.
.. note::
There are two examples below. One sets the property in the form class.
- The other in the View class. You should choose one way or the other.
+ The other sets it in the View class. You should choose one way or the other.
You do **NOT** need to set the property in both locations.
diff --git a/docs/source/templates/forms.rst b/docs/source/templates/forms.rst
index c4b37e2..8adbf90 100644
--- a/docs/source/templates/forms.rst
+++ b/docs/source/templates/forms.rst
@@ -19,7 +19,7 @@ adminlte2_show_field_errors_in_summary
======================================
If you would like to include all field errors in the error summary so that all
-errors no matter what type they are show up in the error summary, set this
+errors, no matter what type they are, show up in the error summary, set this
form attribute to ``True``.
:Type: ``bool``
@@ -49,7 +49,7 @@ summary, you can turn this off by setting this attribute on your form to
``False``.
This is useful if you want to handle the error summary manually without using
-any of the built in magic.
+any of the built-in magic.
:Type: ``bool``
:Default: ``True``
diff --git a/docs/source/templates/template_filters.rst b/docs/source/templates/template_filters.rst
index 3bb6fdd..42c112d 100644
--- a/docs/source/templates/template_filters.rst
+++ b/docs/source/templates/template_filters.rst
@@ -38,7 +38,7 @@ be chained.
:param field: Form field to add attributes to.
:param attrs_as_json: The attrs to add to the field.
- Must be in the form of json. Defaults to None.
+ Must be in the form of JSON. Defaults to None.
:return: Field that was passed in with attrs added.
**Example:**
@@ -65,8 +65,8 @@ Add a ``class`` attribute to a form field and return the form field so filters c
be chained.
:param field: Form field to add attributes to.
-:param class_name: Class name to add to add to the field.
- Defaults to blank string.
+:param class_name: Class name to add to the field.
+ Defaults to a blank string.
:return: Field that was passed in with classes added.
**Example:**
@@ -93,7 +93,7 @@ Add data attributes to a form field and return the form field so filters can be
chained.
:param field: Form field to add data attributes to.
-:param data_attrs_json: The data fields to add. Must be in the form of json.
+:param data_attrs_json: The data fields to add. Must be in the form of JSON.
Defaults to None.
:return: Field that was passed in with data attributes added.
@@ -126,9 +126,9 @@ with_placeholder
Add ``placeholder`` to a form field and return the form field so filters can be
chained.
-:param field: Form field to add placeholder to.
+:param field: Form field to add the placeholder to.
:param placeholder: Placeholder text to use.
- Defaults to fields label if nothing provided.
+ Defaults to the label of the field if nothing is provided.
:return: Field that was passed in with placeholder added.
**Example:**
@@ -251,7 +251,7 @@ site.
:param field: Form field to add attributes to.
:param inputmask: The inputmask pattern to use.
Defaults to ``"(999) 999-9999"`` if value not passed.
-:return: Field that was passed in with a inputmask data attribute added.
+:return: Field that was passed in with an inputmask data attribute added.
**Example:**
@@ -342,10 +342,10 @@ Which will update the form field to look like the following:
with_input_type
===============
-Change widget input_type to passed value.
+Change widget input_type to the passed value.
:param field: Form field to change type on.
-:return: Field that was passed in with input_type changed to passed value.
+:return: Field that was passed in with input_type changed to the passed value.
**Example:**
@@ -413,7 +413,7 @@ letter.
unslugify
=========
-Return a string that converts dash to spaces and capitalizes first letter.
+Return a string that converts dash to spaces and capitalizes the first letter.
:param field: Form field to unslugify.
:return: dir of the field passed in.
diff --git a/docs/source/templates/template_tags.rst b/docs/source/templates/template_tags.rst
index 8e98782..19e2093 100644
--- a/docs/source/templates/template_tags.rst
+++ b/docs/source/templates/template_tags.rst
@@ -39,7 +39,7 @@ Render given fields with optional labels vertically.
:param fields_to_render: List or tuple of fields to render out.
:param labels: Whether to use labels for fields. Defaults to True.
:param media: Media that needs to be used in the form. Defaults to None.
-:return: Context to use with template.
+:return: Context for the template.
:Tag Type: ``inclusion``
:Template: ``adminlte2/partials/_form.html``
@@ -77,7 +77,7 @@ Render given fields with optional labels horizontally.
:param fields_to_render: List or tuple of fields to render.
:param labels: Whether to use labels for fields. Defaults to True.
:param media: Media that needs to be used in the form. Defaults to None.
-:return: Context to use with template.
+:return: Context for the template.
:Type: ``inclusion``
:Template: ``adminlte2/partials/_horizontal_form.html``
@@ -128,7 +128,7 @@ Render a horizontal formset.
get_logout_url
==============
-Get the log out URL from the settings.
+Get the logout URL from the settings.
:Type: ``simple``
@@ -154,7 +154,7 @@ Get the home URL from the settings and default to the django_adminlte_2 home.
get_avatar_url
==============
-Get a gravatar image url.
+Get a gravatar image URL.
If no image is found, gravatar will return an image based on the 'default'
keyword. See http://en.gravatar.com/site/implement/images/ for more info.
@@ -180,7 +180,7 @@ This function will get the profile email in this order:
user_image_initials
===================
-Show user gravatar, initials, or gravatar default mystery person as image
+Show user gravatar, initials, or gravatar default mystery person as the image
Attempt to use/create initials of the user in the style of a profile picture.
Overlay with the user's gravatar image or a blank one if the user does not
@@ -188,8 +188,8 @@ exist. If initials can not be created, change the gravatar default from blank
to the standard mystery person.
If the user is passed in, the user will be used for the base information.
-Information can be overridden by other key word arguments.
-If the user is NOT passed in, key word arguments for each piece of information
+Information can be overridden by other keyword arguments.
+If the user is NOT passed in, keyword arguments for each piece of information
should be used.
:param context: Context for the template.
diff --git a/docs/source/templates/templates.rst b/docs/source/templates/templates.rst
index 064d124..f560656 100644
--- a/docs/source/templates/templates.rst
+++ b/docs/source/templates/templates.rst
@@ -4,15 +4,15 @@ Templates
General
=======
-The main purpose of the **Django-AdminLTE-2** package is to streamline creation
-of `Django <https://www.djangoproject.com/>`_ sites, using the
+The main purpose of the **Django-AdminLTE-2** package is to streamline the
+creation of `Django <https://www.djangoproject.com/>`_ sites, using the
`AdminLTE2 <https://adminlte.io/themes/AdminLTE/index2.html>`_ theme.
As such, this package comes with many templates that are used right out of the
-box, and an automagically-customized site look and feel, just by following the
+box and an automagically-customized site look and feel, just by following the
minimal steps as described in :doc:`../quickstart`.
-Any and all of these templates can be overridden to further customize the look
+All of these templates can be overridden to further customize the look
and feel of the site, depending on project needs. Rather than listing out every
single file and every single block within those files that can be overridden,
it is preferable that you just reference the files yourself. The files can be
@@ -27,7 +27,7 @@ found on
those templates is listed in the
`INSTALLED_APPS <https://docs.djangoproject.com/en/dev/ref/settings/#std-setting-INSTALLED_APPS>`_
setting before the **django-adminlte-2** app. Additionally, the
- **django-adminlte-2** app should be listed before any django apps.
+ **django-adminlte-2** app should be listed before any Django apps.
Example Customization
@@ -45,7 +45,7 @@ First, we can see what this page looks like by default:
To change this page, we can create a template to override the original behavior:
-1. Create ``registration/login.html`` in one of your django project's
+1. Create ``registration/login.html`` in one of your Django project's
`template <https://docs.djangoproject.com/en/dev/ref/settings/#templates>`_
folders, defined via the project settings file.
2. Extend the packages default ``registration/login.html`` by adding the
--
GitLab