page_editing_interface.rst 14 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296
  1. Customising the editing interface
  2. =================================
  3. .. _customising_the_tabbed_interface:
  4. Customising the tabbed interface
  5. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  6. As standard, Wagtail organises panels for pages into three tabs: 'Content', 'Promote' and 'Settings'. For snippets Wagtail puts all panels into one page. Depending on the requirements of your site, you may wish to customise this for specific page types or snippets - for example, adding an additional tab for sidebar content. This can be done by specifying an ``edit_handler`` attribute on the page or snippet model. For example:
  7. .. code-block:: python
  8. from wagtail.admin.edit_handlers import TabbedInterface, ObjectList
  9. class BlogPage(Page):
  10. # field definitions omitted
  11. content_panels = [
  12. FieldPanel('title', classname="full title"),
  13. FieldPanel('date'),
  14. FieldPanel('body', classname="full"),
  15. ]
  16. sidebar_content_panels = [
  17. SnippetChooserPanel('advert'),
  18. InlinePanel('related_links', label="Related links"),
  19. ]
  20. edit_handler = TabbedInterface([
  21. ObjectList(content_panels, heading='Content'),
  22. ObjectList(sidebar_content_panels, heading='Sidebar content'),
  23. ObjectList(Page.promote_panels, heading='Promote'),
  24. ObjectList(Page.settings_panels, heading='Settings', classname="settings"),
  25. ])
  26. .. _rich-text:
  27. Rich Text (HTML)
  28. ~~~~~~~~~~~~~~~~
  29. Wagtail provides a general-purpose WYSIWYG editor for creating rich text content (HTML) and embedding media such as images, video, and documents. To include this in your models, use the :class:`~wagtail.core.fields.RichTextField` function when defining a model field:
  30. .. code-block:: python
  31. from wagtail.core.fields import RichTextField
  32. from wagtail.admin.edit_handlers import FieldPanel
  33. class BookPage(Page):
  34. book_text = RichTextField()
  35. content_panels = Page.content_panels + [
  36. FieldPanel('body', classname="full"),
  37. ]
  38. :class:`~wagtail.core.fields.RichTextField` inherits from Django's basic ``TextField`` field, so you can pass any field parameters into :class:`~wagtail.core.fields.RichTextField` as if using a normal Django field. This field does not need a special panel and can be defined with ``FieldPanel``.
  39. However, template output from :class:`~wagtail.core.fields.RichTextField` is special and need to be filtered to preserve embedded content. See :ref:`rich-text-filter`.
  40. .. _rich_text_features:
  41. Limiting features in a rich text field
  42. --------------------------------------
  43. By default, the rich text editor provides users with a wide variety of options for text formatting and inserting embedded content such as images. However, we may wish to restrict a rich text field to a more limited set of features - for example:
  44. * The field might be intended for a short text snippet, such as a summary to be pulled out on index pages, where embedded images or videos would be inappropriate;
  45. * When page content is defined using :ref:`StreamField <streamfield>`, elements such as headings, images and videos are usually given their own block types, alongside a rich text block type used for ordinary paragraph text; in this case, allowing headings and images to also exist within the rich text content is redundant (and liable to result in inconsistent designs).
  46. This can be achieved by passing a ``features`` keyword argument to ``RichTextField``, with a list of identifiers for the features you wish to allow:
  47. .. code-block:: python
  48. body = RichTextField(features=['h2', 'h3', 'bold', 'italic', 'link'])
  49. The feature identifiers provided on a default Wagtail installation are as follows:
  50. * ``h1``, ``h2``, ``h3``, ``h4``, ``h5``, ``h6`` - heading elements
  51. * ``bold``, ``italic`` - bold / italic text
  52. * ``ol``, ``ul`` - ordered / unordered lists
  53. * ``hr`` - horizontal rules
  54. * ``link`` - page, external and email links
  55. * ``document-link`` - links to documents
  56. * ``image`` - embedded images
  57. * ``embed`` - embedded media (see :ref:`embedded_content`)
  58. Adding new features to this list is generally a two step process:
  59. * Create a plugin that extends the editor with a new toolbar button for adding a particular HTML element
  60. * Add that HTML element to the whitelist of elements that are permitted in rich text output
  61. Both of these steps are performed through the ``register_rich_text_features`` hook (see :ref:`admin_hooks`). The hook function is triggered on startup, and receives a *feature registry* object as its argument; this object keeps track of the behaviours associated with each feature identifier.
  62. This process for adding new features is described in the following sections.
  63. .. _extending_wysiwyg:
  64. Extending the WYSIWYG Editor (``hallo.js``)
  65. +++++++++++++++++++++++++++++++++++++++++++
  66. .. note::
  67. The customisations described here are only available on the hallo.js rich text editor used on Wagtail 1.x. To use hallo.js on Wagtail 2.x, add the following to your settings:
  68. .. code-block:: python
  69. WAGTAILADMIN_RICH_TEXT_EDITORS = {
  70. 'default': {
  71. 'WIDGET': 'wagtail.admin.rich_text.HalloRichTextArea'
  72. }
  73. }
  74. Wagtail's rich text editor is built on ``hallo.js``, and its functionality can be extended through plugins. For information on developing custom ``hallo.js`` plugins, see the project's page: https://github.com/bergie/hallo
  75. Once the plugin has been created, it should be registered through the feature registry's ``register_editor_plugin(editor, feature_name, plugin)`` method. For a ``hallo.js`` plugin, the ``editor`` parameter should always be ``'hallo'``.
  76. A plugin ``halloblockquote``, implemented in ``myapp/js/hallo-blockquote.js``, that adds support for the ``<blockquote>`` tag, would be registered under the feature name ``block-quote`` as follows:
  77. .. code-block:: python
  78. from wagtail.admin.rich_text import HalloPlugin
  79. from wagtail.core import hooks
  80. @hooks.register('register_rich_text_features')
  81. def register_embed_feature(features):
  82. features.register_editor_plugin(
  83. 'hallo', 'block-quote',
  84. HalloPlugin(
  85. name='halloblockquote',
  86. js=['myapp/js/hallo-blockquote.js'],
  87. )
  88. )
  89. The constructor for ``HalloPlugin`` accepts the following keyword arguments:
  90. * ``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.
  91. * ``options`` - a dictionary (or other JSON-serialisable object) of options to be passed to the Javascript plugin code on initialisation
  92. * ``js`` - a list of Javascript files to be imported for this plugin, defined in the same way as a `Django form media <https://docs.djangoproject.com/en/1.11/topics/forms/media/>`_ definition
  93. * ``css`` - a dictionary of CSS files to be imported for this plugin, defined in the same way as a `Django form media <https://docs.djangoproject.com/en/1.11/topics/forms/media/>`_ definition
  94. * ``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
  95. To have a feature active by default (i.e. on ``RichTextFields`` that do not define an explicit ``features`` list), add it to the ``default_features`` list on the ``features`` object:
  96. .. code-block:: python
  97. from django.utils.html import format_html
  98. @hooks.register('register_rich_text_features')
  99. def register_blockquote_feature(features):
  100. features.register_editor_plugin(
  101. 'hallo', 'block-quote',
  102. # ...
  103. )
  104. features.default_features.append('block-quote')
  105. .. _whitelisting_rich_text_elements:
  106. Whitelisting rich text elements
  107. +++++++++++++++++++++++++++++++
  108. After extending the editor to support a new HTML element, you'll need to add it to the whitelist of permitted elements - Wagtail's standard behaviour is to strip out unrecognised elements, to prevent editors from inserting styles and scripts (either deliberately, or inadvertently through copy-and-paste) that the developer didn't account for.
  109. Elements can be added to the whitelist through the feature registry's ``register_converter_rule(converter, feature_name, ruleset)`` method. When the ``hallo.js`` editor is in use, the ``converter`` parameter should always be ``'editorhtml'``.
  110. The following code will add the ``<blockquote>`` element to the whitelist whenever the ``block-quote`` feature is active:
  111. .. code-block:: python
  112. from wagtail.admin.rich_text.converters.editor_html import WhitelistRule
  113. from wagtail.core.whitelist import allow_without_attributes
  114. @hooks.register('register_rich_text_features')
  115. def register_blockquote_feature(features):
  116. features.register_converter_rule('editorhtml', 'block-quote', [
  117. WhitelistRule('blockquote', allow_without_attributes),
  118. ])
  119. ``WhitelistRule`` is passed the element name, and a callable which will perform some kind of manipulation of the element whenever it is encountered. This callable receives the element as a `BeautifulSoup <http://www.crummy.com/software/BeautifulSoup/bs4/doc/>`_ Tag object.
  120. The ``wagtail.core.whitelist`` module provides a few helper functions to assist in defining these handlers: ``allow_without_attributes``, a handler which preserves the element but strips out all of its attributes, and ``attribute_rule`` which accepts a dict specifying how to handle each attribute, and returns a handler function. This dict will map attribute names to either True (indicating that the attribute should be kept), False (indicating that it should be dropped), or a callable (which takes the initial attribute value and returns either a final value for the attribute, or None to drop the attribute).
  121. .. _rich_text_image_formats:
  122. Image Formats in the Rich Text Editor
  123. -------------------------------------
  124. On loading, Wagtail will search for any app with the file ``image_formats.py`` and execute the contents. This provides a way to customise the formatting options shown to the editor when inserting images in the :class:`~wagtail.core.fields.RichTextField` editor.
  125. As an example, add a "thumbnail" format:
  126. .. code-block:: python
  127. # image_formats.py
  128. from wagtail.images.formats import Format, register_image_format
  129. register_image_format(Format('thumbnail', 'Thumbnail', 'richtext-image thumbnail', 'max-120x120'))
  130. 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:
  131. ``name``
  132. The unique key used to identify the format. To unregister this format, call ``unregister_image_format`` with this string as the only argument.
  133. ``label``
  134. The label used in the chooser form when inserting the image into the :class:`~wagtail.core.fields.RichTextField`.
  135. ``classnames``
  136. The string to assign to the ``class`` attribute of the generated ``<img>`` tag.
  137. .. note::
  138. Any class names you provide must have CSS rules matching them written separately, as part of the front end CSS code. Specifying a ``classnames`` value of ``left`` will only ensure that class is output in the generated markup, it won't cause the image to align itself left.
  139. ``filter_spec``
  140. The string specification to create the image rendition. For more, see the :ref:`image_tag`.
  141. To unregister, call ``unregister_image_format`` with the string of the ``name`` of the ``Format`` as the only argument.
  142. .. _custom_edit_handler_forms:
  143. Customising generated forms
  144. ~~~~~~~~~~~~~~~~~~~~~~~~~~~
  145. .. class:: wagtail.admin.forms.WagtailAdminModelForm
  146. .. class:: wagtail.admin.forms.WagtailAdminPageForm
  147. Wagtail automatically generates forms using the panels configured on the model.
  148. By default, this form subclasses :class:`~wagtail.admin.forms.WagtailAdminModelForm`,
  149. or :class:`~wagtail.admin.forms.WagtailAdminPageForm` for pages.
  150. A custom base form class can be configured by setting the :attr:`base_form_class` attribute on any model.
  151. Custom forms for snippets must subclass :class:`~wagtail.admin.forms.WagtailAdminModelForm`,
  152. and custom forms for pages must subclass :class:`~wagtail.admin.forms.WagtailAdminPageForm`.
  153. This can be used to add non-model fields to the form, to automatically generate field content,
  154. or to add custom validation logic for your models:
  155. .. code-block:: python
  156. from django import forms
  157. import geocoder # not in Wagtail, for example only - http://geocoder.readthedocs.io/
  158. from wagtail.admin.edit_handlers import FieldPanel
  159. from wagtail.admin.forms import WagtailAdminPageForm
  160. from wagtail.core.models import Page
  161. class EventPageForm(WagtailAdminPageForm):
  162. address = forms.CharField()
  163. def clean(self):
  164. cleaned_data = super(EventPageForm, self).clean()
  165. # Make sure that the event starts before it ends
  166. start_date = cleaned_data['start_date']
  167. end_date = cleaned_data['end_date']
  168. if start_date and end_date and start_date > end_date:
  169. self.add_error('end_date', 'The end date must be after the start date')
  170. return cleaned_data
  171. def save(self, commit=True):
  172. page = super(EventPageForm, self).save(commit=False)
  173. # Update the duration field from the submitted dates
  174. page.duration = (page.end_date - page.start_date).days
  175. # Fetch the location by geocoding the address
  176. page.location = geocoder.arcgis(self.cleaned_data['address'])
  177. if commit:
  178. page.save()
  179. return page
  180. class EventPage(Page):
  181. start_date = models.DateField()
  182. end_date = models.DateField()
  183. duration = models.IntegerField()
  184. location = models.CharField(max_length=255)
  185. content_panels = [
  186. FieldPanel('title'),
  187. FieldPanel('start_date'),
  188. FieldPanel('end_date'),
  189. FieldPanel('address'),
  190. ]
  191. base_form_class = EventPageForm
  192. Wagtail will generate a new subclass of this form for the model,
  193. adding any fields defined in ``panels`` or ``content_panels``.
  194. Any fields already defined on the model will not be overridden by these automatically added fields,
  195. so the form field for a model field can be overridden by adding it to the custom form.