From 27facef89e8ac3d09754d9485f6e97e7a56486f4 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Fri, 17 Apr 2015 22:49:16 +0100 Subject: [PATCH 1/5] Added spellcheker --- docs/Makefile | 5 +++++ docs/conf.py | 7 +++++++ requirements-dev.txt | 4 ++++ 3 files changed, 16 insertions(+) diff --git a/docs/Makefile b/docs/Makefile index 5b4eb026a..2333c272f 100644 --- a/docs/Makefile +++ b/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 diff --git a/docs/conf.py b/docs/conf.py index b8ff46164..54f2132eb 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -50,6 +50,7 @@ os.environ['DATABASE_ENGINE'] = 'django.db.backends.sqlite3' # ones. extensions = [ 'sphinx.ext.autodoc', + 'sphinxcontrib.spelling', ] # Add any paths that contain templates here, relative to this directory. @@ -116,6 +117,12 @@ pygments_style = 'sphinx' #keep_warnings = False +# splhinxcontrib.spelling settings + +spelling_lang = 'en_US' +spelling_word_list_filename='spelling_wordlist.txt' + + # -- Options for HTML output ---------------------------------------------- diff --git a/requirements-dev.txt b/requirements-dev.txt index d4a4634a4..367d1ae72 100644 --- a/requirements-dev.txt +++ b/requirements-dev.txt @@ -7,3 +7,7 @@ Pillow>=2.7.0 # For coverage and PEP8 linting coverage>=3.7.0 flake8>=2.2.0 + +# For spellchecking the documentation +sphinxcontrib-spelling==2.1.1 +pyenchant==1.6.6 From 739ef64cf153eb7675c85f08752d7e520822a296 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Fri, 17 Apr 2015 23:05:08 +0100 Subject: [PATCH 2/5] Started fixing spellings. Added wordlist --- docs/contrib/api/configuration.rst | 4 ++-- docs/contrib/api/index.rst | 2 +- docs/contrib/sitemaps.rst | 4 ++-- docs/contrib/staticsitegen.rst | 8 +++---- docs/editor_manual/getting_started.rst | 4 ++-- docs/form_builder.rst | 2 +- docs/howto/settings.rst | 3 +-- .../advanced_topics/queryset_methods.rst | 10 ++++---- docs/pages/editing_api.rst | 4 ++-- docs/pages/writing_templates.rst | 4 ++-- docs/reference/hooks.rst | 2 +- docs/releases/0.8.5.rst | 2 +- docs/releases/1.0.rst | 12 +++++----- docs/search/indexing.rst | 8 +++---- docs/search/searching.rst | 6 ++--- docs/snippets.rst | 2 +- docs/spelling_wordlist.txt | 24 +++++++++++++++++++ 17 files changed, 62 insertions(+), 39 deletions(-) create mode 100644 docs/spelling_wordlist.txt diff --git a/docs/contrib/api/configuration.rst b/docs/contrib/api/configuration.rst index 1135b3bd4..31c66cf74 100644 --- a/docs/contrib/api/configuration.rst +++ b/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``. diff --git a/docs/contrib/api/index.rst b/docs/contrib/api/index.rst index ef8ee6a50..29791e43f 100644 --- a/docs/contrib/api/index.rst +++ b/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: diff --git a/docs/contrib/sitemaps.rst b/docs/contrib/sitemaps.rst index 8f4e0685a..5cdb1f3c4 100644 --- a/docs/contrib/sitemaps.rst +++ b/docs/contrib/sitemaps.rst @@ -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: diff --git a/docs/contrib/staticsitegen.rst b/docs/contrib/staticsitegen.rst index 525a68333..11d4c1e1e 100644 --- a/docs/contrib/staticsitegen.rst +++ b/docs/contrib/staticsitegen.rst @@ -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 `_ 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 `_ 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: diff --git a/docs/editor_manual/getting_started.rst b/docs/editor_manual/getting_started.rst index e935b039e..ffa6931fd 100644 --- a/docs/editor_manual/getting_started.rst +++ b/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 \ No newline at end of file +.. image:: ../_static/images/screen01_login.png diff --git a/docs/form_builder.rst b/docs/form_builder.rst index 7682bbba6..5503e25ff 100644 --- a/docs/form_builder.rst +++ b/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 diff --git a/docs/howto/settings.rst b/docs/howto/settings.rst index 7a59d5de9..6b823cc7e 100644 --- a/docs/howto/settings.rst +++ b/docs/howto/settings.rst @@ -1,4 +1,3 @@ - ============================== Configuring Django for Wagtail ============================== @@ -173,7 +172,7 @@ The search settings customize the search results templates as well as choosing a 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 diff --git a/docs/pages/advanced_topics/queryset_methods.rst b/docs/pages/advanced_topics/queryset_methods.rst index 4466b6b63..1b08d133f 100644 --- a/docs/pages/advanced_topics/queryset_methods.rst +++ b/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 diff --git a/docs/pages/editing_api.rst b/docs/pages/editing_api.rst index 197eeffd2..88d1f233d 100644 --- a/docs/pages/editing_api.rst +++ b/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 ` 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 ` 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 diff --git a/docs/pages/writing_templates.rst b/docs/pages/writing_templates.rst index 48ac825da..3d67409e6 100644 --- a/docs/pages/writing_templates.rst +++ b/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. diff --git a/docs/reference/hooks.rst b/docs/reference/hooks.rst index a0776b641..338a74e98 100644 --- a/docs/reference/hooks.rst +++ b/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 diff --git a/docs/releases/0.8.5.rst b/docs/releases/0.8.5.rst index 07c97b9db..8e6764378 100644 --- a/docs/releases/0.8.5.rst +++ b/docs/releases/0.8.5.rst @@ -22,6 +22,6 @@ Bug fixes * When adding tags where there were none before, it is now possible to save a single tag with multiple words in it * ``richtext`` template tag no longer raises ``TypeError`` if ``None`` is passed into it * Serving documents now uses a streaming HTTP response and will no longer break Django's cache middleware - * User admin area no longer fails in the presence of negative user IDs (as used by django-guardian's default settings) + * User admin area no longer fails in the presence of negative user IDs (as used by ``django-guardian``'s default settings) * Password reset emails now use the ``BASE_URL`` setting for the reset URL * ``BASE_URL`` is now included in the project template's default settings file diff --git a/docs/releases/1.0.rst b/docs/releases/1.0.rst index 4166ce3c2..be410be40 100644 --- a/docs/releases/1.0.rst +++ b/docs/releases/1.0.rst @@ -65,7 +65,7 @@ Admin **Page editor** - * Javascript includes in the admin backend have been moved to the HTML header, to accommodate form widgets that render inline scripts that depend on libraries such as jQuery + * JavaScript includes in the admin backend have been moved to the HTML header, to accommodate form widgets that render inline scripts that depend on libraries such as jQuery * The external link chooser in rich text areas now accepts URLs of the form '/some/local/path', to allow linking to non-Wagtail-controlled URLs within the local site * Bare text entered in rich text areas is now automatically wrapped in a paragraph element @@ -84,9 +84,9 @@ Admin * Removed the dependency on ``LOGIN_URL`` and ``LOGIN_REDIRECT_URL`` settings * Password reset view names namespaced to wagtailadmin * Removed the need to add permission check on admin views (now automated) - * Reversing ``django.contrib.auth.admin.login`` will no longer lead to Wagtails login view (making it easier to have front end views) + * Reversing ``django.contrib.auth.admin.login`` will no longer lead to Wagtails log in view (making it easier to have frontend log in views) * Added cache-control headers to all admin views. This allows Varnish/Squid/CDN to run on vanilla settings in front of a Wagtail site - * Date / time pickers now consistently use times without seconds, to prevent Javascript behaviour glitches when focusing / unfocusing fields + * Date / time pickers now consistently use times without seconds, to prevent JavasSript behaviour glitches when focusing / unfocusing fields * Added hook ``construct_homepage_summary_items`` for customising the site summary panel on the admin homepage * Renamed the ``construct_wagtail_edit_bird`` hook to ``construct_wagtail_userbar`` @@ -219,15 +219,15 @@ should work fine without them. Login/Password reset views renamed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -It was previously possible to reverse the Wagtail login using django.contrib.auth.views.login. +It was previously possible to reverse the Wagtail log in view using ``django.contrib.auth.views.login``. This is no longer possible. Update any references to ``wagtailadmin_login``. Password reset view name has changed from ``password_reset`` to ``wagtailadmin_password_reset``. -Javascript includes in admin backend have been moved +JavaScript includes in admin backend have been moved ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -To improve compatibility with third-party form widgets, pages within the Wagtail admin backend now output their Javascript includes in the HTML header, rather than at the end of the page. If your project extends the admin backend (through the ``register_admin_menu_item`` hook, for example) you will need to ensure that all associated Javascript code runs correctly from the new location. In particular, any code that accesses HTML elements will need to be contained in an 'onload' handler (e.g. jQuery's ``$(document).ready()``). +To improve compatibility with third-party form widgets, pages within the Wagtail admin backend now output their JavaScript includes in the HTML header, rather than at the end of the page. If your project extends the admin backend (through the ``register_admin_menu_item`` hook, for example) you will need to ensure that all associated JavaScript code runs correctly from the new location. In particular, any code that accesses HTML elements will need to be contained in an 'onload' handler (e.g. jQuery's ``$(document).ready()``). EditHandler internal API has changed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/search/indexing.rst b/docs/search/indexing.rst index 3b27864e3..1fca1ad38 100644 --- a/docs/search/indexing.rst +++ b/docs/search/indexing.rst @@ -29,7 +29,7 @@ Signal handlers Signal handlers are now automatically registered in Django 1.7 and upwards -Wagtailsearch provides some signal handlers which bind to the save/delete signals of all indexed models. This would automatically add and delete them from all backends you have registered in ``WAGTAILSEARCH_BACKENDS``. +``wagtailsearch`` provides some signal handlers which bind to the save/delete signals of all indexed models. This would automatically add and delete them from all backends you have registered in ``WAGTAILSEARCH_BACKENDS``. If you are using Django version 1.7 or newer, these signal handlers are automatically registered when the ``wagtail.wagtailsearch`` app is loaded. Otherwise, they must be registered as your application starts up. This can be done by placing the following code in your ``urls.py``: @@ -101,9 +101,9 @@ These are added to the search index and are used for performing full-text search Options ``````` - - **partial_match** (boolean) - Setting this to true allows results to be matched on parts of words. For example, this is set on the title field by default so a page titled "Hello World!" will be found if the user only types "Hel" into the search box. - - **boost** (number) - This allows you to set fields as being more important than others. Setting this to a high number on a field will make pages with matches in that field to be ranked higher. By default, this is set to 2 on the Page title field and 1 on all other fields. - - **es_extra** (dict) - This field is to allow the developer to set or override any setting on the field in the ElasticSearch mapping. Use this if you want to make use of any ElasticSearch features that are not yet supported in Wagtail. + - **partial_match** (``boolean``) - Setting this to true allows results to be matched on parts of words. For example, this is set on the title field by default so a page titled ``Hello World!`` will be found if the user only types ``Hel`` into the search box. + - **boost** (``int/float``) - This allows you to set fields as being more important than others. Setting this to a high number on a field will make pages with matches in that field to be ranked higher. By default, this is set to 2 on the Page title field and 1 on all other fields. + - **es_extra** (``dict``) - This field is to allow the developer to set or override any setting on the field in the ElasticSearch mapping. Use this if you want to make use of any ElasticSearch features that are not yet supported in Wagtail. ``index.FilterField`` diff --git a/docs/search/searching.rst b/docs/search/searching.rst index 3240d944a..522e6232d 100644 --- a/docs/search/searching.rst +++ b/docs/search/searching.rst @@ -21,7 +21,7 @@ Wagtail provides a ``search`` method on the QuerySet for all page models: >>> EventPage.objects.filter(date__gt=timezone.now()).search("Hello world!") -All methods of ``PageQuerySet`` are supported by wagtailsearch: +All methods of ``PageQuerySet`` are supported by ``wagtailsearch``: .. code-block:: python @@ -83,7 +83,7 @@ The most basic search functionality just needs a search box which submits a requ -The form is submitted to the url of the ``wagtailsearch_search`` view, with the search terms variable ``q``. The view will use its own basic search results template. +The form is submitted to the URL of the ``wagtailsearch_search`` view, with the search terms variable ``q``. The view will use its own basic search results template. Let's use our own template for the results, though. First, in your project's ``settings.py``, define a path to your template: @@ -156,7 +156,7 @@ Now add a simple interface for the search with a ```` element to gather s
-Finally, we'll use JQuery to make the asynchronous requests and handle the interactivity: +Finally, we'll use jQuery to make the asynchronous requests and handle the interactivity: .. code-block:: guess diff --git a/docs/snippets.rst b/docs/snippets.rst index e323bdb68..6acf2faf2 100644 --- a/docs/snippets.rst +++ b/docs/snippets.rst @@ -35,7 +35,7 @@ Here's an example snippet from the Wagtail demo website: def __unicode__(self): return self.text -The ``Advert`` model uses the basic Django model class and defines two properties: text and url. The editing interface is very close to that provided for ``Page``-derived models, with fields assigned in the panels property. Snippets do not use multiple tabs of fields, nor do they provide the "save as draft" or "submit for moderation" features. +The ``Advert`` model uses the basic Django model class and defines two properties: text and URL. The editing interface is very close to that provided for ``Page``-derived models, with fields assigned in the panels property. Snippets do not use multiple tabs of fields, nor do they provide the "save as draft" or "submit for moderation" features. ``@register_snippet`` tells Wagtail to treat the model as a snippet. The ``panels`` list defines the fields to show on the snippet editing page. It's also important to provide a string representation of the class through ``def __unicode__(self):`` so that the snippet objects make sense when listed in the Wagtail admin. diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt new file mode 100644 index 000000000..e932d56dd --- /dev/null +++ b/docs/spelling_wordlist.txt @@ -0,0 +1,24 @@ +backend +backends +callable +callables +Cloudflare +Django +Elasticsearch +Embedly +frontend +Heroku +jQuery +metadata +Nginx +oEmbed +PostgreSQL +QuerySet +Redis +searchable +Searchly +Torchbox +Vagrantfile +Vimeo +Wagtail +Youtube From 7d6b039239410cce62f2cf90528a748f17e3d0aa Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Sun, 19 Apr 2015 10:24:12 +0100 Subject: [PATCH 3/5] Use GB English for spellchecking --- docs/conf.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/conf.py b/docs/conf.py index 54f2132eb..3b9afb9a3 100644 --- a/docs/conf.py +++ b/docs/conf.py @@ -119,7 +119,7 @@ pygments_style = 'sphinx' # splhinxcontrib.spelling settings -spelling_lang = 'en_US' +spelling_lang = 'en_GB' spelling_word_list_filename='spelling_wordlist.txt' From 458fdbf776f4022615aec15f725f1f8916ae6966 Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Sun, 19 Apr 2015 10:28:10 +0100 Subject: [PATCH 4/5] Add 'login' to wordlist --- docs/releases/1.0.rst | 4 ++-- docs/spelling_wordlist.txt | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/releases/1.0.rst b/docs/releases/1.0.rst index be410be40..774e24863 100644 --- a/docs/releases/1.0.rst +++ b/docs/releases/1.0.rst @@ -84,7 +84,7 @@ Admin * Removed the dependency on ``LOGIN_URL`` and ``LOGIN_REDIRECT_URL`` settings * Password reset view names namespaced to wagtailadmin * Removed the need to add permission check on admin views (now automated) - * Reversing ``django.contrib.auth.admin.login`` will no longer lead to Wagtails log in view (making it easier to have frontend log in views) + * Reversing ``django.contrib.auth.admin.login`` will no longer lead to Wagtails login view (making it easier to have frontend login views) * Added cache-control headers to all admin views. This allows Varnish/Squid/CDN to run on vanilla settings in front of a Wagtail site * Date / time pickers now consistently use times without seconds, to prevent JavasSript behaviour glitches when focusing / unfocusing fields * Added hook ``construct_homepage_summary_items`` for customising the site summary panel on the admin homepage @@ -219,7 +219,7 @@ should work fine without them. Login/Password reset views renamed ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -It was previously possible to reverse the Wagtail log in view using ``django.contrib.auth.views.login``. +It was previously possible to reverse the Wagtail login view using ``django.contrib.auth.views.login``. This is no longer possible. Update any references to ``wagtailadmin_login``. Password reset view name has changed from ``password_reset`` to ``wagtailadmin_password_reset``. diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt index e932d56dd..b62ce8036 100644 --- a/docs/spelling_wordlist.txt +++ b/docs/spelling_wordlist.txt @@ -9,6 +9,7 @@ Embedly frontend Heroku jQuery +login metadata Nginx oEmbed From e145e8ebcf4b3a9c07763e72f6356811e16294fd Mon Sep 17 00:00:00 2001 From: Karl Hobley Date: Sun, 19 Apr 2015 10:53:34 +0100 Subject: [PATCH 5/5] Spelling corrections --- docs/contrib/sitemaps.rst | 2 +- docs/contrib/staticsitegen.rst | 2 +- docs/getting_started/installation.rst | 4 +-- docs/getting_started/trying_wagtail.rst | 4 +-- docs/howto/settings.rst | 22 +++++++------- docs/pages/model_recipes.rst | 2 +- docs/pages/theory.rst | 2 +- docs/reference/project_template.rst | 4 +-- docs/releases/0.4.rst | 8 +++--- docs/spelling_wordlist.txt | 10 +++++++ wagtail/wagtailcore/query.py | 38 ++++++++++++------------- 11 files changed, 54 insertions(+), 44 deletions(-) diff --git a/docs/contrib/sitemaps.rst b/docs/contrib/sitemaps.rst index 5cdb1f3c4..2a461dff4 100644 --- a/docs/contrib/sitemaps.rst +++ b/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 diff --git a/docs/contrib/staticsitegen.rst b/docs/contrib/staticsitegen.rst index 11d4c1e1e..95a81623b 100644 --- a/docs/contrib/staticsitegen.rst +++ b/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:: diff --git a/docs/getting_started/installation.rst b/docs/getting_started/installation.rst index fac423fa2..294f8310c 100644 --- a/docs/getting_started/installation.rst +++ b/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 diff --git a/docs/getting_started/trying_wagtail.rst b/docs/getting_started/trying_wagtail.rst index ac6541312..e08793308 100644 --- a/docs/getting_started/trying_wagtail.rst +++ b/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 diff --git a/docs/howto/settings.rst b/docs/howto/settings.rst index 6b823cc7e..aa704f9ac 100644 --- a/docs/howto/settings.rst +++ b/docs/howto/settings.rst @@ -23,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 @@ -136,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 --------- @@ -166,7 +166,7 @@ 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 @@ -288,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 @@ -510,8 +510,8 @@ settings.py # EMBEDLY_KEY = '253e433d59dc4d2xa266e9e0de0cb830' -urls.py -------- +``urls.py`` +----------- .. code-block:: python diff --git a/docs/pages/model_recipes.rst b/docs/pages/model_recipes.rst index 34392e7d1..22fa7d1b5 100644 --- a/docs/pages/model_recipes.rst +++ b/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. diff --git a/docs/pages/theory.rst b/docs/pages/theory.rst index 639ee34f2..b33e77572 100644 --- a/docs/pages/theory.rst +++ b/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. diff --git a/docs/reference/project_template.rst b/docs/reference/project_template.rst index 8b5baadbe..93ea616c7 100644 --- a/docs/reference/project_template.rst +++ b/docs/reference/project_template.rst @@ -38,7 +38,7 @@ Location: ``/mysite/core/templates/`` and ``/mysite/core/static/`` The templates directory contains ``base.html``, ``404.html`` and ``500.html``. These files are very commonly needed on Wagtail sites to they have been added into the template. -The static directory contains an empty javascript and sass file. Wagtail uses ``django-compressor`` for compiling and compressing static files. For more information, see: `Django Compressor Documentation `_ +The static directory contains an empty JavaScript and SASS file. Wagtail uses ``django-compressor`` for compiling and compressing static files. For more information, see: `Django Compressor Documentation `_ Vagrant configuration @@ -80,4 +80,4 @@ The Django settings files are split up into ``base.py``, ``dev.py``, ``productio .. tip:: - On production servers, we recommend that you only store secrets in local.py (such as API keys and passwords). This can save you headaches in the future if you are ever trying to debug why a server is behaving badly. If you are using multiple servers which need different settings then we recommend that you create a different ``production.py`` file for each one. + On production servers, we recommend that you only store secrets in ``local.py`` (such as API keys and passwords). This can save you headaches in the future if you are ever trying to debug why a server is behaving badly. If you are using multiple servers which need different settings then we recommend that you create a different ``production.py`` file for each one. diff --git a/docs/releases/0.4.rst b/docs/releases/0.4.rst index 4e985e7c2..59220a77c 100644 --- a/docs/releases/0.4.rst +++ b/docs/releases/0.4.rst @@ -88,7 +88,7 @@ Admin * Removed the "More" section from the menu * Added pagination to page listings * Added a new datetime picker widget - * Updated hallo.js to version 1.0.4 + * Updated ``hallo.js`` to version 1.0.4 * Aesthetic improvements to preview experience * Login screen redirects to dashboard if user is already logged in * Snippets are now ordered alphabetically @@ -103,15 +103,15 @@ Search * Major refactor of Elasticsearch backend * Use ``match`` instead of ``query_string`` queries * Fields are now indexed in Elasticsearch with their correct type - * Filter fields are no longer included in '_all' - * Fields with partial matching are now indexed together into '_partials' + * Filter fields are no longer included in ``_all`` + * Fields with partial matching are now indexed together into ``_partials`` Images ------ * Added ``original`` as a resizing rule supported by the ``{% image %}`` tag - * ``image`` tag now accepts extra keyword arguments to be output as attributes on the img tag + * ``image`` tag now accepts extra keyword arguments to be output as attributes on the ``img`` tag * Added an ``attrs`` property to image rendition objects to output ``src``, ``width``, ``height`` and ``alt`` attributes all in one go diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt index b62ce8036..ed4539b50 100644 --- a/docs/spelling_wordlist.txt +++ b/docs/spelling_wordlist.txt @@ -8,17 +8,27 @@ Elasticsearch Embedly frontend Heroku +hostname jQuery login metadata +mixin Nginx oEmbed PostgreSQL QuerySet Redis +resize +resized +resizing searchable Searchly +sitemap +sitemaps +subpage +subpages Torchbox +uWSGI Vagrantfile Vimeo Wagtail diff --git a/wagtail/wagtailcore/query.py b/wagtail/wagtailcore/query.py index 8911fe8be..2b5ac628d 100644 --- a/wagtail/wagtailcore/query.py +++ b/wagtail/wagtailcore/query.py @@ -13,13 +13,13 @@ class PageQuerySet(MP_NodeQuerySet): def live(self): """ - This filters the queryset to only contain published pages. + This filters the QuerySet to only contain published pages. """ return self.filter(self.live_q()) def not_live(self): """ - This filters the queryset to only contain unpublished pages. + This filters the QuerySet to only contain unpublished pages. """ return self.exclude(self.live_q()) @@ -28,7 +28,7 @@ class PageQuerySet(MP_NodeQuerySet): def in_menu(self): """ - This filters the queryset to only contain pages that are in the menus. + This filters the QuerySet to only contain pages that are in the menus. """ return self.filter(self.in_menu_q()) @@ -40,13 +40,13 @@ class PageQuerySet(MP_NodeQuerySet): def page(self, other): """ - This filters the queryset so it only contains the specified page. + This filters the QuerySet so it only contains the specified page. """ return self.filter(self.page_q(other)) def not_page(self, other): """ - This filters the queryset so it doesn't contain the specified page. + This filters the QuerySet so it doesn't contain the specified page. """ return self.exclude(self.page_q(other)) @@ -60,7 +60,7 @@ class PageQuerySet(MP_NodeQuerySet): def descendant_of(self, other, inclusive=False): """ - This filters the queryset to only contain pages that descend from the specified page. + This filters the QuerySet to only contain pages that descend from the specified page. If inclusive is set to True, it will also contain the page itself (instead of just its descendants). """ @@ -68,7 +68,7 @@ class PageQuerySet(MP_NodeQuerySet): def not_descendant_of(self, other, inclusive=False): """ - This filters the queryset to not contain any pages that descend from the specified page. + This filters the QuerySet to not contain any pages that descend from the specified page. If inclusive is set to True, it will also exclude the specified page. """ @@ -79,13 +79,13 @@ class PageQuerySet(MP_NodeQuerySet): def child_of(self, other): """ - This filters the queryset to only contain pages that are direct children of the specified page. + This filters the QuerySet to only contain pages that are direct children of the specified page. """ return self.filter(self.child_of_q(other)) def not_child_of(self, other): """ - This filters the queryset to not contain any pages that are direct children of the specified page. + This filters the QuerySet to not contain any pages that are direct children of the specified page. """ return self.exclude(self.child_of_q(other)) @@ -103,7 +103,7 @@ class PageQuerySet(MP_NodeQuerySet): def ancestor_of(self, other, inclusive=False): """ - This filters the queryset to only contain pages that are ancestors of the specified page. + This filters the QuerySet to only contain pages that are ancestors of the specified page. If inclusive is set to True, it will also include the specified page. """ @@ -111,7 +111,7 @@ class PageQuerySet(MP_NodeQuerySet): def not_ancestor_of(self, other, inclusive=False): """ - This filters the queryset to not contain any pages that are ancestors of the specified page. + This filters the QuerySet to not contain any pages that are ancestors of the specified page. If inclusive is set to True, it will also exclude the specified page. """ @@ -136,7 +136,7 @@ class PageQuerySet(MP_NodeQuerySet): def sibling_of(self, other, inclusive=True): """ - This filters the queryset to only contain pages that are siblings of the specified page. + This filters the QuerySet to only contain pages that are siblings of the specified page. By default, inclusive is set to True so it will include the specified page in the results. @@ -146,7 +146,7 @@ class PageQuerySet(MP_NodeQuerySet): def not_sibling_of(self, other, inclusive=True): """ - This filters the queryset to not contain any pages that are siblings of the specified page. + This filters the QuerySet to not contain any pages that are siblings of the specified page. By default, inclusive is set to True so it will exclude the specified page from the results. @@ -164,13 +164,13 @@ class PageQuerySet(MP_NodeQuerySet): def type(self, model): """ - This filters the queryset to only contain pages that are an instance of the specified model (including subclasses). + This filters the QuerySet to only contain pages that are an instance of the specified model (including subclasses). """ return self.filter(self.type_q(model)) def not_type(self, model): """ - This filters the queryset to not contain any pages which are an instance of the specified model. + This filters the QuerySet to not contain any pages which are an instance of the specified model. """ return self.exclude(self.type_q(model)) @@ -184,25 +184,25 @@ class PageQuerySet(MP_NodeQuerySet): def public(self): """ - This filters the queryset to only contain pages that are not in a private section + This filters the QuerySet to only contain pages that are not in a private section """ return self.filter(self.public_q()) def not_public(self): """ - This filters the queryset to only contain pages that are in a private section + This filters the QuerySet to only contain pages that are in a private section """ return self.exclude(self.public_q()) def search(self, query_string, fields=None, backend='default'): """ - This runs a search query on all the pages in the queryset + This runs a search query on all the pages in the QuerySet """ search_backend = get_search_backend(backend) return search_backend.search(query_string, self, fields=None) def unpublish(self): """ - This unpublishes all pages in the queryset + This unpublishes all pages in the QuerySet """ self.update(live=False, has_unpublished_changes=True)