diff --git a/CONTRIBUTORS.rst b/CONTRIBUTORS.rst index 0012c4ebb..7f29e58af 100644 --- a/CONTRIBUTORS.rst +++ b/CONTRIBUTORS.rst @@ -299,6 +299,7 @@ Contributors * David Moore * Pierre Geier * Jérôme Lebleu +* Victor Miti Translators =========== diff --git a/docs/advanced_topics/customisation/extending_hallo.rst b/docs/advanced_topics/customisation/extending_hallo.rst index 3e0d9a111..9c95cac33 100644 --- a/docs/advanced_topics/customisation/extending_hallo.rst +++ b/docs/advanced_topics/customisation/extending_hallo.rst @@ -39,8 +39,8 @@ The constructor for ``HalloPlugin`` accepts the following keyword arguments: * ``name`` - the plugin name as defined in the JavaScript code. ``hallo.js`` plugin names are prefixed with the ``"IKS."`` namespace, but the name passed here should be without the prefix. * ``options`` - a dictionary (or other JSON-serialisable object) of options to be passed to the JavaScript plugin code on initialisation - * ``js`` - a list of JavaScript files to be imported for this plugin, defined in the same way as a `Django form media `_ definition - * ``css`` - a dictionary of CSS files to be imported for this plugin, defined in the same way as a `Django form media `_ definition + * ``js`` - a list of JavaScript files to be imported for this plugin, defined in the same way as a `Django form media `_ definition + * ``css`` - a dictionary of CSS files to be imported for this plugin, defined in the same way as a `Django form media `_ definition * ``order`` - an index number (default 100) specifying the order in which plugins should be listed, which in turn determines the order buttons will appear in the toolbar When writing the front-end code for the plugin, Wagtail’s Hallo implementation offers two extension points: diff --git a/docs/advanced_topics/deploying.rst b/docs/advanced_topics/deploying.rst index 4e144d4bb..decc0a8c8 100644 --- a/docs/advanced_topics/deploying.rst +++ b/docs/advanced_topics/deploying.rst @@ -21,11 +21,11 @@ We know of Wagtail sites running on `Heroku `_, and can be configured to store uploaded images and documents on a cloud storage service such as Amazon S3; this is done through the `DEFAULT_FILE_STORAGE `_ setting in conjunction with an add-on package such as `django-storages `_. Be aware that setting up remote storage will not entirely offload file handling tasks from the application server - some Wagtail functionality requires files to be read back by the application server. In particular, documents are served through a Django view in order to enforce permission checks, and original image files need to be read back whenever a new resized rendition is created. +Wagtail follows `Django's conventions for managing uploaded files `_, and can be configured to store uploaded images and documents on a cloud storage service such as Amazon S3; this is done through the `DEFAULT_FILE_STORAGE `_ setting in conjunction with an add-on package such as `django-storages `_. Be aware that setting up remote storage will not entirely offload file handling tasks from the application server - some Wagtail functionality requires files to be read back by the application server. In particular, documents are served through a Django view in order to enforce permission checks, and original image files need to be read back whenever a new resized rendition is created. Note that the django-storages Amazon S3 backends (``storages.backends.s3boto.S3BotoStorage`` and ``storages.backends.s3boto3.S3Boto3Storage``) **do not correctly handle duplicate filenames** in their default configuration. When using these backends, ``AWS_S3_FILE_OVERWRITE`` must be set to ``False``. -If you are also serving Wagtail's static files from remote storage (using Django's `STATICFILES_STORAGE `_ setting), you'll need to ensure that it is configured to serve `CORS HTTP headers `_, as current browsers will reject remotely-hosted font files that lack a valid header. For Amazon S3, refer to the documentation `Setting Bucket and Object Access Permissions `_, or (for the ``storages.backends.s3boto.S3BotoStorage`` backend only) add the following to your Django settings: +If you are also serving Wagtail's static files from remote storage (using Django's `STATICFILES_STORAGE `_ setting), you'll need to ensure that it is configured to serve `CORS HTTP headers `_, as current browsers will reject remotely-hosted font files that lack a valid header. For Amazon S3, refer to the documentation `Setting Bucket and Object Access Permissions `_, or (for the ``storages.backends.s3boto.S3BotoStorage`` backend only) add the following to your Django settings: .. code-block:: python diff --git a/docs/advanced_topics/documents/custom_document_model.rst b/docs/advanced_topics/documents/custom_document_model.rst index f181f61b4..cdcac8e93 100644 --- a/docs/advanced_topics/documents/custom_document_model.rst +++ b/docs/advanced_topics/documents/custom_document_model.rst @@ -54,7 +54,7 @@ Then in your settings module: When changing an existing site to use a custom document model, no documents will be copied to the new model automatically. Copying old documents to the new model would need to be done manually with a - `data migration `_. + `data migration `_. Any templates that reference the builtin document model will still continue to work as before. diff --git a/docs/advanced_topics/i18n/index.rst b/docs/advanced_topics/i18n/index.rst index 1fd4ed191..48b9b8f13 100644 --- a/docs/advanced_topics/i18n/index.rst +++ b/docs/advanced_topics/i18n/index.rst @@ -4,7 +4,7 @@ Internationalisation This document describes the internationalisation features of Wagtail and how to create multi-lingual sites. -Wagtail uses Django's `Internationalisation framework `_ so most of the steps are the same as other Django projects. +Wagtail uses Django's `Internationalisation framework `_ so most of the steps are the same as other Django projects. .. contents:: @@ -34,8 +34,8 @@ Changing the primary language of your Wagtail installation The default language of Wagtail is ``en-us`` (American English). You can change this by tweaking a couple of Django settings: - - Make sure `USE_I18N `_ is set to ``True`` - - Set `LANGUAGE_CODE `_ to your websites' primary language + - Make sure `USE_I18N `_ is set to ``True`` + - Set `LANGUAGE_CODE `_ to your websites' primary language If there is a translation available for your language, the Wagtail admin backend should now be in the language you've chosen. @@ -43,7 +43,7 @@ If there is a translation available for your language, the Wagtail admin backend Creating sites with multiple languages ====================================== -You can create sites with multiple language support by leveraging Django's `translation features `_. +You can create sites with multiple language support by leveraging Django's `translation features `_. This section of the documentation will show you how to use Django's translation features with Wagtail and also describe a couple of methods for storing/retrieving translated content using Wagtail pages. @@ -51,7 +51,7 @@ This section of the documentation will show you how to use Django's translation Enabling multiple language support ---------------------------------- -Firstly, make sure the `USE_I18N `_ Django setting is set to ``True``. +Firstly, make sure the `USE_I18N `_ Django setting is set to ``True``. To enable multi-language support, add ``django.middleware.locale.LocaleMiddleware`` to your ``MIDDLEWARE``: @@ -63,7 +63,7 @@ To enable multi-language support, add ``django.middleware.locale.LocaleMiddlewar 'django.middleware.locale.LocaleMiddleware', ) -This middleware class looks at the user's browser language and sets the `language of the site accordingly `_. +This middleware class looks at the user's browser language and sets the `language of the site accordingly `_. Serving different languages from different URLs @@ -118,7 +118,7 @@ Static text in templates needs to be marked up in a way that allows Django's ``m As Wagtail uses Django's templates, inserting this markup and the workflow for exporting and translating the strings is the same as any other Django project. -See: https://docs.djangoproject.com/en/1.8/topics/i18n/translation/#internationalization-in-template-code +See: https://docs.djangoproject.com/en/stable/topics/i18n/translation/#internationalization-in-template-code Translating content diff --git a/docs/advanced_topics/images/custom_image_model.rst b/docs/advanced_topics/images/custom_image_model.rst index 7af4d4185..bd4e9d9c9 100644 --- a/docs/advanced_topics/images/custom_image_model.rst +++ b/docs/advanced_topics/images/custom_image_model.rst @@ -66,7 +66,7 @@ Then set the ``WAGTAILIMAGES_IMAGE_MODEL`` setting to point to it: When changing an existing site to use a custom image model, no images will be copied to the new model automatically. Copying old images to the new model would need to be done manually with a - `data migration `_. + `data migration `_. Any templates that reference the builtin image model will still continue to work as before but would need to be updated in order to see any new images. diff --git a/docs/advanced_topics/jinja2.rst b/docs/advanced_topics/jinja2.rst index fc77011dd..cda445ed4 100644 --- a/docs/advanced_topics/jinja2.rst +++ b/docs/advanced_topics/jinja2.rst @@ -30,7 +30,7 @@ Django needs to be configured to support Jinja2 templates. As the Wagtail admin Jinja templates must be placed in a ``jinja2/`` directory in your app. The template for an ``EventPage`` model in an ``events`` app should be created at ``events/jinja2/events/event_page.html``. -By default, the Jinja environment does not have any Django functions or filters. The Django documentation has more information on `configuring Jinja for Django `_. +By default, the Jinja environment does not have any Django functions or filters. The Django documentation has more information on `configuring Jinja for Django `_. ``self`` in templates ===================== diff --git a/docs/advanced_topics/performance.rst b/docs/advanced_topics/performance.rst index 5fdc8197a..df57ac251 100644 --- a/docs/advanced_topics/performance.rst +++ b/docs/advanced_topics/performance.rst @@ -45,7 +45,7 @@ Wagtail is tested on PostgreSQL, SQLite and MySQL. It should work on some third- Templates --------- -The overhead from reading and compiling templates can add up. In some cases a significant performance improvement can be gained by using `Django's cached template loader `_: +The overhead from reading and compiling templates can add up. In some cases a significant performance improvement can be gained by using `Django's cached template loader `_: .. code-block:: python diff --git a/docs/advanced_topics/privacy.rst b/docs/advanced_topics/privacy.rst index c50dd46e8..0b9ffe479 100644 --- a/docs/advanced_topics/privacy.rst +++ b/docs/advanced_topics/privacy.rst @@ -23,7 +23,7 @@ The basic login page can be customised by setting ``WAGTAIL_FRONTEND_LOGIN_TEMPL WAGTAIL_FRONTEND_LOGIN_TEMPLATE = 'myapp/login.html' -Wagtail uses Django's standard ``django.contrib.auth.views.login`` view here, and so the context variables available on the template are as detailed in `Django's login view documentation `_. +Wagtail uses Django's standard ``django.contrib.auth.views.login`` view here, and so the context variables available on the template are as detailed in `Django's login view documentation `_. If the stock Django login view is not suitable - for example, you wish to use an external authentication system, or you are integrating Wagtail into an existing Django site that already has a working login view - you can specify the URL of the login view via the ``WAGTAIL_FRONTEND_LOGIN_URL`` setting: diff --git a/docs/advanced_topics/settings.rst b/docs/advanced_topics/settings.rst index 47adeb822..7229a0fc3 100644 --- a/docs/advanced_topics/settings.rst +++ b/docs/advanced_topics/settings.rst @@ -433,7 +433,7 @@ Date and DateTime inputs WAGTAIL_DATETIME_FORMAT = '%d.%m.%Y. %H:%M' -Specifies the date and datetime format to be used in input fields in the Wagtail admin. The format is specified in `Python datetime module syntax `_, and must be one of the recognised formats listed in the ``DATE_INPUT_FORMATS`` or ``DATETIME_INPUT_FORMATS`` setting respectively (see `DATE_INPUT_FORMATS `_). +Specifies the date and datetime format to be used in input fields in the Wagtail admin. The format is specified in `Python datetime module syntax `_, and must be one of the recognised formats listed in the ``DATE_INPUT_FORMATS`` or ``DATETIME_INPUT_FORMATS`` setting respectively (see `DATE_INPUT_FORMATS `_). .. _WAGTAIL_USER_TIME_ZONES: diff --git a/docs/getting_started/integrating_into_django.rst b/docs/getting_started/integrating_into_django.rst index 9e9a4a36f..fdf160126 100644 --- a/docs/getting_started/integrating_into_django.rst +++ b/docs/getting_started/integrating_into_django.rst @@ -102,7 +102,7 @@ Finally, your project needs to be set up to serve user-uploaded files from ``MED # ... the rest of your URLconf goes here ... ] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT) -Note that this only works in development mode (``DEBUG = True``); in production, you will need to configure your web server to serve files from ``MEDIA_ROOT``. For further details, see the Django documentation: `Serving files uploaded by a user during development `_ and `Deploying static files `_. +Note that this only works in development mode (``DEBUG = True``); in production, you will need to configure your web server to serve files from ``MEDIA_ROOT``. For further details, see the Django documentation: `Serving files uploaded by a user during development `_ and `Deploying static files `_. With this configuration in place, you are ready to run ``./manage.py migrate`` to create the database tables used by Wagtail. diff --git a/docs/getting_started/tutorial.rst b/docs/getting_started/tutorial.rst index 868ed8bd1..8d92d6f0d 100644 --- a/docs/getting_started/tutorial.rst +++ b/docs/getting_started/tutorial.rst @@ -82,7 +82,7 @@ Edit ``home/models.py`` as follows, to add a ``body`` field to the model: ] ``body`` is defined as ``RichTextField``, a special Wagtail field. You -can use any of the `Django core fields `__. ``content_panels`` define the +can use any of the `Django core fields `__. ``content_panels`` define the capabilities and the layout of the editing interface. :doc:`More on creating Page models. <../topics/pages>` Run ``python manage.py makemigrations``, then @@ -97,7 +97,7 @@ to the model. Wagtail uses normal Django templates to render each page type. By default, it will look for a template filename formed from the app and model name, separating capital letters with underscores (e.g. HomePage within the 'home' app becomes ``home/home_page.html``). This template file can exist in any location recognised by -`Django's template rules `__; conventionally it is placed under a ``templates`` folder within the app. +`Django's template rules `__; conventionally it is placed under a ``templates`` folder within the app. Edit ``home/templates/home/home_page.html`` to contain the following: diff --git a/docs/reference/contrib/forms/customisation.rst b/docs/reference/contrib/forms/customisation.rst index b325d62cd..f2f14d064 100644 --- a/docs/reference/contrib/forms/customisation.rst +++ b/docs/reference/contrib/forms/customisation.rst @@ -609,7 +609,7 @@ Customise form submissions listing in Wagtail Admin The Admin listing of form submissions can be customised by setting the attribute ``submissions_list_view_class`` on your FormPage model. -The list view class must be a subclass of ``SubmissionsListView`` from ``wagtail.contrib.forms.views``, which is a child class of `Django's class based ListView `_. +The list view class must be a subclass of ``SubmissionsListView`` from ``wagtail.contrib.forms.views``, which is a child class of `Django's class based ListView `_. Example: diff --git a/docs/reference/contrib/forms/index.rst b/docs/reference/contrib/forms/index.rst index c4dff0265..ef0ddde3f 100644 --- a/docs/reference/contrib/forms/index.rst +++ b/docs/reference/contrib/forms/index.rst @@ -7,7 +7,7 @@ Form builder The ``wagtailforms`` module allows you to set up single-page forms, such as a 'Contact us' form, as pages of a Wagtail site. It provides a set of base models that site implementers can extend to create their own ``FormPage`` type with their own site-specific templates. Once a page type has been set up in this way, editors can build forms within the usual page editor, consisting of any number of fields. Form submissions are stored for later retrieval through a new 'Forms' section within the Wagtail admin interface; in addition, they can be optionally e-mailed to an address specified by the editor. .. note:: - **wagtailforms is not a replacement for** `Django's form support `_. It is designed as a way for page authors to build general-purpose data collection forms without having to write code. If you intend to build a form that assigns specific behaviour to individual fields (such as creating user accounts), or needs a custom HTML layout, you will almost certainly be better served by a standard Django form, where the fields are fixed in code rather than defined on-the-fly by a page author. See the `wagtail-form-example project `_ for an example of integrating a Django form into a Wagtail page. + **wagtailforms is not a replacement for** `Django's form support `_. It is designed as a way for page authors to build general-purpose data collection forms without having to write code. If you intend to build a form that assigns specific behaviour to individual fields (such as creating user accounts), or needs a custom HTML layout, you will almost certainly be better served by a standard Django form, where the fields are fixed in code rather than defined on-the-fly by a page author. See the `wagtail-form-example project `_ for an example of integrating a Django form into a Wagtail page. .. _form_builder_usage: diff --git a/docs/reference/contrib/modeladmin/indexview.rst b/docs/reference/contrib/modeladmin/indexview.rst index 1b54bd1c1..f7d2711eb 100644 --- a/docs/reference/contrib/modeladmin/indexview.rst +++ b/docs/reference/contrib/modeladmin/indexview.rst @@ -304,7 +304,7 @@ your project is using, and without any additional setup or configuration. --------------------------- **Expected value**: A list or tuple in the same format as a model’s -[``ordering``](https://docs.djangoproject.com/en/1.9/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display) parameter. +[``ordering``](https://docs.djangoproject.com/en/stable/ref/contrib/admin/#django.contrib.admin.ModelAdmin.list_display) parameter. Set ``ordering`` to specify the default ordering of objects when listed by IndexView. If not provided, the model’s default ordering will be respected. diff --git a/docs/reference/pages/model_reference.rst b/docs/reference/pages/model_reference.rst index 583204e1a..f4f1b88d4 100644 --- a/docs/reference/pages/model_reference.rst +++ b/docs/reference/pages/model_reference.rst @@ -197,7 +197,7 @@ In addition to the model fields provided, ``Page`` has many properties and metho .. attribute:: is_creatable - Controls if this page can be created through the Wagtail administration. Defaults to True, and is not inherited by subclasses. This is useful when using `multi-table inheritance `_, to stop the base model from being created as an actual page. + Controls if this page can be created through the Wagtail administration. Defaults to True, and is not inherited by subclasses. This is useful when using `multi-table inheritance `_, to stop the base model from being created as an actual page. .. attribute:: exclude_fields_in_copy diff --git a/docs/reference/signals.rst b/docs/reference/signals.rst index f12028fba..9f7912d3a 100644 --- a/docs/reference/signals.rst +++ b/docs/reference/signals.rst @@ -4,7 +4,7 @@ Signals ======= Wagtail's :ref:`page-revision-model-ref` and :ref:`page-model-ref` implement -`Signals `__ from ``django.dispatch``. +`Signals `__ from ``django.dispatch``. Signals are useful for creating side-effects from page publish/unpublish events. For example, you could use signals to send publish notifications to a messaging service, or ``POST`` messages to another app that's consuming the API, such as a static site generator. @@ -71,7 +71,7 @@ wish to do something when a new blog post is published: Wagtail provides access to a list of registered page types through the ``get_page_models()`` function in ``wagtail.core.models``. -Read the `Django documentation `__ for more information about specifying senders. +Read the `Django documentation `__ for more information about specifying senders. page_unpublished diff --git a/docs/releases/1.0.rst b/docs/releases/1.0.rst index c8b83b4ab..f996da157 100644 --- a/docs/releases/1.0.rst +++ b/docs/releases/1.0.rst @@ -198,7 +198,7 @@ should work fine without them. ``RoutablePage`` now uses decorator syntax for defining views ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -In previous versions of Wagtail, page types that used the :class:`~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin` had endpoints configured by setting their :attr:`~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin.subpage_urls` attribute to a list of urls with view names. This will not work on Django 1.8 as view names can no longer be passed into a url (see: https://docs.djangoproject.com/en/1.8/releases/1.8/#django-conf-urls-patterns). +In previous versions of Wagtail, page types that used the :class:`~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin` had endpoints configured by setting their :attr:`~wagtail.contrib.wagtailroutablepage.models.RoutablePageMixin.subpage_urls` attribute to a list of urls with view names. This will not work on Django 1.8 as view names can no longer be passed into a url (see: https://docs.djangoproject.com/en/stable/releases/1.8/#django-conf-urls-patterns). Wagtail 1.0 introduces a new syntax where each view function is annotated with a ``@route`` decorator - see :ref:`routable_page_mixin`. diff --git a/docs/releases/1.10.rst b/docs/releases/1.10.rst index 683c257fb..c1f47f236 100644 --- a/docs/releases/1.10.rst +++ b/docs/releases/1.10.rst @@ -159,7 +159,7 @@ Projects using :ref:`custom image models ` no longer need to Adding / editing users through Wagtail admin no longer sets ``is_staff`` flag ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Previously, the ``is_staff`` flag (which grants access to the Django admin interface) was automatically set for superusers, and reset for other users, when creating and updating users through the Wagtail admin. This behaviour has now been removed, since Wagtail is designed to work independently of the Django admin. If you need to reinstate the old behaviour, you can set up a `pre_save signal handler `_ on the User model to set the flag appropriately. +Previously, the ``is_staff`` flag (which grants access to the Django admin interface) was automatically set for superusers, and reset for other users, when creating and updating users through the Wagtail admin. This behaviour has now been removed, since Wagtail is designed to work independently of the Django admin. If you need to reinstate the old behaviour, you can set up a `pre_save signal handler `_ on the User model to set the flag appropriately. Specifying the full file name in documents URL is mandatory diff --git a/docs/releases/1.6.1.rst b/docs/releases/1.6.1.rst index d4c061002..a89c3cab8 100644 --- a/docs/releases/1.6.1.rst +++ b/docs/releases/1.6.1.rst @@ -19,7 +19,7 @@ Minor features Bug fixes ~~~~~~~~~ -* Wagtail's middleware classes are now compatible with Django 1.10's `new-style middleware `_ (Karl Hobley) +* Wagtail's middleware classes are now compatible with Django 1.10's `new-style middleware `_ (Karl Hobley) * The :meth:`~wagtail.core.models.Page.can_create_at` method is now checked in the create page view (Mikalai Radchuk) * Fixed regression on Django 1.10.1 causing Page subclasses to fail to use PageManager (Matt Westcott) * ChoiceBlocks with lazy translations as option labels no longer break Elasticsearch indexing (Matt Westcott) diff --git a/docs/releases/2.0.rst b/docs/releases/2.0.rst index 5cde9b17e..54474c556 100644 --- a/docs/releases/2.0.rst +++ b/docs/releases/2.0.rst @@ -123,7 +123,7 @@ Python 2.7, Django 1.8 and Django 1.10 are no longer supported in this release. Added support for Django 2.0 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Before upgrading to Django 2.0, you are advised to review the `release notes `_, especially the `backwards incompatible changes `_ and `removed features `_. +Before upgrading to Django 2.0, you are advised to review the `release notes `_, especially the `backwards incompatible changes `_ and `removed features `_. Wagtail module path updates diff --git a/docs/topics/pages.rst b/docs/topics/pages.rst index 50901cb6c..e790f8dd2 100644 --- a/docs/topics/pages.rst +++ b/docs/topics/pages.rst @@ -4,15 +4,15 @@ Page models Each page type (a.k.a. content type) in Wagtail is represented by a Django model. All page models must inherit from the :class:`wagtail.core.models.Page` class. -As all page types are Django models, you can use any field type that Django provides. See `Model field reference `_ for a complete list of field types you can use. Wagtail also provides :class:`~wagtail.core.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content. +As all page types are Django models, you can use any field type that Django provides. See `Model field reference `_ for a complete list of field types you can use. Wagtail also provides :class:`~wagtail.core.fields.RichTextField` which provides a WYSIWYG editor for editing rich-text content. .. topic:: Django models If you're not yet familiar with Django models, have a quick look at the following links to get you started: - * `Creating models `_ - * `Model syntax `_ + * `Creating models `_ + * `Model syntax `_ An example Wagtail page model @@ -256,7 +256,7 @@ You just need to create a template in a location where it can be accessed with t Template context ---------------- -Wagtail renders templates with the ``page`` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, use ``{{ page.title }}``. All variables provided by `context processors `_ are also available. +Wagtail renders templates with the ``page`` variable bound to the page instance being rendered. Use this to access the content of the page. For example, to get the title of the current page, use ``{{ page.title }}``. All variables provided by `context processors `_ are also available. Customising template context @@ -408,7 +408,7 @@ The first argument must match the value of the ``related_name`` attribute of the Working with pages ================== -Wagtail uses Django's `multi-table inheritance `_ feature to allow multiple page models to be used in the same tree. +Wagtail uses Django's `multi-table inheritance `_ feature to allow multiple page models to be used in the same tree. Each page is added to both Wagtail's builtin :class:`~wagtail.core.models.Page` model as well as its user-defined model (such as the ``BlogPage`` model created earlier). diff --git a/docs/topics/permissions.rst b/docs/topics/permissions.rst index b46e0f3b1..dafe94def 100644 --- a/docs/topics/permissions.rst +++ b/docs/topics/permissions.rst @@ -4,7 +4,7 @@ Permissions =========== -Wagtail adapts and extends `the Django permission system `_ to cater for the needs of website content creation, such as moderation workflows, and multiple teams working on different areas of a site (or multiple sites within the same Wagtail installation). Permissions can be configured through the 'Groups' area of the Wagtail admin interface, under 'Settings'. +Wagtail adapts and extends `the Django permission system `_ to cater for the needs of website content creation, such as moderation workflows, and multiple teams working on different areas of a site (or multiple sites within the same Wagtail installation). Permissions can be configured through the 'Groups' area of the Wagtail admin interface, under 'Settings'. Page permissions diff --git a/docs/topics/search/searching.rst b/docs/topics/search/searching.rst index c07d68a53..07c9559b2 100644 --- a/docs/topics/search/searching.rst +++ b/docs/topics/search/searching.rst @@ -12,7 +12,7 @@ Searching Searching QuerySets =================== -Wagtail search is built on Django's `QuerySet API `_. You should be able to search any Django QuerySet provided the model and the fields being filtered on have been added to the search index. +Wagtail search is built on Django's `QuerySet API `_. You should be able to search any Django QuerySet provided the model and the fields being filtered on have been added to the search index. Searching Pages diff --git a/docs/topics/streamfield.rst b/docs/topics/streamfield.rst index 56edee21d..a35ab80b5 100644 --- a/docs/topics/streamfield.rst +++ b/docs/topics/streamfield.rst @@ -165,7 +165,7 @@ DateBlock A date picker. The keyword arguments ``required`` (default: True), ``help_text`` and ``format`` are accepted. ``format`` (default: None) - Date format. This must be one of the recognised formats listed in the `DATE_INPUT_FORMATS `_ setting. If not specified Wagtail will use ``WAGTAIL_DATE_FORMAT`` setting with fallback to '%Y-%m-%d'. + Date format. This must be one of the recognised formats listed in the `DATE_INPUT_FORMATS `_ setting. If not specified Wagtail will use ``WAGTAIL_DATE_FORMAT`` setting with fallback to '%Y-%m-%d'. TimeBlock ~~~~~~~~~ @@ -182,7 +182,7 @@ DateTimeBlock A combined date / time picker. The keyword arguments ``required`` (default: True), ``help_text`` and ``format`` are accepted. ``format`` (default: None) - Date format. This must be one of the recognised formats listed in the `DATETIME_INPUT_FORMATS `_ setting. If not specified Wagtail will use ``WAGTAIL_DATETIME_FORMAT`` setting with fallback to '%Y-%m-%d %H:%M'. + Date format. This must be one of the recognised formats listed in the `DATETIME_INPUT_FORMATS `_ setting. If not specified Wagtail will use ``WAGTAIL_DATETIME_FORMAT`` setting with fallback to '%Y-%m-%d %H:%M'. RichTextBlock ~~~~~~~~~~~~~ @@ -951,7 +951,7 @@ As with any model field in Django, any changes to a model definition that affect To mitigate this, StructBlock, StreamBlock and ChoiceBlock implement additional logic to ensure that any subclasses of these blocks are deconstructed to plain instances of StructBlock, StreamBlock and ChoiceBlock -- in this way, the migrations avoid having any references to your custom class definitions. This is possible because these block types provide a standard pattern for inheritance, and know how to reconstruct the block definition for any subclass that follows that pattern. -If you subclass any other block class, such as ``FieldBlock``, you will need to either keep that class definition in place for the lifetime of your project, or implement a `custom deconstruct method `__ that expresses your block entirely in terms of classes that are guaranteed to remain in place. Similarly, if you customise a StructBlock, StreamBlock or ChoiceBlock subclass to the point where it can no longer be expressed as an instance of the basic block type -- for example, if you add extra arguments to the constructor -- you will need to provide your own ``deconstruct`` method. +If you subclass any other block class, such as ``FieldBlock``, you will need to either keep that class definition in place for the lifetime of your project, or implement a `custom deconstruct method `__ that expresses your block entirely in terms of classes that are guaranteed to remain in place. Similarly, if you customise a StructBlock, StreamBlock or ChoiceBlock subclass to the point where it can no longer be expressed as an instance of the basic block type -- for example, if you add extra arguments to the constructor -- you will need to provide your own ``deconstruct`` method. .. _streamfield_migrating_richtext: