mirror
/
wagtail
kopia lustrzana https://github.com/wagtail/wagtail
1
0
Forkuj 0
Kod Zgłoszenia Packages Projekty Wydania Wiki Aktywność

Various typo fixes and grammar/clarity improvements.

pull/2175/merge
Robert Rollins 2016-03-03 19:12:38 -08:00 zatwierdzone przez Matt Westcott
rodzic d134eadb2a
commit 6446c42132
10 zmienionych plików z 140 dodań i 131 usunięć
Pokaż statystyki Ściągnij plik aktualizacji Ściągnij plik porównania Expand all files Collapse all files

2
docs/advanced_topics/customisation/page_editing_interface.rst
Wyświetl plik

@ -93,7 +93,7 @@ As an example, add a "thumbnail" format:
register_image_format(Format('thumbnail', 'Thumbnail', 'richtext-image thumbnail', 'max-120x120'))
To begin, import the the ``Format`` class, ``register_image_format`` function, and optionally ``unregister_image_format`` function. To register a new ``Format``, call the ``register_image_format`` with the ``Format`` object as the argument. The ``Format`` class takes the following constructor arguments:
To begin, import the ``Format`` class, ``register_image_format`` function, and optionally ``unregister_image_format`` function. To register a new ``Format``, call the ``register_image_format`` with the ``Format`` object as the argument. The ``Format`` class takes the following constructor arguments:
``name``
The unique key used to identify the format. To unregister this format, call ``unregister_image_format`` with this string as the only argument.

53
docs/topics/images.rst
Wyświetl plik

@ -16,17 +16,18 @@ For example:
{% load wagtailimages_tags %}
...
<!-- Display the image scaled to a width of 400 pixels: -->
{% image page.photo width-400 %}
<!-- or a square thumbnail: -->
<!-- Display it again, but this time as a square thumbnail: -->
{% image page.photo fill-80x80 %}
In the above syntax example ``[image]`` is the Django object refering to the image. If your page model defined a field called "photo" then ``[image]`` would probably be ``page.photo``. The ``[resize-rule]`` defines how the image is to be resized when inserted into the page; various resizing methods are supported, to cater for different usage cases (e.g. lead images that span the whole width of the page, or thumbnails to be cropped to a fixed size).
In the above syntax example ``[image]`` is the Django object refering to the image. If your page model defined a field called "photo" then ``[image]`` would probably be ``page.photo``. The ``[resize-rule]`` defines how the image is to be resized when inserted into the page. Various resizing methods are supported, to cater to different use cases (e.g. lead images that span the whole width of the page, or thumbnails to be cropped to a fixed size).
Note that a space separates ``[image]`` and ``[resize-rule]``, but the resize rule must not contain spaces.
Note that a space separates ``[image]`` and ``[resize-rule]``, but the resize rule must not contain spaces. The width is always specified before the height. Resized images will maintain their original aspect ratio unless the ``fill`` rule is used, which may result in some pixels being cropped.
The available resizing methods are:
The available resizing methods are as follows:
.. glossary::
@ -40,7 +41,7 @@ The available resizing methods are:
Fit **within** the given dimensions.
The longest edge will be reduced to the equivalent dimension size defined. For example, a portrait image of width 1000, height 2000, treated with the ``max`` dimensions ``1000x500`` (landscape) would result in the image shrunk so the *height* was 500 pixels and the width 250.
The longest edge will be reduced to the matching dimension specified. For example, a portrait image of width 1000 and height 2000, treated with the ``max-1000x500`` rule (a landscape layout) would result in the image being shrunk so the *height* was 500 pixels and the width was 250.
``min``
(takes two dimensions)
@ -51,7 +52,7 @@ The available resizing methods are:
**Cover** the given dimensions.
This may result in an image slightly **larger** than the dimensions you specify. e.g A square image of width 2000, height 2000, treated with the ``min`` dimensions ``500x200`` (landscape) would have its height and width changed to 500, i.e matching the width required, but greater than the height.
This may result in an image slightly **larger** than the dimensions you specify. A square image of width 2000 and height 2000, treated with the ``min-500x200`` rule would have its height and width changed to 500, i.e matching the *width* of the resize-rule, but greater than the height.
``width``
(takes one dimension)
@ -78,31 +79,31 @@ The available resizing methods are:
{% image page.photo fill-200x200 %}
Resize and **crop** to fill the **exact** dimensions.
Resize and **crop** to fill the **exact** dimensions specified.
This can be particularly useful for websites requiring square thumbnails of arbitrary images. For example, a landscape image of width 2000, height 1000, treated with ``fill`` dimensions ``200x200`` would have its height reduced to 200, then its width (ordinarily 400) cropped to 200.
This can be particularly useful for websites requiring square thumbnails of arbitrary images. For example, a landscape image of width 2000 and height 1000 treated with the ``fill200x200`` rule would have its height reduced to 200, then its width (ordinarily 400) cropped to 200.
This filter will crop to the image's focal point if it has been set. If not, it will crop to the centre of the image.
This resize-rule will crop to the image's focal point if it has been set. If not, it will crop to the centre of the image.
**On images that won't upscale**
It's possible to request an image with ``fill`` dimensions that the image can't support without upscaling. e.g an image 400x200 requested with ``fill-400x400``. In this situation the *ratio of the requested fill* will be matched, but the dimension will not. So with that example 400x200 image, the resulting image will be 200x200.
It's possible to request an image with ``fill`` dimensions that the image can't support without upscaling. e.g. an image of width 400 and height 200 requested with ``fill-400x400``. In this situation the *ratio of the requested fill* will be matched, but the dimension will not. So that example 400x200 image (a 2:1 ratio) could become 200x200 (a 1:1 ratio, matching the resize-rule).
**Cropping closer to the focal point**
By default, Wagtail will only crop to change the aspect ratio of the image.
By default, Wagtail will only crop enough to change the aspect ratio of the image to match the ratio in the resize-rule.
In some cases (thumbnails, for example) it may be nice to crop closer to the focal point so the subject of the image is easier to see.
In some cases (e.g. thumbnails), it may be preferable to crop closer to the focal point, so that the subject of the image is more prominent.
You can do this by appending ``-c<percentage>`` at the end of the method. For example, if you would like the image to be cropped as closely as possible to its focal point, add ``-c100`` to the end of the method.
You can do this by appending ``-c<percentage>`` at the end of the resize-rule. For example, if you would like the image to be cropped as closely as possible to its focal point, add ``-c100``:
.. code-block:: html+django
{% image page.photo fill-200x200-c100 %}
This will crop the image as much as it can, but will never crop into the focal point.
This will crop the image as much as it can, without cropping into the focal point.
If you find that ``-c100`` is too close, you can try ``-c75`` or ``-c50`` (any whole number from 0 to 100 is accepted).
If you find that ``-c100`` is too close, you can try ``-c75`` or ``-c50``. Any whole number from 0 to 100 is accepted.
``original``
(takes no dimensions)
@ -111,7 +112,7 @@ The available resizing methods are:
{% image page.photo original %}
Leaves the image at its original size - no resizing is performed.
Renders the image at its original size.
@ -148,13 +149,13 @@ Wagtail can assign the image data to another variable using Django's ``as`` synt
height="{{ tmp_photo.height }}" alt="{{ tmp_photo.alt }}" class="my-custom-class" />
This syntax exposes the underlying image "Rendition" (``tmp_photo``) to the developer. A "Rendition" contains just the information specific to the way you've requested to format the image i.e dimensions and source URL.
This syntax exposes the underlying image Rendition (``tmp_photo``) to the developer. A "Rendition" contains the information specific to the way you've requested to format the image using the resize-rule, i.e. dimensions and source URL.
If your site defines a custom image model using ``AbstractImage``, then any additional fields you add to an image e.g a copyright holder, are **not** part of the image *rendition*, they're part of the image *model*.
If your site defines a custom image model using ``AbstractImage``, any additional fields you add to an image (e.g. a copyright holder) are **not** included in the rendition.
Therefore in the above example, if you'd added the field ``author`` to your AbstractImage you'd access it using ``{{ page.photo.author }}`` not ``{{ tmp_photo.author }}``.
Therefore, if you'd added the field ``author`` to your AbstractImage in the above example, you'd access it using ``{{ page.photo.author }}`` rather than ``{{ tmp_photo.author }}``.
(Due to the links in the database between renditions and their parent image, you could also access it as ``{{ tmp_photo.image.author }}`` but this is clearly confusing.)
(Due to the links in the database between renditions and their parent image, you *could* access it as ``{{ tmp_photo.image.author }}``, but that has reduced readability.)
.. Note::
@ -174,25 +175,25 @@ You can also use the ``attrs`` property as a shorthand to output the attributes
Images embedded in rich text
----------------------------
The information above relates to images defined via image-specific fields in your model, but images can also be embedded arbitrarily in Rich Text fields by the editor (see :ref:`rich-text`).
The information above relates to images defined via image-specific fields in your model. However, images can also be embedded arbitrarily in Rich Text fields by the page editor (see :ref:`rich-text`).
Images embedded in Rich Text fields can't be controlled by the template developer as easily. There are no image objects to work with, so the ``{% image %}`` template tag can't be used. Instead editors can choose from one of a number of image "Formats" at the point of inserting images into their text.
Images embedded in Rich Text fields can't be controlled by the template developer as easily. There are no image objects to work with, so the ``{% image %}`` template tag can't be used. Instead, editors can choose from one of a number of image "Formats" at the point of inserting images into their text.
Wagtail comes with three pre-defined image formats, but more can be defined in Python by the developer. These formats are:
.. glossary::
``Full width``
Creates an image tag using the filter ``width-800`` and given the CSS class ``full-width``
Creates an image rendition using ``width-800``, giving the <img> tag the CSS class ``full-width``.
``Left-aligned``
Creates an image tag with the filter ``width-500`` and given the CSS class ``left``
Creates an image rendition using ``width-500``, giving the <img> tag the CSS class ``left``.
``Right-aligned``
Creates an image tag with the filter ``width-500`` and given the CSS class ``right``
Creates an image rendition using ``width-500``, giving the <img> tag the CSS class ``right``.
.. Note::
The CSS classes added to images do **not** come with any accompanying stylesheets, or inline styles. e.g the ``left`` class will do nothing, by default. The developer is expected to add these classes to their front end CSS files, to define what exactly ``left``, ``right`` or ``full-width`` means *to them*.
The CSS classes added to images do **not** come with any accompanying stylesheets, or inline styles. e.g. the ``left`` class will do nothing, by default. The developer is expected to add these classes to their front end CSS files, to define exactly what they want ``left``, ``right`` or ``full-width`` to mean.
For more information about image formats, including creating your own, see :ref:`rich_text_image_formats`

28
docs/topics/pages.rst
Wyświetl plik

