Merge e145e8e into 80da034

docs/Makefile

@@ -54,6 +54,11 @@ html:
 	@echo
 	@echo "Build finished. The HTML pages are in $(BUILDDIR)/html."
 
+spelling:
+	$(SPHINXBUILD) -b spelling $(ALLSPHINXOPTS) $(BUILDDIR)/spelling
+	@echo
+	@echo "Spellcheck complete."
+
 dirhtml:
 	$(SPHINXBUILD) -b dirhtml $(ALLSPHINXOPTS) $(BUILDDIR)/dirhtml
 	@echo

docs/conf.py

@@ -50,6 +50,7 @@
 # ones.
 extensions = [
     'sphinx.ext.autodoc',
+    'sphinxcontrib.spelling',
 ]
 
 # Add any paths that contain templates here, relative to this directory.
@@ -116,6 +117,12 @@
 #keep_warnings = False
 
 
+# splhinxcontrib.spelling settings
+
+spelling_lang = 'en_GB'
+spelling_word_list_filename='spelling_wordlist.txt'
+
+
 # -- Options for HTML output ----------------------------------------------
 
 

docs/contrib/api/configuration.rst

@@ -26,7 +26,7 @@ Adding more fields to the pages endpoint
 
 By default, the pages endpoint only includes the ``id``, ``title`` and ``type`` fields in both the listing and detail views.
 
-You can add more fields to the pages endpoint by setting an attribute called ``api_fields`` to a list/tuple of field names:
+You can add more fields to the pages endpoint by setting an attribute called ``api_fields`` to a ``list`` or ``tuple`` of field names:
 
 .. code-block:: python
 
@@ -63,6 +63,6 @@ If you have a Varnish, Squid or Cloudflare instance in front of your API, the ``
 
 To enable it, firstly configure the ``wagtail.contrib.wagtailfrontendcache`` module within your project (see [Wagtail frontend cache docs](http://docs.wagtail.io/en/latest/contrib_components/frontendcache.html) for more information).
 
-Then make sure that the ``WAGTAILAPI_BASE_URL`` setting is set correctly (eg. ``WAGTAILAPI_BASE_URL = 'http://api.mysite.com'``).
+Then make sure that the ``WAGTAILAPI_BASE_URL`` setting is set correctly (Example: ``WAGTAILAPI_BASE_URL = 'http://api.mysite.com'``).
 
 Then finally, switch it on by setting ``WAGTAILAPI_USE_FRONTENDCACHE`` to ``True``.

docs/contrib/api/index.rst

@@ -1,7 +1,7 @@
 Wagtail API
 ===========
 
-The wagtailapi module can be used to create a read-only, JSON-based API for public Wagtail content.
+The ``wagtailapi`` module can be used to create a read-only, JSON-based API for public Wagtail content.
 
 There are three endpoints to the API:
 

docs/contrib/sitemaps.rst

@@ -20,7 +20,7 @@ You firstly need to add ``"wagtail.contrib.wagtailsitemaps"`` to INSTALLED_APPS
     ]
 
 
-Then, in urls.py, you need to add a link to the ``wagtail.contrib.wagtailsitemaps.views.sitemap`` view which generates the sitemap:
+Then, in ``urls.py``, you need to add a link to the ``wagtail.contrib.wagtailsitemaps.views.sitemap`` view which generates the sitemap:
 
 .. code-block:: python
 
@@ -33,7 +33,7 @@ Then, in urls.py, you need to add a link to the ``wagtail.contrib.wagtailsitemap
     ]
 
 
-You should now be able to browse to "/sitemap.xml" and see the sitemap working. By default, all published pages in your website will be added to the site map.
+You should now be able to browse to ``/sitemap.xml`` and see the sitemap working. By default, all published pages in your website will be added to the site map.
 
 
 Customising
@@ -42,7 +42,7 @@ Customising
 URLs
 ----
 
-The Page class defines a ``get_sitemap_urls`` method which you can override to customise sitemaps per page instance. This method must return a list of dictionaries, one dictionary per URL entry in the sitemap. You can exclude pages from the sitemap by returning an empty list.
+The ``Page`` class defines a ``get_sitemap_urls`` method which you can override to customise sitemaps per ``Page`` instance. This method must return a list of dictionaries, one dictionary per URL entry in the sitemap. You can exclude pages from the sitemap by returning an empty list.
 
 Each dictionary can contain the following:
 

docs/contrib/staticsitegen.rst

@@ -1,7 +1,7 @@
 Generating a static site
 ========================
 
-This document describes how to render your Wagtail site into static HTML files on your local filesystem, Amazon S3 or Google App Engine, using `django medusa`_ and the ``wagtail.contrib.wagtailmedusa`` module.
+This document describes how to render your Wagtail site into static HTML files on your local file system, Amazon S3 or Google App Engine, using `django medusa`_ and the ``wagtail.contrib.wagtailmedusa`` module.
 
 .. note::
 
@@ -38,9 +38,9 @@ Define ``MEDUSA_RENDERER_CLASS`` and ``MEDUSA_DEPLOY_DIR`` in settings:
 Rendering
 ~~~~~~~~~
 
-To render a site, run ``./manage.py staticsitegen``. This will render the entire website and place the HTML in a folder called 'medusa_output'. The static and media folders need to be copied into this folder manually after the rendering is complete. This feature inherits ``django-medusa``'s ability to render your static site to Amazon S3 or Google App Engine; see the `medusa docs <https://github.com/mtigas/django-medusa/blob/master/README.markdown>`_ for configuration details.
+To render a site, run ``./manage.py staticsitegen``. This will render the entire website and place the HTML in a folder called ``medusa_output``. The static and media folders need to be copied into this folder manually after the rendering is complete. This feature inherits ``django-medusa``'s ability to render your static site to Amazon S3 or Google App Engine; see the `medusa docs <https://github.com/mtigas/django-medusa/blob/master/README.markdown>`_ for configuration details.
 
-To test, open the 'medusa_output' folder in a terminal and run ``python -m SimpleHTTPServer``.
+To test, open the ``medusa_output`` folder in a terminal and run ``python -m SimpleHTTPServer``.
 
 
 Advanced topics
@@ -51,7 +51,7 @@ GET parameters
 
 Pages which require GET parameters (e.g. for pagination) don't generate suitable filenames for generated HTML files.
 
-Wagtail provides a mixin (``wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin``) which allows you to embed a Django url configuration into a page. This allows you to give the subpages a URL like ``/page/1/`` which work well with static site generation.
+Wagtail provides a mixin (``wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin``) which allows you to embed a Django URL configuration into a page. This allows you to give the subpages a URL like ``/page/1/`` which work well with static site generation.
 
 
 Example:
@@ -94,7 +94,7 @@ Next, you have to tell the ``wagtailmedusa`` module about your custom routing...
 Rendering pages which use custom routing
 ----------------------------------------
 
-For page types that override the ``route`` method, we need to let django medusa know which URLs it responds on. This is done by overriding the ``get_static_site_paths`` method to make it yield one string per URL path.
+For page types that override the ``route`` method, we need to let ``django-medusa`` know which URLs it responds on. This is done by overriding the ``get_static_site_paths`` method to make it yield one string per URL path.
 
 For example, the BlogIndex above would need to yield one URL for each page of results:
 

docs/editor_manual/getting_started.rst

@@ -12,7 +12,7 @@ Logging in
 __________
 
 * The first port of call for an editor is the login page for the administrator interface.
-* Access this by adding **/admin** onto the end of your root URL (e.g. www.example.com/admin).
+* Access this by adding **/admin** onto the end of your root URL (e.g. ``www.example.com/admin``).
 * Enter your username and password and click **Sign in**.
 
-.. image:: ../_static/images/screen01_login.png
+.. image:: ../_static/images/screen01_login.png

docs/form_builder.rst

@@ -19,7 +19,7 @@ Add 'wagtail.wagtailforms' to your INSTALLED_APPS:
        'wagtail.wagtailforms',
     ]
 
-Within the models.py of one of your apps, create a model that extends wagtailforms.models.AbstractEmailForm:
+Within the ``models.py`` of one of your apps, create a model that extends ``wagtailforms.models.AbstractEmailForm``:
 
 
 .. code:: python

docs/getting_started/installation.rst

@@ -78,11 +78,11 @@ For the best possible performance and feature set, we recommend setting up the f
 
 PostgreSQL
 ----------
-PostgreSQL is a mature database engine suitable for production use, and is recommended by the Django development team. Non-Vagrant users will need to install the PostgreSQL development headers in addition to Postgres itself; on Debian or Ubuntu, this can be done with the following command::
+PostgreSQL is a mature database engine suitable for production use, and is recommended by the Django development team. Non-Vagrant users will need to install the PostgreSQL development headers in addition to PostgreSQL itself; on Debian or Ubuntu, this can be done with the following command::
 
     sudo apt-get install postgresql postgresql-server-dev-all
 
-To enable Postgres for your project, uncomment the ``psycopg2`` line from your project's requirements.txt, and in ``myprojectname/settings/base.py``, uncomment the DATABASES section for PostgreSQL, commenting out the SQLite one instead. Then run::
+To enable PostgreSQL for your project, uncomment the ``psycopg2`` line from your project's requirements.txt, and in ``myprojectname/settings/base.py``, uncomment the DATABASES section for PostgreSQL, commenting out the SQLite one instead. Then run::
 
     pip install -r requirements.txt
     createdb -Upostgres myprojectname

docs/getting_started/trying_wagtail.rst

@@ -41,7 +41,7 @@ types, in one step. As the root user::
   curl -O https://raw.githubusercontent.com/torchbox/wagtail/master/scripts/install/ubuntu.sh; bash ubuntu.sh
 
 This script installs all the dependencies for a production-ready Wagtail site,
-including PostgreSQL, Redis, Elasticsearch, Nginx and uwsgi. We
+including PostgreSQL, Redis, Elasticsearch, Nginx and uWSGI. We
 recommend you check through the script before running it, and adapt it according
 to your deployment preferences. The canonical version is at
 `github.com/torchbox/wagtail/blob/master/scripts/install/ubuntu.sh
@@ -58,7 +58,7 @@ step. As the root user::
   curl -O https://raw.githubusercontent.com/torchbox/wagtail/master/scripts/install/debian.sh; bash debian.sh
 
 This script installs all the dependencies for a production-ready Wagtail site,
-including PostgreSQL, Redis, Elasticsearch, Nginx and uwsgi. We
+including PostgreSQL, Redis, Elasticsearch, Nginx and uWSGI. We
 recommend you check through the script before running it, and adapt it according
 to your deployment preferences. The canonical version is at
 `github.com/torchbox/wagtail/blob/master/scripts/install/debian.sh

docs/howto/settings.rst

@@ -1,4 +1,3 @@
-
 ==============================
 Configuring Django for Wagtail
 ==============================
@@ -24,8 +23,8 @@ From your app directory, you can safely remove ``admin.py`` and ``views.py``, si
 What follows is a settings reference which skips many boilerplate Django settings. If you just want to get your Wagtail install up quickly without fussing with settings at the moment, see :ref:`complete_example_config`.
 
 
-Middleware (settings.py)
-~~~~~~~~~~~~~~~~~~~~~~~~
+Middleware (``settings.py``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. code-block:: python
 
@@ -137,8 +136,8 @@ Wagtail Apps
   Models for creating forms on your pages and viewing submissions. See :ref:`form_builder`.
 
 
-Settings Variables (settings.py)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Settings Variables (``settings.py``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Site Name
 ---------
@@ -167,13 +166,13 @@ Search
     }
   }
 
