settings.rst 27 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707
  1. ========
  2. Settings
  3. ========
  4. Wagtail makes use of the following settings, in addition to :doc:`Django's core settings <ref/settings>`:
  5. Site Name
  6. =========
  7. .. code-block:: python
  8. WAGTAIL_SITE_NAME = 'Stark Industries Skunkworks'
  9. This is the human-readable name of your Wagtail install which welcomes users upon login to the Wagtail admin.
  10. .. _append_slash:
  11. Append Slash
  12. ============
  13. .. code-block:: python
  14. # Don't add a trailing slash to Wagtail-served URLs
  15. WAGTAIL_APPEND_SLASH = False
  16. Similar to Django's ``APPEND_SLASH``, this setting controls how Wagtail will handle requests that don't end in a trailing slash.
  17. When ``WAGTAIL_APPEND_SLASH`` is ``True`` (default), requests to Wagtail pages which omit a trailing slash will be redirected by Django's :class:`~django.middleware.common.CommonMiddleware` to a URL with a trailing slash.
  18. When ``WAGTAIL_APPEND_SLASH`` is ``False``, requests to Wagtail pages will be served both with and without trailing slashes. Page links generated by Wagtail, however, will not include trailing slashes.
  19. .. note::
  20. If you use the ``False`` setting, keep in mind that serving your pages both with and without slashes may affect search engines' ability to index your site. See `this Google Webmaster Blog post`_ for more details.
  21. .. _this Google Webmaster Blog post: https://webmasters.googleblog.com/2010/04/to-slash-or-not-to-slash.html
  22. Search
  23. ======
  24. .. code-block:: python
  25. WAGTAILSEARCH_BACKENDS = {
  26. 'default': {
  27. 'BACKEND': 'wagtail.search.backends.elasticsearch5',
  28. 'INDEX': 'myapp'
  29. }
  30. }
  31. Define a search backend. For a full explanation, see :ref:`wagtailsearch_backends`.
  32. .. code-block:: python
  33. WAGTAILSEARCH_RESULTS_TEMPLATE = 'myapp/search_results.html'
  34. WAGTAILSEARCH_RESULTS_TEMPLATE_AJAX = 'myapp/includes/search_listing.html'
  35. Override the templates used by the search front-end views.
  36. .. _wagtailsearch_hits_max_age:
  37. .. code-block:: python
  38. WAGTAILSEARCH_HITS_MAX_AGE = 14
  39. Set the number of days (default 7) that search query logs are kept for; these are used to identify popular search terms for :ref:`promoted search results <editors-picks>`. Queries older than this will be removed by the :ref:`search_garbage_collect` command.
  40. Internationalisation
  41. ====================
  42. .. versionadded:: 2.11
  43. Wagtail supports internationalisation of content by maintaining separate trees
  44. of pages for each language.
  45. For a guide on how to enable internationalisation on your site, see the :ref:`configuration guide <enabling_internationalisation>`.
  46. ``WAGTAIL_I18N_ENABLED``
  47. ------------------------
  48. (boolean, default ``False``)
  49. When set to ``True``, Wagtail's internationalisation features will be enabled:
  50. .. code-block:: python
  51. WAGTAIL_I18N_ENABLED = True
  52. .. _wagtail_content_languages_setting:
  53. ``WAGTAIL_CONTENT_LANGUAGES``
  54. -----------------------------
  55. (list, default ``[]``)
  56. A list of languages and/or locales that Wagtail content can be authored in.
  57. For example:
  58. .. code-block:: python
  59. WAGTAIL_CONTENT_LANGUAGES = [
  60. ('en', _("English")),
  61. ('fr', _("French")),
  62. ]
  63. Each item in the list is a 2-tuple containing a language code and a display name.
  64. The language code can either be a language code on its own (such as ``en``, ``fr``),
  65. or it can include a region code (such as ``en-gb``, ``fr-fr``).
  66. You can mix the two formats if you only need to localize in some regions but not others.
  67. This setting follows the same structure of Django's ``LANGUAGES`` setting,
  68. so they can both be set to the same value:
  69. .. code-block:: python
  70. LANGUAGES = WAGTAIL_CONTENT_LANGUAGES = [
  71. ('en-gb', _("English (United Kingdom)")),
  72. ('en-us', _("English (United States)")),
  73. ('es-es', _("Spanish (Spain)")),
  74. ('es-mx', _("Spanish (Mexico)")),
  75. ]
  76. However having them separate allows you to configure many different regions on your site
  77. yet have them share Wagtail content (but defer on things like date formatting, currency, etc):
  78. .. code-block:: python
  79. LANGUAGES = [
  80. ('en', _("English (United Kingdom)")),
  81. ('en-us', _("English (United States)")),
  82. ('es', _("Spanish (Spain)")),
  83. ('es-mx', _("Spanish (Mexico)")),
  84. ]
  85. WAGTAIL_CONTENT_LANGUAGES = [
  86. ('en', _("English")),
  87. ('es', _("Spanish")),
  88. ]
  89. This would mean that your site will respond on the
  90. ``https://www.mysite.com/es/`` and ``https://www.mysite.com/es-MX/`` URLs, but both
  91. of them will serve content from the same "Spanish" tree in Wagtail.
  92. .. note:: ``WAGTAIL_CONTENT_LANGUAGES`` must be a subset of ``LANGUAGES``
  93. Note that all languages that exist in ``WAGTAIL_CONTENT_LANGUAGES``
  94. must also exist in your ``LANGUAGES`` setting. This is so that Wagtail can
  95. generate a live URL to these pages from an untranslated context (e.g. the admin
  96. interface).
  97. Embeds
  98. ======
  99. Wagtail supports generating embed code from URLs to content on an external
  100. providers such as Youtube or Twitter. By default, Wagtail will fetch the embed
  101. code directly from the relevant provider's site using the oEmbed protocol.
  102. Wagtail has a builtin list of the most common providers.
  103. The embeds fetching can be fully configured using the ``WAGTAILEMBEDS_FINDERS``
  104. setting. This is fully documented in :ref:`configuring_embed_finders`.
  105. .. code-block:: python
  106. WAGTAILEMBEDS_RESPONSIVE_HTML = True
  107. Adds ``class="responsive-object"`` and an inline ``padding-bottom`` style to embeds,
  108. to assist in making them responsive. See :ref:`responsive-embeds` for details.
  109. Dashboard
  110. =========
  111. .. code-block:: python
  112. WAGTAILADMIN_RECENT_EDITS_LIMIT = 5
  113. This setting lets you change the number of items shown at 'Your most recent edits' on the dashboard.
  114. .. code-block:: python
  115. WAGTAILADMIN_USER_LOGIN_FORM = 'users.forms.LoginForm'
  116. Allows the default ``LoginForm`` to be extended with extra fields.
  117. .. _wagtail_gravatar_provider_url:
  118. .. code-block:: python
  119. WAGTAIL_GRAVATAR_PROVIDER_URL = '//www.gravatar.com/avatar'
  120. If a user has not uploaded a profile picture, Wagtail will look for an avatar linked to their email address on gravatar.com. This setting allows you to specify an alternative provider such as like robohash.org, or can be set to ``None`` to disable the use of remote avatars completely.
  121. .. _wagtail_moderation_enabled:
  122. .. code-block:: python
  123. WAGTAIL_MODERATION_ENABLED = True
  124. Changes whether the Submit for Moderation button is displayed in the action menu.
  125. Images
  126. ======
  127. .. code-block:: python
  128. WAGTAILIMAGES_IMAGE_MODEL = 'myapp.MyImage'
  129. This setting lets you provide your own image model for use in Wagtail, which might extend the built-in ``AbstractImage`` class or replace it entirely.
  130. .. code-block:: python
  131. WAGTAILIMAGES_MAX_UPLOAD_SIZE = 20 * 1024 * 1024 # i.e. 20MB
  132. This setting lets you override the maximum upload size for images (in bytes). If omitted, Wagtail will fall back to using its 10MB default value.
  133. .. code-block:: python
  134. WAGTAILIMAGES_MAX_IMAGE_PIXELS = 128000000 # i.e. 128 megapixels
  135. This setting lets you override the maximum number of pixels an image can have. If omitted, Wagtail will fall back to using its 128 megapixels default value. The pixel count takes animation frames into account - for example, a 25-frame animation of size 100x100 is considered to have 100 * 100 * 25 = 250000 pixels.
  136. .. code-block:: python
  137. WAGTAILIMAGES_FEATURE_DETECTION_ENABLED = True
  138. This setting enables feature detection once OpenCV is installed, see all details on the :ref:`image_feature_detection` documentation.
  139. .. code-block:: python
  140. WAGTAILIMAGES_INDEX_PAGE_SIZE = 20
  141. Specifies the number of images per page shown on the main Images listing in the Wagtail admin.
  142. .. code-block:: python
  143. WAGTAILIMAGES_USAGE_PAGE_SIZE = 20
  144. Specifies the number of items per page shown when viewing an image's usage (see :ref:`WAGTAIL_USAGE_COUNT_ENABLED <WAGTAIL_USAGE_COUNT_ENABLED>`).
  145. .. code-block:: python
  146. WAGTAILIMAGES_CHOOSER_PAGE_SIZE = 12
  147. Specifies the number of images shown per page in the image chooser modal.
  148. Documents
  149. =========
  150. .. _wagtaildocs_serve_method:
  151. .. code-block:: python
  152. WAGTAILDOCS_SERVE_METHOD = 'redirect'
  153. Determines how document downloads will be linked to and served. Normally, requests for documents are sent through a Django view, to perform permission checks (see :ref:`image_document_permissions`) and potentially other housekeeping tasks such as hit counting. To fully protect against users bypassing this check, it needs to happen in the same request where the document is served; however, this incurs a performance hit as the document then needs to be served by the Django server. In particular, this cancels out much of the benefit of hosting documents on external storage, such as S3 or a CDN.
  154. For this reason, Wagtail provides a number of serving methods which trade some of the strictness of the permission check for performance:
  155. * ``'direct'`` - links to documents point directly to the URL provided by the underlying storage, bypassing the Django view that provides the permission check. This is most useful when deploying sites as fully static HTML (e.g. using `wagtail-bakery <https://github.com/wagtail/wagtail-bakery>`_ or `Gatsby <https://www.gatsbyjs.org/>`_).
  156. * ``'redirect'`` - links to documents point to a Django view which will check the user's permission; if successful, it will redirect to the URL provided by the underlying storage to allow the document to be downloaded. This is most suitable for remote storage backends such as S3, as it allows the document to be served independently of the Django server. Note that if a user is able to guess the latter URL, they will be able to bypass the permission check; some storage backends may provide configuration options to generate a random or short-lived URL to mitigate this.
  157. * ``'serve_view'`` - links to documents point to a Django view which both checks the user's permission, and serves the document. Serving will be handled by `django-sendfile <https://github.com/johnsensible/django-sendfile>`_, if this is installed and supported by your server configuration, or as a streaming response from Django if not. When using this method, it is recommended that you configure your webserver to *disallow* serving documents directly from their location under ``MEDIA_ROOT``, as this would provide a way to bypass the permission check.
  158. If ``WAGTAILDOCS_SERVE_METHOD`` is unspecified or set to ``None``, the default method is ``'redirect'`` when a remote storage backend is in use (i.e. one that exposes a URL but not a local filesystem path), and ``'serve_view'`` otherwise. Finally, some storage backends may not expose a URL at all; in this case, serving will proceed as for ``'serve_view'``.
  159. .. _wagtaildocs_content_types:
  160. .. code-block:: python
  161. WAGTAILDOCS_CONTENT_TYPES = {
  162. 'pdf': 'application/pdf',
  163. 'txt': 'text/plain',
  164. }
  165. Specifies the MIME content type that will be returned for the given file extension, when using the ``serve_view`` method. Content types not listed here will be guessed using the Python ``mimetypes.guess_type`` function, or ``application/octet-stream`` if unsuccessful.
  166. .. _wagtaildocs_inline_content_types:
  167. .. code-block:: python
  168. WAGTAILDOCS_INLINE_CONTENT_TYPES = ['application/pdf', 'text/plain']
  169. A list of MIME content types that will be shown inline in the browser (by serving the HTTP header ``Content-Disposition: inline``) rather than served as a download, when using the ``serve_view`` method. Defaults to ``application/pdf``.
  170. .. _wagtaildocs_extensions:
  171. .. code-block:: python
  172. WAGTAILDOCS_EXTENSIONS = ['pdf', 'docx']
  173. A list of allowed document extensions that will be validated during document uploading.
  174. If this isn't supplied all document extensions are allowed.
  175. Warning: this doesn't always ensure that the uploaded file is valid as files can
  176. be renamed to have an extension no matter what data they contain.
  177. Password Management
  178. ===================
  179. .. code-block:: python
  180. WAGTAIL_PASSWORD_MANAGEMENT_ENABLED = True
  181. This specifies whether users are allowed to change their passwords (enabled by default).
  182. .. code-block:: python
  183. WAGTAIL_PASSWORD_RESET_ENABLED = True
  184. This specifies whether users are allowed to reset their passwords. Defaults to the same as ``WAGTAIL_PASSWORD_MANAGEMENT_ENABLED``. Password reset emails will be sent from the address specified in Django's ``DEFAULT_FROM_EMAIL`` setting.
  185. .. code-block:: python
  186. WAGTAILUSERS_PASSWORD_ENABLED = True
  187. This specifies whether password fields are shown when creating or editing users through Settings -> Users (enabled by default). Set this to False (along with ``WAGTAIL_PASSWORD_MANAGEMENT_ENABLED`` and ``WAGTAIL_PASSWORD_RESET_ENABLED``) if your users are authenticated through an external system such as LDAP.
  188. .. code-block:: python
  189. WAGTAILUSERS_PASSWORD_REQUIRED = True
  190. This specifies whether password is a required field when creating a new user. True by default; ignored if ``WAGTAILUSERS_PASSWORD_ENABLED`` is false. If this is set to False, and the password field is left blank when creating a user, then that user will have no usable password; in order to log in, they will have to reset their password (if ``WAGTAIL_PASSWORD_RESET_ENABLED`` is True) or use an alternative authentication system such as LDAP (if one is set up).
  191. .. code-block:: python
  192. WAGTAIL_EMAIL_MANAGEMENT_ENABLED = True
  193. This specifies whether users are allowed to change their email (enabled by default).
  194. .. _email_notifications:
  195. Email Notifications
  196. ===================
  197. .. code-block:: python
  198. WAGTAILADMIN_NOTIFICATION_FROM_EMAIL = 'wagtail@myhost.io'
  199. Wagtail sends email notifications when content is submitted for moderation, and when the content is accepted or rejected. This setting lets you pick which email address these automatic notifications will come from. If omitted, Wagtail will fall back to using Django's ``DEFAULT_FROM_EMAIL`` setting if set, or ``webmaster@localhost`` if not.
  200. .. code-block:: python
  201. WAGTAILADMIN_NOTIFICATION_USE_HTML = True
  202. Notification emails are sent in `text/plain` by default, change this to use HTML formatting.
  203. .. code-block:: python
  204. WAGTAILADMIN_NOTIFICATION_INCLUDE_SUPERUSERS = False
  205. Notification emails are sent to moderators and superusers by default. You can change this to exclude superusers and only notify moderators.
  206. .. _update_notifications:
  207. Wagtail update notifications
  208. ============================
  209. .. code-block:: python
  210. WAGTAIL_ENABLE_UPDATE_CHECK = True
  211. For admins only, Wagtail performs a check on the dashboard to see if newer releases are available. This also provides the Wagtail team with the hostname of your Wagtail site. If you'd rather not receive update notifications, or if you'd like your site to remain unknown, you can disable it with this setting.
  212. Private pages / documents
  213. =========================
  214. .. code-block:: python
  215. PASSWORD_REQUIRED_TEMPLATE = 'myapp/password_required.html'
  216. This is the path to the Django template which will be used to display the "password required" form when a user accesses a private page. For more details, see the :ref:`private_pages` documentation.
  217. .. code-block:: python
  218. DOCUMENT_PASSWORD_REQUIRED_TEMPLATE = 'myapp/document_password_required.html'
  219. As above, but for password restrictions on documents. For more details, see the :ref:`private_pages` documentation.
  220. Login page
  221. ==========
  222. The basic login page can be customised with a custom template.
  223. .. code-block:: python
  224. WAGTAIL_FRONTEND_LOGIN_TEMPLATE = 'myapp/login.html'
  225. Or the login page can be a redirect to an external or internal URL.
  226. .. code-block:: python
  227. WAGTAIL_FRONTEND_LOGIN_URL = '/accounts/login/'
  228. For more details, see the :ref:`login_page` documentation.
  229. Case-Insensitive Tags
  230. =====================
  231. .. code-block:: python
  232. TAGGIT_CASE_INSENSITIVE = True
  233. Tags are case-sensitive by default ('music' and 'Music' are treated as distinct tags). In many cases the reverse behaviour is preferable.
  234. Multi-word tags
  235. ===============
  236. .. code-block:: python
  237. TAG_SPACES_ALLOWED = False
  238. Tags can only consist of a single word, no spaces allowed. The default setting is ``True`` (spaces in tags are allowed).
  239. Tag limit
  240. =========
  241. .. code-block:: python
  242. TAG_LIMIT = 5
  243. Limit the number of tags that can be added to (django-taggit) Tag model. Default setting is ``None``, meaning no limit on tags.
  244. Unicode Page Slugs
  245. ==================
  246. .. code-block:: python
  247. WAGTAIL_ALLOW_UNICODE_SLUGS = True
  248. By default, page slugs can contain any alphanumeric characters, including non-Latin alphabets. Set this to False to limit slugs to ASCII characters.
  249. .. _WAGTAIL_AUTO_UPDATE_PREVIEW:
  250. Auto update preview
  251. ===================
  252. .. code-block:: python
  253. WAGTAIL_AUTO_UPDATE_PREVIEW = False
  254. When enabled, data from an edited page is automatically sent to the server
  255. on each change, even without saving. That way, users don’t have to click on
  256. “Preview” to update the content of the preview page. However, the preview page
  257. tab is not refreshed automatically, users have to do it manually.
  258. This behaviour is disabled by default.
  259. Custom User Edit Forms
  260. ======================
  261. See :doc:`/advanced_topics/customisation/custom_user_models`.
  262. .. code-block:: python
  263. WAGTAIL_USER_EDIT_FORM = 'users.forms.CustomUserEditForm'
  264. Allows the default ``UserEditForm`` class to be overridden with a custom form when
  265. a custom user model is being used and extra fields are required in the user edit form.
  266. .. code-block:: python
  267. WAGTAIL_USER_CREATION_FORM = 'users.forms.CustomUserCreationForm'
  268. Allows the default ``UserCreationForm`` class to be overridden with a custom form when
  269. a custom user model is being used and extra fields are required in the user creation form.
  270. .. code-block:: python
  271. WAGTAIL_USER_CUSTOM_FIELDS = ['country']
  272. A list of the extra custom fields to be appended to the default list.
  273. .. _WAGTAIL_USAGE_COUNT_ENABLED:
  274. Usage for images, documents and snippets
  275. ========================================
  276. .. code-block:: python
  277. WAGTAIL_USAGE_COUNT_ENABLED = True
  278. When enabled Wagtail shows where a particular image, document or snippet is being used on your site.
  279. This is disabled by default because it generates a query which may run slowly on sites with large numbers of pages.
  280. A link will appear on the edit page (in the rightmost column) showing you how many times the item is used.
  281. Clicking this link takes you to the "Usage" page, which shows you where the snippet, document or image is used.
  282. The link is also shown on the delete page, above the "Delete" button.
  283. .. note::
  284. The usage count only applies to direct (database) references. Using documents, images and snippets within StreamFields or rich text fields will not be taken into account.
  285. Date and DateTime inputs
  286. ========================
  287. .. code-block:: python
  288. WAGTAIL_DATE_FORMAT = '%d.%m.%Y.'
  289. WAGTAIL_DATETIME_FORMAT = '%d.%m.%Y. %H:%M'
  290. WAGTAIL_TIME_FORMAT = '%H:%M'
  291. Specifies the date, time and datetime format to be used in input fields in the Wagtail admin. The format is specified in `Python datetime module syntax <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_, and must be one of the recognised formats listed in the ``DATE_INPUT_FORMATS``, ``TIME_INPUT_FORMATS``, or ``DATETIME_INPUT_FORMATS`` setting respectively (see `DATE_INPUT_FORMATS <https://docs.djangoproject.com/en/stable/ref/settings/#std:setting-DATE_INPUT_FORMATS>`_).
  292. .. _WAGTAIL_USER_TIME_ZONES:
  293. Time zones
  294. ==========
  295. Logged-in users can choose their current time zone for the admin interface in the account settings. If is no time zone selected by the user, then ``TIME_ZONE`` will be used.
  296. (Note that time zones are only applied to datetime fields, not to plain time or date fields. This is a Django design decision.)
  297. The list of time zones is by default the common_timezones list from pytz.
  298. It is possible to override this list via the ``WAGTAIL_USER_TIME_ZONES`` setting.
  299. If there is zero or one time zone permitted, the account settings form will be hidden.
  300. .. code-block:: python
  301. WAGTAIL_USER_TIME_ZONES = ['America/Chicago', 'Australia/Sydney', 'Europe/Rome']
  302. .. _WAGTAILADMIN_PERMITTED_LANGUAGES:
  303. Admin languages
  304. ===============
  305. Users can choose between several languages for the admin interface
  306. in the account settings. The list of languages is by default all the available
  307. languages in Wagtail with at least 90% coverage. To change it, set ``WAGTAILADMIN_PERMITTED_LANGUAGES``:
  308. .. code-block:: python
  309. WAGTAILADMIN_PERMITTED_LANGUAGES = [('en', 'English'),
  310. ('pt', 'Portuguese')]
  311. Since the syntax is the same as Django ``LANGUAGES``, you can do this so users
  312. can only choose between front office languages:
  313. .. code-block:: python
  314. LANGUAGES = WAGTAILADMIN_PERMITTED_LANGUAGES = [('en', 'English'),
  315. ('pt', 'Portuguese')]
  316. Static files
  317. ============
  318. .. code-block:: python
  319. WAGTAILADMIN_STATIC_FILE_VERSION_STRINGS = False
  320. Static file URLs within the Wagtail admin are given a version-specific query string of the form ``?v=1a2b3c4d``, to prevent outdated cached copies of JavaScript and CSS files from persisting after a Wagtail upgrade. To disable these, set ``WAGTAILADMIN_STATIC_FILE_VERSION_STRINGS`` to ``False``.
  321. API Settings
  322. ============
  323. For full documentation on API configuration, including these settings, see :ref:`api_v2_configuration` documentation.
  324. .. code-block:: python
  325. WAGTAILAPI_BASE_URL = 'http://api.example.com/'
  326. Required when using frontend cache invalidation, used to generate absolute URLs to document files and invalidating the cache.
  327. .. code-block:: python
  328. WAGTAILAPI_LIMIT_MAX = 500
  329. Default is 20, used to change the maximum number of results a user can request at a time, set to ``None`` for no limit.
  330. .. code-block:: python
  331. WAGTAILAPI_SEARCH_ENABLED = False
  332. Default is true, setting this to false will disable full text search on all endpoints.
  333. .. code-block:: python
  334. WAGTAILAPI_USE_FRONTENDCACHE = True
  335. Requires ``wagtailfrontendcache`` app to be installed, indicates the API should use the frontend cache.
  336. Frontend cache
  337. ==============
  338. For full documentation on frontend cache invalidation, including these settings, see :ref:`frontend_cache_purging`.
  339. .. code-block:: python
  340. WAGTAILFRONTENDCACHE = {
  341. 'varnish': {
  342. 'BACKEND': 'wagtail.contrib.frontend_cache.backends.HTTPBackend',
  343. 'LOCATION': 'http://localhost:8000',
  344. },
  345. }
  346. See documentation linked above for full options available.
  347. .. note::
  348. ``WAGTAILFRONTENDCACHE_LOCATION`` is no longer the preferred way to set the cache location, instead set the ``LOCATION`` within the ``WAGTAILFRONTENDCACHE`` item.
  349. .. code-block:: python
  350. WAGTAILFRONTENDCACHE_LANGUAGES = [l[0] for l in settings.LANGUAGES]
  351. Default is an empty list, must be a list of languages to also purge the urls for each language of a purging url. This setting needs ``settings.USE_I18N`` to be ``True`` to work.
  352. .. _WAGTAILADMIN_RICH_TEXT_EDITORS:
  353. Rich text
  354. =========
  355. .. code-block:: python
  356. WAGTAILADMIN_RICH_TEXT_EDITORS = {
  357. 'default': {
  358. 'WIDGET': 'wagtail.admin.rich_text.DraftailRichTextArea',
  359. 'OPTIONS': {
  360. 'features': ['h2', 'bold', 'italic', 'link', 'document-link']
  361. }
  362. },
  363. 'legacy': {
  364. 'WIDGET': 'wagtail.admin.rich_text.HalloRichTextArea',
  365. }
  366. }
  367. Customise the behaviour of rich text fields. By default, ``RichTextField`` and ``RichTextBlock`` use the configuration given under the ``'default'`` key, but this can be overridden on a per-field basis through the ``editor`` keyword argument, e.g. ``body = RichTextField(editor='legacy')``. Within each configuration block, the following fields are recognised:
  368. * ``WIDGET``: The rich text widget implementation to use. Wagtail provides two implementations: ``wagtail.admin.rich_text.DraftailRichTextArea`` (a modern extensible editor which enforces well-structured markup) and ``wagtail.admin.rich_text.HalloRichTextArea`` (deprecated; works directly at the HTML level). Other widgets may be provided by third-party packages.
  369. * ``OPTIONS``: Configuration options to pass to the widget. Recognised options are widget-specific, but both ``DraftailRichTextArea`` and ``HalloRichTextArea`` accept a ``features`` list indicating the active rich text features (see :ref:`rich_text_features`).
  370. If a ``'default'`` editor is not specified, rich text fields that do not specify an ``editor`` argument will use the Draftail editor with the default feature set enabled.
  371. .. versionchanged:: 2.10
  372. Omitting the ``'default'`` editor now leaves the original default editor intact, so it is no longer necessary to redefine ``'default'`` when adding alternative editors.
  373. .. _WAGTAILADMIN_GLOBAL_PAGE_EDIT_LOCK:
  374. Page locking
  375. ============
  376. ``WAGTAILADMIN_GLOBAL_PAGE_EDIT_LOCK`` can be set to ``True`` to prevent users
  377. from editing pages that they have locked.
  378. Redirects
  379. =========
  380. .. code-block:: python
  381. WAGTAIL_REDIRECTS_FILE_STORAGE = 'tmp_file'
  382. By default the redirect importer keeps track of the uploaded file as a temp file, but on certain environments (load balanced/cloud environments), you cannot keep a shared file between environments. For those cases you can use the built-in cache to store the file instead.
  383. .. code-block:: python
  384. WAGTAIL_REDIRECTS_FILE_STORAGE = 'cache'
  385. Form builder
  386. ============
  387. .. code-block:: python
  388. WAGTAILFORMS_HELP_TEXT_ALLOW_HTML = True
  389. When true, HTML tags in form field help text will be rendered unescaped (default: False).
  390. .. WARNING::
  391. Enabling this option will allow editors to insert arbitrary HTML into the page, such as scripts that could allow the editor to acquire administrator privileges when another administrator views the page. Do not enable this setting unless your editors are fully trusted.
  392. .. _workflow_settings:
  393. Workflow
  394. ========
  395. .. code-block:: python
  396. WAGTAIL_WORKFLOW_REQUIRE_REAPPROVAL_ON_EDIT = True
  397. Moderation workflows can be used in two modes. The first is to require that all tasks must approve a specific page revision for the workflow to complete. As a result,
  398. if edits are made to a page while it is in moderation, any approved tasks will need to be re-approved for the new revision before the workflow finishes.
  399. This is the default, ``WAGTAIL_WORKFLOW_REQUIRE_REAPPROVAL_ON_EDIT = True`` . The second mode does not require reapproval: if edits are made when
  400. tasks have already been approved, those tasks do not need to be reapproved. This is more suited to a hierarchical workflow system. To use workflows in this mode,
  401. set ``WAGTAIL_WORKFLOW_REQUIRE_REAPPROVAL_ON_EDIT = False``.
  402. .. code-block:: python
  403. WAGTAIL_FINISH_WORKFLOW_ACTION = 'wagtail.core.workflows.publish_workflow_state'
  404. This sets the function to be called when a workflow completes successfully - by default, ``wagtail.core.workflows.publish_workflow_state``,
  405. which publishes the page. The function must accept a ``WorkflowState`` object as its only positional argument.
  406. .. code-block:: python
  407. WAGTAIL_WORKFLOW_CANCEL_ON_PUBLISH = True
  408. This determines whether publishing a page with an ongoing workflow will cancel the workflow (if true) or leave the workflow unaffected (false).
  409. Disabling this could be useful if your site has long, multi-step workflows, and you want to be able to publish urgent page updates while the
  410. workflow continues to provide less urgent feedback.