@ -123,7 +123,7 @@ This should be a tuple of ``SearchField`` and ``FilterField`` objects. ``SearchF
In the above example, we've indexed ``body`` for full-text search and ``date`` for filtering.
The arguments that these field types accept are documented here: :ref:`wagtailsearch_indexing_fields`
The arguments that these field types accept are documented here: :ref:`wagtailsearch_indexing_fields`.
Editor panels
@ -141,7 +141,7 @@ Here's a summary of the ``EditHandler`` classes that Wagtail provides out of the
**Basic**
These allow editing of model fields, the ``FieldPanel`` class will choose the correct widget based on the type of the field. ``StreamField`` fields need to use a specialised panel class.
These allow editing of model fields. The ``FieldPanel`` class will choose the correct widget based on the type of the field, though ``StreamField`` fields need to use a specialised panel class.
- :class:`~wagtail.wagtailadmin.edit_handlers.FieldPanel`
- :class:`~wagtail.wagtailadmin.edit_handlers.StreamFieldPanel`
@ -156,7 +156,7 @@ These are used for structuring fields in the interface.
**Chooser**
``ForeignKey`` fields to certain models can use one of the below ``ChooserPanel`` classes. These add a nice modal-based chooser interface (and the image/document choosers also allow uploading new files without leaving the page editor).
``ForeignKey`` fields to certain models can use one of the below ``ChooserPanel`` classes. These add a nice modal chooser interface, and the image/document choosers also allow uploading new files without leaving the page editor.
- :class:`~wagtail.wagtailadmin.edit_handlers.PageChooserPanel`
- :class:`~wagtail.wagtailimages.edit_handlers.ImageChooserPanel`
@ -194,7 +194,7 @@ Setting ``parent_page_types`` to an empty list is a good way of preventing a par
Template rendering
==================
Each page model can be given a HTML template which is rendered when a user browses to a page on the site frontend. This is the simplest and most common way to get Wagtail content to end users (but not the only way).
Each page model can be given an HTML template which is rendered when a user browses to a page on the site frontend. This is the simplest and most common way to get Wagtail content to end users (but not the only way).
Adding a template for a page model
@ -212,7 +212,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, do ``{{ page.title }}``. All variables provided by `context processors <https://docs.djangoproject.com/en/1.8/ref/templates/api/#subclassing-context-requestcontext>`_ 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 <https://docs.djangoproject.com/en/1.8/ref/templates/api/#subclassing-context-requestcontext>`_ are also available.
Customising template context
@ -277,17 +277,17 @@ The template can be changed on a per-instance basis by defining a ``get_template
return 'blog/blog_page.html'
In this example, pages that have the ``use_other_template`` boolean field set will use the ``other_blog_page.html`` template. All other pages will use the default ``blog/blog_page.html``.
In this example, pages that have the ``use_other_template`` boolean field set will use the ``blog/other_blog_page.html`` template. All other pages will use the default ``blog/blog_page.html``.
More control over page rendering
--------------------------------
All page classes have a ``serve()`` method, that internally calls the ``get_context`` and ``get_template`` methods and renders the template. This method is similar to a Django view function, taking a Django ``Request`` object and returning a Django ``Response`` object.
All page classes have a ``serve()`` method that internally calls the ``get_context`` and ``get_template`` methods and renders the template. This method is similar to a Django view function, taking a Django ``Request`` object and returning a Django ``Response`` object.
This method can also be overridden for complete control over page rendering.
For example, here's a way you could make a page respond with a JSON representation of itself:
For example, here's a way to make a page respond with a JSON representation of itself:
.. code-block:: python
@ -370,7 +370,7 @@ Each page is added to both Wagtail's builtin :class:`~wagtail.wagtailcore.models
Pages can exist in Python code in two forms, an instance of ``Page`` or an instance of the page model.
When working with multiple page types together, you will typically use instances of Wagtail's :class:`~wagtail.wagtailcore.models.Page` model, which doesn't give you access to any fields specific to their type.
When working with multiple page types together, you will typically use instances of Wagtail's :class:`~wagtail.wagtailcore.models.Page` model, which don't give you access to any fields specific to their type.
.. code-block:: python
@ -379,7 +379,7 @@ Pages can exist in Python code in two forms, an instance of ``Page`` or an insta
>>> Page.objects.all()
[<Page: Homepage>, <Page: About us>, <Page: Blog>, <Page: A Blog post>, <Page: Another Blog post>]
When working with a single page type, you can work with instances of the user-defined model that gives access to all the fields available in ``Page`` and any user defined fields for that type.
When working with a single page type, you can work with instances of the user-defined model. These give access to all the fields available in ``Page``, along with any user-defined fields for that type.
.. code-block:: python
@ -387,7 +387,7 @@ When working with a single page type, you can work with instances of the user-de
>>> BlogPage.objects.all()
[<BlogPage: A Blog post>, <BlogPage: Another Blog post>]
You can convert a ``Page`` object to a specific object using the ``.specific`` property (this may cause an additional database lookup).
You can convert a ``Page`` object to its more specific user-defined equivalent using the ``.specific`` property. This may cause an additional database lookup.
.. code-block:: python
@ -417,7 +417,7 @@ You can make your model names more friendly to users of Wagtail by using Django'
class Meta:
verbose_name = "homepage"
When users are given a choice of pages to create, the list of page types is generated by splitting your model names on each of their capital letters. Thus a ``HomePage`` model would be named "Home Page" which is a little clumsy. ``verbose_name`` as in the example above, would change this to read "Homepage" which is slightly more conventional.
When users are given a choice of pages to create, the list of page types is generated by splitting your model names on each of their capital letters. Thus a ``HomePage`` model would be named "Home Page" which is a little clumsy. Defining ``verbose_name`` as in the example above would change this to read "Homepage", which is slightly more conventional.
Page QuerySet ordering
@ -434,7 +434,7 @@ Page QuerySet ordering
class Meta:
ordering = ('-publication_date', ) # will not work
This is because ``Page`` enforces ordering QuerySets by path. Instead you must apply the ordering explicitly when you construct a QuerySet:
This is because ``Page`` enforces ordering QuerySets by path. Instead, you must apply the ordering explicitly when constructing a QuerySet:
.. code-block:: python
@ -443,7 +443,7 @@ This is because ``Page`` enforces ordering QuerySets by path. Instead you must a
Custom Page managers
--------------------
You can add a custom Manager to your ``Page`` class. Any custom ``Manager``\s should inherit from :class:`wagtail.wagtailcore.models.PageManager`:
You can add a custom ``Manager`` to your ``Page`` class. Any custom Managers should inherit from :class:`wagtail.wagtailcore.models.PageManager`:
.. code-block:: python

6
docs/topics/search/backends.rst
Wyświetl plik