-The search settings customize the search results templates as well as choosing a custom backend for search. For a full explanation, see :ref:`search`.
+The search settings customise the search results templates as well as choosing a custom backend for search. For a full explanation, see :ref:`search`.
 
 
 Embeds
 ------
 
-Wagtail uses the oEmbed standard with a large but not comprehensive number of "providers" (youtube, vimeo, etc.). You can also use a different embed backend by providing an Embedly key or replacing the embed backend by writing your own embed finder function. 
+Wagtail uses the oEmbed standard with a large but not comprehensive number of "providers" (Youtube, Vimeo, etc.). You can also use a different embed backend by providing an Embedly key or replacing the embed backend by writing your own embed finder function. 
 
 .. code-block:: python
 
@@ -289,14 +288,14 @@ That's not everything you might want to include in your project's urlconf, but i
 
 .. _complete_example_config:
 
-Ready to Use Example Config Files
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Ready to Use Example Configuration Files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 These two files should reside in your project directory (``myproject/myproject/``).
 
 
-settings.py
------------
+``settings.py``
+---------------
 
 .. code-block:: python
 
@@ -511,8 +510,8 @@ settings.py
   # EMBEDLY_KEY = '253e433d59dc4d2xa266e9e0de0cb830'
 
 
-urls.py
--------
+``urls.py``
+-----------
 
 .. code-block:: python
 

docs/pages/advanced_topics/queryset_methods.rst

@@ -1,8 +1,8 @@
 =====================
-Page Queryset Methods
+Page QuerySet Methods
 =====================
 
-All models that inherit from ``Page`` are given some extra Queryset methods accessible from their ``.objects`` attribute.
+All models that inherit from ``Page`` are given some extra QuerySet methods accessible from their ``.objects`` attribute.
 
 
 Examples
@@ -24,7 +24,7 @@ Examples
 
     .. code-block:: python
 
-        # This gets a queryset of live children of the homepage with ``show_in_menus`` set
+        # This gets a QuerySet of live children of the homepage with ``show_in_menus`` set
         menu_items = homepage.get_children().live().in_menu()
 
 
@@ -75,7 +75,7 @@ Reference
 
         .. code-block:: python
 
-            # Append an extra page to a queryset
+            # Append an extra page to a QuerySet
             new_queryset = old_queryset | Page.objects.page(page_to_add)
 
     .. automethod:: not_page
@@ -84,7 +84,7 @@ Reference
 
         .. code-block:: python
 
-            # Remove a page from a queryset
+            # Remove a page from a QuerySet
             new_queryset = old_queryset & Page.objects.not_page(page_to_remove)
 
     .. automethod:: descendant_of

docs/pages/editing_api.rst

@@ -9,7 +9,7 @@ Wagtail provides a highly-customizable editing interface consisting of several c
   * **Panels** — the basic editing blocks for fields, groups of fields, and related object clusters
   * **Choosers** — interfaces for finding related objects in a ForeignKey relationship
 
-Configuring your models to use these components will shape the Wagtail editor to your needs. Wagtail also provides an API for injecting custom CSS and JavaScript for further customization, including extending the hallo.js rich text editor.
+Configuring your models to use these components will shape the Wagtail editor to your needs. Wagtail also provides an API for injecting custom CSS and JavaScript for further customization, including extending the ``hallo.js`` rich text editor.
 
 There is also an Edit Handler API for creating your own Wagtail editor components.
 
@@ -412,7 +412,7 @@ As standard, Wagtail organises panels into three tabs: 'Content', 'Promote' and
 Extending the WYSIWYG Editor (hallo.js)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-To inject javascript into the Wagtail page editor, see the :ref:`insert_editor_js <insert_editor_js>` hook. Once you have the hook in place and your hallo.js plugin loads into the Wagtail page editor, use the following Javascript to register the plugin with hallo.js.
+To inject JavaScript into the Wagtail page editor, see the :ref:`insert_editor_js <insert_editor_js>` hook. Once you have the hook in place and your hallo.js plugin loads into the Wagtail page editor, use the following Javascript to register the plugin with hallo.js.
 
 .. code-block:: javascript
 

docs/pages/model_recipes.rst

@@ -78,7 +78,7 @@ Wagtail routes requests by iterating over the path components (separated with a
 
 ``route()`` takes the current object (``self``), the ``request`` object, and a list of the remaining ``path_components`` from the request URL. It either continues delegating routing by calling ``route()`` again on one of its children in the Wagtail tree, or ends the routing process by returning a ``RouteResult`` object or raising a 404 error.
 
-The ``RouteResult`` object (defined in wagtail.wagtailcore.url_routing) encapsulates all the information Wagtail needs to call a page's ``serve()`` method and return a final response: this information consists of the page object, and any additional args / kwargs to be passed to ``serve()``.
+The ``RouteResult`` object (defined in wagtail.wagtailcore.url_routing) encapsulates all the information Wagtail needs to call a page's ``serve()`` method and return a final response: this information consists of the page object, and any additional ``args``/``kwargs`` to be passed to ``serve()``.
 
 By overriding the ``route()`` method, we could create custom endpoints for each object in the Wagtail tree. One use case might be using an alternate template when encountering the ``print/`` endpoint in the path. Another might be a REST API which interacts with the current object. Just to see what's involved, lets make a simple model which prints out all of its child path components.
 

docs/pages/theory.rst

@@ -89,7 +89,7 @@ For going beyond the basics of model definition and interrelation, it might help
     #.  Django gets a request and routes through Wagtail's URL dispatcher definitions
     #.  Wagtail checks the hostname of the request to determine which ``Site`` record will handle this request.
     #.  Starting from the root page of that site, Wagtail traverses the page tree, calling the ``route()`` method and letting each page model decide whether it will handle the request itself or pass it on to a child page.
-    #.  The page responsible for handling the request returns a ``RouteResult`` object from ``route()``, which identifies the page along with any additional args/kwargs to be passed to ``serve()``.
+    #.  The page responsible for handling the request returns a ``RouteResult`` object from ``route()``, which identifies the page along with any additional ``args``/``kwargs`` to be passed to ``serve()``.
     #.  Wagtail calls ``serve()``, which constructs a context using ``get_context()``
     #.  ``serve()`` finds a template to pass it to using ``get_template()``
     #.  A response object is returned by ``serve()`` and Django responds to the requester.

docs/pages/writing_templates.rst

@@ -159,8 +159,8 @@ Wagtail embeds and images are included at their full width, which may overflow t
 Internal links (tag)
 ~~~~~~~~~~~~~~~~~~~~
 
-pageurl
---------
+``pageurl``
+-----------
 
 Takes a Page object and returns a relative URL (``/foo/bar/``) if within the same site as the current page, or absolute (``http://example.com/foo/bar/``) if not.
 

docs/reference/hooks.rst

@@ -30,7 +30,7 @@ The available hooks are:
 
 ``before_serve_page``
 
-  Called when Wagtail is about to serve a page. The callable passed into the hook will receive the page object, the request object, and the args and kwargs that will be passed to the page's ``serve()`` method. If the callable returns an ``HttpResponse``, that response will be returned immediately to the user, and Wagtail will not proceed to call ``serve()`` on the page.
+  Called when Wagtail is about to serve a page. The callable passed into the hook will receive the page object, the request object, and the ``args`` and ``kwargs`` that will be passed to the page's ``serve()`` method. If the callable returns an ``HttpResponse``, that response will be returned immediately to the user, and Wagtail will not proceed to call ``serve()`` on the page.
 
   .. code-block:: python