@ -5,7 +5,7 @@
Backends
========
Wagtailsearch has support for multiple backends giving you the choice between using the database for search or an external service such as Elasticsearch.
Wagtailsearch has support for multiple backends, giving you the choice between using the database for search or an external service such as Elasticsearch. The database backend is enabled by default.
You can configure which backend to use with the ``WAGTAILSEARCH_BACKENDS`` setting:
@ -73,7 +73,7 @@ Database Backend (default)
Before 1.1, the full path to the backend class had to be specified: ``wagtail.wagtailsearch.backends.db.DBSearch``
The database backend is very basic and is intended only to be used in development and on small sites. It cannot order results by relevance making it not very useful when searching a large amount of pages.
The database backend is very basic and is intended only to be used in development and on small sites. It cannot order results by relevance, severely hampering its usefulness when searching a large collection of pages.
It also doesn't support:
@ -99,7 +99,7 @@ Prerequisites are the `Elasticsearch`_ service itself and, via pip, the `elastic
.. note::
Wagtail doesn't support Elasticsearch 2.0 yet; please use 1.x in the meantime. Elasticsearch 2.0 support is scheduled for Wagtail 1.3.
Wagtail doesn't support Elasticsearch 2.0 yet; please use 1.x in the meantime. Elasticsearch 2.0 support is scheduled for a future release.
.. code-block:: sh

4
docs/topics/search/index.rst
Wyświetl plik

@ -18,11 +18,11 @@ Wagtail provides a comprehensive and extensible search interface. In addition, i
Indexing
========
To make objects searchable, they firstly need to be added to the search index. This involves configuring the models/fields that you would like to index (this is done for you for Pages, Images and Documents) and then actually inserting them into the index.
To make objects searchable, they must first be added to the search index. This involves configuring the models and fields that you would like to index (which is done for you for Pages, Images and Documents), and then actually inserting them into the index.
See :ref:`wagtailsearch_indexing_update` for information on how to keep the objects in your search index in sync with the objects in your database.
If you have created some extra fields in a subclass of ``Page`` or ``Image``, you may want to add these new fields to the search index too so a users search query will match on their content. See :ref:`wagtailsearch_indexing_fields`.
If you have created some extra fields in a subclass of ``Page`` or ``Image``, you may want to add these new fields to the search index, so a user's search query can match the Page or Image's extra content. See :ref:`wagtailsearch_indexing_fields`.
If you have a custom model which doesn't derive from ``Page`` or ``Image`` that you would like to make searchable, see :ref:`wagtailsearch_indexing_models`.

29
docs/topics/search/indexing.rst
Wyświetl plik

@ -5,7 +5,7 @@
Indexing
========
To make a model searchable, you'll firstly need to add it into the search index. All pages, images and documents are indexed for you and you can start searching them right away.
To make a model searchable, you'll need to add it into the search index. All pages, images and documents are indexed for you, so you can start searching them right away.
If you have created some extra fields in a subclass of Page or Image, you may want to add these new fields to the search index too so that a user's search query will match on their content. See :ref:`wagtailsearch_indexing_fields` for info on how to do this.
@ -62,12 +62,13 @@ Fields must be explicitly added to the ``search_fields`` property of your ``Page
Example
-------
This creates an ``EventPage`` model with two fields ``description`` and ``date``. ``description`` is indexed as a ``SearchField`` and ``date`` is indexed as a ``FilterField``
This creates an ``EventPage`` model with two fields: ``description`` and ``date``. ``description`` is indexed as a ``SearchField`` and ``date`` is indexed as a ``FilterField``
.. code-block:: python
from wagtail.wagtailsearch import index
from django.utils import timezone
class EventPage(Page):
description = models.TextField()
@ -86,14 +87,14 @@ This creates an ``EventPage`` model with two fields ``description`` and ``date``
``index.SearchField``
---------------------
These are added to the search index and are used for performing full-text searches on your models. These would usually be text fields.
These are used for performing full-text searches on your models, usually for text fields.
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** (``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.
- **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 cause 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.
@ -110,7 +111,7 @@ These are added to the search index but are not used for full-text searches. Ins
This allows you to index fields from related objects. It works on all types of related fields, including their reverse accessors.
For example, if we have a book that has a ``ForeignKey`` to its author, we can nest the authors ``name`` and ``date_of_birth`` fields inside the book:
For example, if we have a book that has a ``ForeignKey`` to its author, we can nest the author's ``name`` and ``date_of_birth`` fields inside the book:
.. code-block:: python
@ -127,9 +128,9 @@ For example, if we have a book that has a ``ForeignKey`` to its author, we can n
]),
]
This will allow you to search for books with their author's name.
This will allow you to search for books by their author's name.
It works the other way around as well, you can index an author's books allowing an author to be searched for with the titles of books they've published:
It works the other way around as well. You can index an author's books, allowing an author to be searched for by the titles of books they've published:
.. code-block:: python
@ -148,7 +149,7 @@ It works the other way around as well, you can index an author's books allowing
.. topic:: Filtering on ``index.RelatedFields``
It's not possible to filter on any ``index.FilterFields`` within ``index.RelatedFields`` using the ``QuerySet`` API. Although, the fields are indexed so it should be possible to use them by querying Elasticsearch manually.
It's not possible to filter on any ``index.FilterFields`` within ``index.RelatedFields`` using the ``QuerySet`` API. However, the fields are indexed, so it should be possible to use them by querying Elasticsearch manually.
Filtering on ``index.RelatedFields`` with the ``QuerySet`` API is planned for a future release of Wagtail.
@ -162,9 +163,9 @@ Indexing callables and other attributes
This is not supported in the :ref:`wagtailsearch_backends_database`
Search/filter fields do not need to be Django fields, they could be any method or attribute on your class.
Search/filter fields do not need to be Django model fields. They can also be any method or attribute on your model class.
One use for this is indexing ``get_*_display`` methods Django creates automatically for fields with choices.
One use for this is indexing the ``get_*_display`` methods Django creates automatically for fields with choices.
.. code-block:: python
@ -180,10 +181,10 @@ One use for this is indexing ``get_*_display`` methods Django creates automatica
is_private = models.BooleanField(choices=IS_PRIVATE_CHOICES)
search_fields = Page.search_fields + (
# Index the human-readable string for searching
# Index the human-readable string for searching.
index.SearchField('get_is_private_display'),
# Index the boolean value for filtering
# Index the boolean value for filtering.
index.FilterField('is_private'),
)
@ -195,7 +196,7 @@ Callables also provide a way to index fields from related models. In the example
# ...
def get_related_link_titles(self):
# Get list of titles and concatenate them
return '\n'.join(self.related_links.all().values_list('title', flat=True))
return '\n'.join(self.related_links.all().values_list('name', flat=True))
search_fields = Page.search_fields + [
# ...

4
docs/topics/search/searching.rst
Wyświetl plik

@ -87,7 +87,7 @@ Specifying the fields to search
By default, Wagtail will search all fields that have been indexed using ``index.SearchField``.
This can be limited to a certian set of fields using the ``fields`` keyword argument:
This can be limited to a certian set of fields by using the ``fields`` keyword argument:
.. code-block:: python
@ -113,7 +113,7 @@ Both operators have benefits and drawbacks. The "or" operator will return many m
We recommend using the "or" operator when ordering by relevance and the "and" operator when ordering by anything else (note: the database backend doesn't currently support ordering by relevance).
Here's an example of using the "operator" keyword argument:
Here's an example of using the ``operator`` keyword argument:
.. code-block:: python

22
docs/topics/snippets.rst
Wyświetl plik

@ -4,9 +4,9 @@
Snippets
========
Snippets are pieces of content which do not necessitate a full webpage to render. They could be used for making secondary content, such as headers, footers, and sidebars, editable in the Wagtail admin. Snippets are models which do not inherit the ``Page`` class and are thus not organized into the Wagtail tree, but can still be made editable by assigning panels and identifying the model as a snippet with the ``register_snippet`` class decorator.
Snippets are pieces of content which do not necessitate a full webpage to render. They could be used for making secondary content, such as headers, footers, and sidebars, editable in the Wagtail admin. Snippets are Django models which do not inherit the ``Page`` class and are thus not organized into the Wagtail tree. However, they can still be made editable by assigning panels and identifying the model as a snippet with the ``register_snippet`` class decorator.
Snippets lack many of the features of pages, such as being orderable in the Wagtail admin or having a defined URL, so decide carefully if the content type you would want to build into a snippet might be more suited to a page.
Snippets lack many of the features of pages, such as being orderable in the Wagtail admin or having a defined URL. Decide carefully if the content type you would want to build into a snippet might be more suited to a page.
Snippet Models
--------------
@ -35,16 +35,16 @@ Here's an example snippet from the Wagtail demo website:
def __str__(self): # __unicode__ on Python 2
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 __str__(self):`` so that the snippet objects make sense when listed in the Wagtail admin.
Including Snippets in Template Tags
-----------------------------------
The simplest way to make your snippets available to templates is with a template tag. This is mostly done with vanilla Django, so perhaps reviewing Django's documentation for `django custom template tags`_ will be more helpful. We'll go over the basics, though, and make note of any considerations to make for Wagtail.
The simplest way to make your snippets available to templates is with a template tag. This is mostly done with vanilla Django, so perhaps reviewing Django's documentation for `django custom template tags`_ will be more helpful. We'll go over the basics, though, and point out any considerations to make for Wagtail.
First, add a new python file to a ``templatetags`` folder within your app. The demo website, for instance uses the path ``wagtaildemo/demo/templatetags/demo_tags.py``. We'll need to load some Django modules and our app's models and ready the ``register`` decorator:
First, add a new python file to a ``templatetags`` folder within your app. The demo website, for instance uses the path ``wagtaildemo/demo/templatetags/demo_tags.py``. We'll need to load some Django modules and our app's models, and ready the ``register`` decorator:
.. _django custom template tags: https://docs.djangoproject.com/en/dev/howto/custom-template-tags/
@ -67,7 +67,7 @@ First, add a new python file to a ``templatetags`` folder within your app. The d
``@register.inclusion_tag()`` takes two variables: a template and a boolean on whether that template should be passed a request context. It's a good idea to include request contexts in your custom template tags, since some Wagtail-specific template tags like ``pageurl`` need the context to work properly. The template tag function could take arguments and filter the adverts to return a specific model, but for brevity we'll just use ``Advert.objects.all()``.
Here's what's in the template used by the template tag:
Here's what's in the template used by this template tag:
.. code-block:: html+django
@ -79,7 +79,7 @@ Here's what's in the template used by the template tag:
</p>
{% endfor %}
Then in your own page templates, you can include your snippet template tag with:
Then, in your own page templates, you can include your snippet template tag with:
.. code-block:: html+django
@ -99,7 +99,7 @@ Then in your own page templates, you can include your snippet template tag with:
Binding Pages to Snippets
-------------------------
In the above example, the list of adverts is a fixed list, displayed as part of the template independently of the page content. This might be what you want for a common panel in a sidebar, say - but in other scenarios you may wish to refer to a snippet within page content. This can be done by defining a foreign key to the snippet model within your page model, and adding a ``SnippetChooserPanel`` to the page's ``content_panels`` definitions. For example, if you wanted to be able to specify an advert to appear on ``BookPage``:
In the above example, the list of adverts is a fixed list, displayed independently of the page content. This might be what you want for a common panel in a sidebar, say -- but in other scenarios you may wish to refer to a particular snippet from within a page's content. This can be done by defining a foreign key to the snippet model within your page model, and adding a ``SnippetChooserPanel`` to the page's ``content_panels`` list. For example, if you wanted to be able to specify an advert to appear on ``BookPage``:
.. code-block:: python
@ -167,7 +167,11 @@ These child objects are now accessible through the page's ``advert_placements``
.. code-block:: html+django
{% for advert_placement in page.advert_placements.all %}
<p><a href="{{ advert_placement.advert.url }}">{{ advert_placement.advert.text }}</a></p>
<p>
<a href="{{ advert_placement.advert.url }}">
{{ advert_placement.advert.text }}
</a>
</p>
{% endfor %}

82
docs/topics/streamfield.rst
Wyświetl plik

@ -3,7 +3,7 @@
Freeform page content using StreamField
=======================================
StreamField provides a content editing model suitable for pages that do not follow a fixed structure - such as blog posts or news stories, where the text may be interspersed with subheadings, images, pull quotes and video, and perhaps more specialised content types such as maps and charts (or, for a programming blog, code snippets). In this model, these different content types are represented as a sequence of 'blocks', which can be repeated and arranged in any order.
StreamField provides a content editing model suitable for pages that do not follow a fixed structure -- such as blog posts or news stories -- where the text may be interspersed with subheadings, images, pull quotes and video. It's also suitable for more specialised content types, such as maps and charts (or, for a programming blog, code snippets). In this model, these different content types are represented as a sequence of 'blocks', which can be repeated and arranged in any order.
For further background on StreamField, and why you would use it instead of a rich text field for the article body, see the blog post `Rich text fields and faster horses <https://torchbox.com/blog/rich-text-fields-and-faster-horses/>`__.
@ -41,9 +41,9 @@ Using StreamField
]
Note: StreamField is not backwards compatible with other field types such as RichTextField; if you migrate an existing field to StreamField, the existing data will be lost.
Note: StreamField is not backwards compatible with other field types such as RichTextField. If you need to migrate an existing field to StreamField, refer to :ref:`streamfield_migrating_richtext`.
The parameter to ``StreamField`` is a list of (name, block_type) tuples; 'name' is used to identify the block type within templates and the internal JSON representation (and should follow standard Python conventions for variable names: lower-case and underscores, no spaces) and 'block_type' should be a block definition object as described below. (Alternatively, ``StreamField`` can be passed a single ``StreamBlock`` instance - see `Structural block types`_.)
The parameter to ``StreamField`` is a list of ``(name, block_type)`` tuples. 'name' is used to identify the block type within templates and the internal JSON representation (and should follow standard Python conventions for variable names: lower-case and underscores, no spaces) and 'block_type' should be a block definition object as described below. (Alternatively, ``StreamField`` can be passed a single ``StreamBlock`` instance - see `Structural block types`_.)
This defines the set of available block types that can be used within this field. The author of the page is free to use these blocks as many times as desired, in any order.
@ -101,7 +101,7 @@ BooleanBlock
``wagtail.wagtailcore.blocks.BooleanBlock``
A checkbox. The keyword arguments ``required`` and ``help_text`` are accepted. As with Django's ``BooleanField``, a value of ``required=True`` (the default) indicates that the checkbox must be ticked in order to proceed; for a checkbox that can be ticked or unticked, you must explicitly pass in ``required=False``.
A checkbox. The keyword arguments ``required`` and ``help_text`` are accepted. As with Django's ``BooleanField``, a value of ``required=True`` (the default) indicates that the checkbox must be ticked in order to proceed. For a checkbox that can be ticked or unticked, you must explicitly pass in ``required=False``.
DateBlock
~~~~~~~~~
@ -194,7 +194,7 @@ A control for selecting a page object, using Wagtail's page browser. The followi
If true, the field cannot be left blank.
``can_choose_root`` (default: False)
If true, the editor can choose the tree root as a page. Normally this would be undesirable, since the tree root is never a usable page, but in some specialised cases it may be appropriate; for example, a block providing a feed of related articles could use a PageChooserBlock to select which subsection articles will be taken from, with the root corresponding to 'everywhere'.
If true, the editor can choose the tree root as a page. Normally this would be undesirable, since the tree root is never a usable page, but in some specialised cases it may be appropriate. For example, a block providing a feed of related articles could use a PageChooserBlock to select which subsection of the site articles will be taken from, with the root corresponding to 'everywhere'.
DocumentChooserBlock
~~~~~~~~~~~~~~~~~~~~
@ -235,7 +235,7 @@ StructBlock
``wagtail.wagtailcore.blocks.StructBlock``
A block consisting of a fixed group of sub-blocks to be displayed together. Takes a list of (name, block_definition) tuples as its first argument:
A block consisting of a fixed group of sub-blocks to be displayed together. Takes a list of ``(name, block_definition)`` tuples as its first argument:
.. code-block:: python
@ -261,7 +261,7 @@ Alternatively, the list of sub-blocks can be provided in a subclass of StructBlo
icon = 'user'
The ``Meta`` class supports the properties ``default``, ``label``, ``icon`` and ``template``; these have the same meanings as when they are passed to the block's constructor.
The ``Meta`` class supports the properties ``default``, ``label``, ``icon`` and ``template``, which have the same meanings as when they are passed to the block's constructor.
This defines ``PersonBlock()`` as a block type that can be re-used as many times as you like within your model definitions:
@ -320,7 +320,7 @@ StreamBlock
``wagtail.wagtailcore.blocks.StreamBlock``
A block consisting of a sequence of sub-blocks of different types, which can be mixed and reordered in any order. Used as the overall mechanism of the StreamField itself, but can also be nested or used within other structural block types. Takes a list of (name, block_definition) tuples as its first argument:
A block consisting of a sequence of sub-blocks of different types, which can be mixed and reordered at will. Used as the overall mechanism of the StreamField itself, but can also be nested or used within other structural block types. Takes a list of ``(name, block_definition)`` tuples as its first argument:
.. code-block:: python
@ -353,7 +353,7 @@ As with StructBlock, the list of sub-blocks can also be provided as a subclass o
icon='cogs'
Since ``StreamField`` accepts an instance of ``StreamBlock`` as a parameter, in place of a list of block types, this makes it possible to re-use a common set block types without repeating definitions:
Since ``StreamField`` accepts an instance of ``StreamBlock`` as a parameter, in place of a list of block types, this makes it possible to re-use a common set of block types without repeating definitions:
.. code-block:: python
@ -376,9 +376,9 @@ This will render each block of the stream in turn, wrapped in a ``<div class="bl
.. code-block:: html+django
<article>
{% for block in page.body %}
<section>{{ block }}</section>
{% endfor %}
{% for block in page.body %}
<section>{{ block }}</section>
{% endfor %}
</article>
@ -387,19 +387,19 @@ For more control over the rendering of specific block types, each block object p
.. code-block:: html+django
<article>
{% for block in page.body %}
{% if block.block_type == 'heading' %}
<h1>{{ block.value }}</h1>
{% else %}
<section class="block-{{ block.block_type }}">
{{ block }}
</section>
{% endif %}
{% endfor %}
{% for block in page.body %}
{% if block.block_type == 'heading' %}
<h1>{{ block.value }}</h1>
{% else %}
<section class="block-{{ block.block_type }}">
{{ block }}
</section>
{% endif %}
{% endfor %}
</article>
Each block type provides its own front-end HTML rendering mechanism, and this is used for the output of ``{{ block }}``. For most simple block types, such as CharBlock, this will simply output the field's value, but others will provide their own HTML markup; for example, a ListBlock will output the list of child blocks as a ``<ul>`` element (with each child wrapped in an ``<li>`` element and rendered using the child block's own HTML rendering).
Each block type provides its own front-end HTML rendering mechanism, and this is used for the output of ``{{ block }}``. For most simple block types, such as CharBlock, this will simply output the field's value, but others will provide their own HTML markup. For example, a ListBlock will output the list of child blocks as a ``<ul>`` element (with each child wrapped in an ``<li>`` element and rendered using the child block's own HTML rendering).
To override this with your own custom HTML rendering, you can pass a ``template`` argument to the block, giving the filename of a template file to be rendered. This is particularly useful for custom block types derived from StructBlock, as the default StructBlock rendering is simple and somewhat generic:
@ -439,9 +439,9 @@ Within the template, the block value is accessible as the variable ``value``:
{% load wagtailimages_tags %}
<div class="person">
{% image value.photo width-400 %}
<h2>{{ value.first_name }} {{ value.surname }}</h2>
{{ value.biography }}
{% image value.photo width-400 %}
<h2>{{ value.first_name }} {{ value.surname }}</h2>
{{ value.biography }}
</div>
@ -472,7 +472,7 @@ In this example, the variable ``is_happening_today`` will be made available with
BoundBlocks and values
----------------------
As you've seen above, it's possible to assign a particular template rendering to a block. This can be done on any block type, not just StructBlocks - however, there are some extra details to be aware of. Consider the following block definition:
As you've seen above, it's possible to assign a particular template for rendering a block. This can be done on any block type (not just StructBlocks), but there are some extra details to be aware of. Consider the following block definition:
.. code-block:: python
@ -480,7 +480,7 @@ As you've seen above, it's possible to assign a particular template rendering to
class Meta:
template = 'blocks/heading.html'
where blocks/heading.html consists of:
where ``blocks/heading.html`` consists of:
.. code-block:: html+django
@ -493,16 +493,16 @@ This gives us a block that behaves as an ordinary text field, but wraps its outp
class BlogPage(Page):
body = StreamField([
# ...
'heading': HeadingBlock(),
('heading', HeadingBlock()),
# ...
])
.. code-block:: html+django
{% for block in page.body %}
{% if block.block_type == 'heading' %}
{{ block }} {# this block will output its own <h1>...</h1> tags #}
{% endif %}
{% if block.block_type == 'heading' %}
{{ block }} {# This block will output its own <h1>...</h1> tags. #}
{% endif %}
{% endfor %}
This is a powerful feature, but it involves some complexity behind the scenes to make it work. Effectively, HeadingBlock has a double identity - logically it represents a plain Python string value, but in circumstances such as this it needs to yield a 'magic' object that knows its own custom HTML representation. This 'magic' object is an instance of ``BoundBlock`` - an object that represents the pairing of a value and its block definition. (Django developers may recognise this as the same principle behind ``BoundField`` in Django's forms framework.)
@ -519,16 +519,16 @@ Most of the time, you won't need to worry about whether you're dealing with a pl
class Meta:
template = 'blocks/event.html'
where blocks/event.html is:
where ``blocks/event.html`` is:
.. code-block:: html+django
<div class="event {% if value.heading == 'Party!' %}lots-of-balloons{% endif %}">
{{ value.heading }}
- {{ value.description }}
{{ value.heading }}
- {{ value.description }}
</div>
In this case, ``value.heading`` returns the plain string value; if this weren't the case, the comparison in ``{% if value.heading == 'Party!' %}`` would never succeed. This in turn means that ``{{ value.heading }}`` renders as the plain string, without the ``<h1>`` tags.
In this case, ``value.heading`` returns the plain string value, because if this weren't the case, the comparison in ``{% if value.heading == 'Party!' %}`` would never succeed. This in turn means that ``{{ value.heading }}`` renders as the plain string, without the ``<h1>`` tags.
Interactions between BoundBlocks and plain values work according to the following rules:
@ -590,7 +590,7 @@ This is possible because the HTML rendering behaviour of these blocks does not i
('photo', ImageChooserBlock()),
], template='blocks/speaker.html')
then writing ``{{ value.guest_speaker }}`` within the EventBlock's template will use the template rendering from blocks/speaker.html for that field.
then writing ``{{ value.guest_speaker }}`` within the EventBlock's template will use the template rendering from ``blocks/speaker.html`` for that field.
Custom block types
@ -614,16 +614,18 @@ Migrations
StreamField definitions within migrations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
As with any model field in Django, any changes to a model definition that affect a StreamField will result in a migration file that contains a 'frozen' copy of that field definition. Since a StreamField definition is more complex than a typical model field, there is an increased likelihood of definitions from your project being imported into the migration - which would cause problems later on if those definitions are moved or deleted.
As with any model field in Django, any changes to a model definition that affect a StreamField will result in a migration file that contains a 'frozen' copy of that field definition. Since a StreamField definition is more complex than a typical model field, there is an increased likelihood of definitions from your project being imported into the migration -- which would cause problems later on if those definitions are moved or deleted.
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.
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 <https://docs.djangoproject.com/en/1.9/topics/migrations/#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 <https://docs.djangoproject.com/en/1.9/topics/migrations/#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:
Migrating RichTextFields to StreamField
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If you change an existing RichTextField to a StreamField, and create and run migrations as normal, the migration will complete with no errors, since both fields use a text column within the database. However, StreamField uses a JSON representation for its data, and so the existing text needs to be converted with a data migration in order to become accessible again. For this to work, the StreamField needs to include a RichTextBlock as one of the available block types. The field can then be converted by creating a new migration (``./manage.py makemigrations --empty myapp``) and editing it as follows (in this example, the 'body' field of the ``demo.BlogPage`` model is being converted to a StreamField with a RichTextBlock named ``rich_text``):
If you change an existing RichTextField to a StreamField, and create and run migrations as normal, the migration will complete with no errors, since both fields use a text column within the database. However, StreamField uses a JSON representation for its data, so the existing text needs to be converted with a data migration in order to become accessible again. For this to work, the StreamField needs to include a RichTextBlock as one of the available block types. The field can then be converted by creating a new migration (``./manage.py makemigrations --empty myapp``) and editing it as follows (in this example, the 'body' field of the ``demo.BlogPage`` model is being converted to a StreamField with a RichTextBlock named ``rich_text``):
.. code-block:: python

41
docs/topics/writing_templates.rst
Wyświetl plik

@ -19,7 +19,7 @@ Every type of page or "content type" in Wagtail is defined as a "model" in a fil
For each page model in ``models.py``, Wagtail assumes an HTML template file exists of (almost) the same name. The Front End developer may need to create these templates themselves by refering to ``models.py`` to infer template names from the models defined therein.
To find a suitable template, Wagtail converts CamelCase names to underscore_case. So for a ``BlogPage``, a template ``blog_page.html`` will be expected. The name of the template file can be overridden per model if necessary.
To find a suitable template, Wagtail converts CamelCase names to snake_case. So for a ``BlogPage``, a template ``blog_page.html`` will be expected. The name of the template file can be overridden per model if necessary.
Template files are assumed to exist here::
@ -64,9 +64,9 @@ Any file within the static folder should be inserted into your HTML using the ``
User images
~~~~~~~~~~~
Images uploaded to Wagtail by its users (as opposed to a developer's static files, above) go into the image library and from there are added to pages via the :doc:`page editor interface </editor_manual/new_pages/inserting_images>`.
Images uploaded to a Wagtail site by its users (as opposed to a developer's static files, mentioned above) go into the image library and from there are added to pages via the :doc:`page editor interface </editor_manual/new_pages/inserting_images>`.
Unlike other CMS, adding images to a page does not involve choosing a "version" of the image to use. Wagtail has no predefined image "formats" or "sizes". Instead the template developer defines image manipulation to occur *on the fly* when the image is requested, via a special syntax within the template.
Unlike other CMSs, adding images to a page does not involve choosing a "version" of the image to use. Wagtail has no predefined image "formats" or "sizes". Instead the template developer defines image manipulation to occur *on the fly* when the image is requested, via a special syntax within the template.
Images from the library must be requested using this syntax, but a developer's static images can be added via conventional means e.g ``img`` tags. Only images from the library can be manipulated on the fly.
@ -77,7 +77,7 @@ Read more about the image manipulation syntax here :ref:`image_tag`.
Template tags & filters
=======================
In addition to Django's standard tags and filters, Wagtail provides some of its own, which can be ``load``-ed `as you would any other <https://docs.djangoproject.com/en/dev/topics/templates/#custom-tag-and-filter-libraries>`_
In addition to Django's standard tags and filters, Wagtail provides some of its own, which can be ``load``-ed `just like any other <https://docs.djangoproject.com/en/dev/topics/templates/#custom-tag-and-filter-libraries>`_.
Images (tag)
@ -85,7 +85,7 @@ Images (tag)
The ``image`` tag inserts an XHTML-compatible ``img`` element into the page, setting its ``src``, ``width``, ``height`` and ``alt``. See also :ref:`image_tag_alt`.
The syntax for the tag is thus::
The syntax for the ``image`` tag is thus::
{% image [image] [resize-rule] %}
@ -110,7 +110,7 @@ See :ref:`image_tag` for full documentation.
Rich text (filter)
~~~~~~~~~~~~~~~~~~
This filter takes a chunk of HTML content and renders it as safe HTML in the page. Importantly it also expands internal shorthand references to embedded images and links made in the Wagtail editor into fully-baked HTML ready for display.
This filter takes a chunk of HTML content and renders it as safe HTML in the page. Importantly, it also expands internal shorthand references to embedded images, and links made in the Wagtail editor, into fully-baked HTML ready for display.
Only fields using ``RichTextField`` need this applied in the template.
@ -123,7 +123,7 @@ Only fields using ``RichTextField`` need this applied in the template.
Responsive Embeds
-----------------
Wagtail embeds and images are included at their full width, which may overflow the bounds of the content container you've defined in your templates. To make images and embeds responsive -- meaning they'll resize to fit their container -- include the following CSS.
Wagtail includes embeds and images at their full width, which may overflow the bounds of the content container you've defined in your templates. To make images and embeds responsive -- meaning they'll resize to fit their container -- include the following CSS.
.. code-block:: css
@ -135,15 +135,16 @@ Wagtail embeds and images are included at their full width, which may overflow t
.responsive-object {
position: relative;
}
.responsive-object iframe,
.responsive-object object,
.responsive-object embed {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
}
.responsive-object iframe,
.responsive-object object,
.responsive-object embed {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
}
Internal links (tag)
@ -154,7 +155,7 @@ Internal links (tag)
``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.
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.
.. code-block:: html+django
@ -167,7 +168,7 @@ Takes a Page object and returns a relative URL (``/foo/bar/``) if within the sam
``slugurl``
------------
Takes any ``slug`` as defined in a page's "Promote" tab and returns the URL for the matching Page. Like ``pageurl``, will try to provide a relative link if possible, but will default to an absolute link if on a different site. This is most useful when creating shared page furniture e.g top level navigation or site-wide links.
Takes any ``slug`` as defined in a page's "Promote" tab and returns the URL for the matching Page. Like ``pageurl``, this will try to provide a relative link if possible, but will default to an absolute link if the Page is on a different Site. This is most useful when creating shared page furniture, e.g. top level navigation or site-wide links.
.. code-block:: html+django
@ -181,7 +182,7 @@ Takes any ``slug`` as defined in a page's "Promote" tab and returns the URL for
Static files (tag)
~~~~~~~~~~~~~~~~~~
Used to load anything from your static files directory. Use of this tag avoids rewriting all static paths if hosting arrangements change, as they might between local and a live environments.
Used to load anything from your static files directory. Use of this tag avoids rewriting all static paths if hosting arrangements change, as they might between development and live environments.
.. code-block:: html+django
@ -197,7 +198,7 @@ Notice that the full path name is not required and the path snippet you enter on
Wagtail User Bar
================
This tag provides a contextual flyout menu on the top-right of a page for logged-in users. The menu gives editors the ability to edit the current page or add another at the same level. Moderators are also given the ability to accept or reject a page previewed as part of content moderation.
This tag provides a contextual flyout menu on the top-right of a page for logged-in users. The menu gives editors the ability to edit the current page or add another at the same level. Moderators are also given the ability to accept or reject a page being previewed as part of content moderation.
.. code-block:: html+django