mirror of
https://github.com/wagtail/wagtail.git
synced 2024-11-21 18:09:02 +01:00
fix up spelling in documentation & docstrings (should be en-GB not en-US)
- customize -> customise - color -> colour - customizing -> customising - organize -> organise
This commit is contained in:
parent
885b593234
commit
d9981e0ec7
@ -1336,7 +1336,7 @@ Changelog
|
||||
* Updated documentation styling (LB (Ben Johnston))
|
||||
* Rich text fields now take feature lists into account when whitelisting HTML elements (Matt Westcott)
|
||||
* FormPage lists and Form submission lists in admin now use class based views for easy overriding (Johan Arensman)
|
||||
* Form submission csv exports now have the export date in the filename and can be customized (Johan Arensman)
|
||||
* Form submission csv exports now have the export date in the filename and can be customised (Johan Arensman)
|
||||
* FormBuilder class now uses bound methods for field generation, adding custom fields is now easier and documented (LB (Ben) Johnston)
|
||||
* Added `WAGTAILADMIN_NOTIFICATION_INCLUDE_SUPERUSERS` setting to determine whether superusers are included in moderation email notifications (Bruno Alla)
|
||||
* Added a basic Dockerfile to the project template (Tom Dyson)
|
||||
|
@ -38,7 +38,7 @@ The features below were developed thanks to the sponsorship of these organsation
|
||||
|
||||
- Page aliases - [The Mozilla Foundation](https://foundation.mozilla.org/en/)
|
||||
|
||||
- Hooks for Snippet customization - [The Mozilla Foundation](https://foundation.mozilla.org/en/)
|
||||
- Hooks for Snippet customisation - [The Mozilla Foundation](https://foundation.mozilla.org/en/)
|
||||
|
||||
- Utility for testing hooks - [The Mozilla Foundation](https://foundation.mozilla.org/en/)
|
||||
|
||||
|
@ -4,7 +4,7 @@
|
||||
|
||||
REFERENCE
|
||||
|
||||
* We organize our styles based on a combination of ITCSS and
|
||||
* We organise our styles based on a combination of ITCSS and
|
||||
the Sass 7-1 pattern.
|
||||
* Classes should be written using BEM, which we modify to include a prefix.
|
||||
* Every BEM block should have its own file.
|
||||
|
@ -31,7 +31,7 @@ Ideally, always add an optional “alt text” field wherever an image is used,
|
||||
|
||||
- For normal fields, add an alt text field to your image’s panel.
|
||||
- For StreamField, add an extra field to your image block.
|
||||
- For rich text – Wagtail already makes it possible to customize alt text for rich text images.
|
||||
- For rich text – Wagtail already makes it possible to customise alt text for rich text images.
|
||||
|
||||
When defining the alt text fields, make sure they are optional so editors can choose to not write any alt text for decorative images. Take the time to provide ``help_text`` with appropriate guidance.
|
||||
For example, linking to `established resources on alt text <https://axesslab.com/alt-texts/>`_.
|
||||
|
@ -312,7 +312,7 @@ These two files should reside in your project directory (``myproject/myproject/`
|
||||
# performed by this configuration is to send an email to
|
||||
# the site admins on every HTTP 500 error when DEBUG=False.
|
||||
# See https://docs.djangoproject.com/en/stable/topics/logging for
|
||||
# more details on how to customize your logging configuration.
|
||||
# more details on how to customise your logging configuration.
|
||||
LOGGING = {
|
||||
'version': 1,
|
||||
'disable_existing_loggers': False,
|
||||
|
@ -91,16 +91,16 @@ To replace the welcome message on the dashboard, create a template file ``dashbo
|
||||
|
||||
{% block branding_welcome %}Welcome to Frank's Site{% endblock %}
|
||||
|
||||
.. _custom_user_interface_colors:
|
||||
.. _custom_user_interface_colours:
|
||||
|
||||
Custom user interface colors
|
||||
============================
|
||||
Custom user interface colours
|
||||
=============================
|
||||
|
||||
|
||||
.. warning::
|
||||
The default Wagtail colors conform to the WCAG2.1 AA level color contrast requirements. When customizing the admin colors you should test the contrast using tools like `Axe <https://www.deque.com/axe/browser-extensions/>`_.
|
||||
The default Wagtail colours conform to the WCAG2.1 AA level colour contrast requirements. When customising the admin colours you should test the contrast using tools like `Axe <https://www.deque.com/axe/browser-extensions/>`_.
|
||||
|
||||
To customize the primary color used in the admin user interface, inject a CSS file using the hook :ref:`insert_global_admin_css` and override the variables within the ``:root`` selector:
|
||||
To customise the primary colour used in the admin user interface, inject a CSS file using the hook :ref:`insert_global_admin_css` and override the variables within the ``:root`` selector:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@ -108,7 +108,7 @@ To customize the primary color used in the admin user interface, inject a CSS fi
|
||||
--color-primary-hue: 25;
|
||||
}
|
||||
|
||||
``color-primary`` is an `hsl color <https://en.wikipedia.org/wiki/HSL_and_HSV>`_ composed of 3 CSS variables - ``--color-primary-hue`` (0-360 with no unit), ``--color-primary-saturation`` (a percentage), and ``--color-primary-lightness`` (also a percentage). Separating the color into 3 allows us to calculate variations on the color to use alongside the primary color. If needed, you can also control those variations manually by setting ``hue``, ``saturation``, and ``lightness`` variables for the following colors: ``color-primary-darker``, ``color-primary-dark``, ``color-primary-lighter``, ``color-primary-light``, ``color-input-focus``, and ``color-input-focus-border``:
|
||||
``color-primary`` is an `hsl colour <https://en.wikipedia.org/wiki/HSL_and_HSV>`_ composed of 3 CSS variables - ``--color-primary-hue`` (0-360 with no unit), ``--color-primary-saturation`` (a percentage), and ``--color-primary-lightness`` (also a percentage). Separating the colour into 3 allows us to calculate variations on the colour to use alongside the primary colour. If needed, you can also control those variations manually by setting ``hue``, ``saturation``, and ``lightness`` variables for the following colours: ``color-primary-darker``, ``color-primary-dark``, ``color-primary-lighter``, ``color-primary-light``, ``color-input-focus``, and ``color-input-focus-border``:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@ -124,7 +124,7 @@ To customize the primary color used in the admin user interface, inject a CSS fi
|
||||
--color-primary-dark-lightness: 15%;
|
||||
}
|
||||
|
||||
If instead you intend to set all available colors, you can use any valid css colors:
|
||||
If instead you intend to set all available colours, you can use any valid css colours:
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
@ -141,7 +141,7 @@ If instead you intend to set all available colors, you can use any valid css col
|
||||
Specifying a site or page in the branding
|
||||
=========================================
|
||||
|
||||
The admin interface has a number of variables available to the renderer context that can be used to customize the branding in the admin page. These can be useful for customizing the dashboard on a multitenanted Wagtail installation:
|
||||
The admin interface has a number of variables available to the renderer context that can be used to customise the branding in the admin page. These can be useful for customising the dashboard on a multitenanted Wagtail installation:
|
||||
|
||||
``root_page``
|
||||
-------------
|
||||
|
@ -24,7 +24,7 @@ image formats and let the browser choose the one it prefers. For example:
|
||||
{% image myimage width-1000 format-png %}
|
||||
</picture>
|
||||
|
||||
Customizing output formats
|
||||
Customising output formats
|
||||
--------------------------
|
||||
|
||||
By default all ``bmp`` and ``webp`` images are converted to the ``png`` format
|
||||
|
@ -81,7 +81,7 @@ But several features do not currently support multi-tenancy:
|
||||
|
||||
Permission configuration for built-in models like Sites, Site settings and Users is not site-specific, so any user with permission to edit a single entry can edit them all. This limitation can be mostly circumvented by only allowing superusers to manage these models.
|
||||
|
||||
Python, Django, and Wagtail allow you to override, extend and customize functionality. Here are some ideas that may help you create a multi-tenancy solution for your site:
|
||||
Python, Django, and Wagtail allow you to override, extend and customise functionality. Here are some ideas that may help you create a multi-tenancy solution for your site:
|
||||
|
||||
- Django allows to override templates, this also works in the Wagtail admin.
|
||||
- A custom user model can be used to link users to a specific site.
|
||||
|
@ -64,7 +64,7 @@ the latest Wagtail versions.
|
||||
- [Deploying my Wagtail blog to Digital Ocean](https://rosederwelt.com/deploying-my-wagtail-blog-digital-ocean-pt-1/) Part 1 of a 2 part series (29 January 2020)
|
||||
- [How to Create and Manage Menus of Wagtail application](https://www.accordbox.com/blog/wagtail-tutorial-12-how-create-and-manage-menus-wagtail-application/) - An updated overview of implementing menus (22 February 2020)
|
||||
- [Adding a React component in Wagtail Admin](https://dev.to/lb/adding-a-react-component-in-wagtail-admin-3e) - Shows how to render an interactive timeline of published Pages (30 December 2019)
|
||||
- [Wagtail API - how to customize the detail URL](https://dev.to/wagtail/wagtail-api-how-to-customize-the-detail-url-2j3l) (19 December 2020)
|
||||
- [Wagtail API - how to customise the detail URL](https://dev.to/wagtail/wagtail-api-how-to-customize-the-detail-url-2j3l) (19 December 2020)
|
||||
- [How to Add Django Models to the Wagtail Admin](https://dev.to/revsys/how-to-add-django-models-to-the-wagtail-admin-1mdi) (27 August 2019)
|
||||
- [How do I Wagtail](https://foundation.mozilla.org/en/docs/how-do-i-wagtail/) - An Editor\'s Guide for Mozilla\'s usage of Wagtail (25 April 2019)
|
||||
- [Learn Wagtail](https://learnwagtail.com/) - Regular video tutorials about all aspects of Wagtail (1 March 2019)
|
||||
|
@ -141,7 +141,7 @@ intersphinx_mapping = {
|
||||
|
||||
# -- Options for HTML output ----------------------------------------------
|
||||
|
||||
# Theme options are theme-specific and customize the look and feel of a theme
|
||||
# Theme options are theme-specific and customise the look and feel of a theme
|
||||
# further. For a list of options available for each theme, see the
|
||||
# documentation.
|
||||
# html_theme_options = {}
|
||||
|
@ -32,7 +32,7 @@ We use [Prettier](https://prettier.io/) for formatting and [Stylelint](https://s
|
||||
- We follow [BEM](http://getbem.com/) and [ITCSS](https://www.xfive.co/blog/itcss-scalable-maintainable-css-architecture/), with a large amount of utilities created with [Tailwind](https://tailwindcss.com/).
|
||||
- Familiarise yourself with our [stylelint-config-wagtail](https://github.com/wagtail/stylelint-config-wagtail) configuration, which details our preferred code style.
|
||||
- Use `rems` for `font-size`, because they offer absolute control over text. Additionally, unit-less `line-height` is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the `font-size`.
|
||||
- Always use variables for design tokens such as colors or font sizes, rather than hard-coding specific values.
|
||||
- Always use variables for design tokens such as colours or font sizes, rather than hard-coding specific values.
|
||||
- We use the `w-` prefix for all styles intended to be reusable by Wagtail site implementers.
|
||||
|
||||
## JavaScript guidelines
|
||||
|
@ -8,7 +8,7 @@ The views for managing groups within the app are collected into a 'viewset' clas
|
||||
Custom edit/create forms
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This example shows how to customize forms on the 'edit group' and 'create group' views in the Wagtail
|
||||
This example shows how to customise forms on the 'edit group' and 'create group' views in the Wagtail
|
||||
admin.
|
||||
|
||||
Let's say you need to connect Active Directory groups with Django groups.
|
||||
|
@ -396,7 +396,7 @@ To tighten up template code like this, we could use Django's `with` tag:
|
||||
{% endfor %}
|
||||
```
|
||||
|
||||
When you start writing more customized Wagtail code, you'll find a whole set of QuerySet
|
||||
When you start writing more customised Wagtail code, you'll find a whole set of QuerySet
|
||||
modifiers to help you navigate the hierarchy.
|
||||
|
||||
```python
|
||||
|
@ -102,7 +102,7 @@ A few special cases to note about ``list_display``:
|
||||
last_name = models.CharField(max_length=50)
|
||||
color_code = models.CharField(max_length=6)
|
||||
|
||||
def colored_name(self):
|
||||
def styled_name(self):
|
||||
return format_html(
|
||||
'<span style="color: #{};">{} {}</span>',
|
||||
self.color_code,
|
||||
@ -113,7 +113,7 @@ A few special cases to note about ``list_display``:
|
||||
|
||||
class PersonAdmin(ModelAdmin):
|
||||
model = Person
|
||||
list_display = ('first_name', 'last_name', 'colored_name')
|
||||
list_display = ('first_name', 'last_name', 'styled_name')
|
||||
|
||||
|
||||
- If the value of a field is ``None``, an empty string, or an iterable
|
||||
@ -183,22 +183,22 @@ A few special cases to note about ``list_display``:
|
||||
last_name = models.CharField(max_length=50)
|
||||
color_code = models.CharField(max_length=6)
|
||||
|
||||
def colored_first_name(self):
|
||||
def styled_first_name(self):
|
||||
return format_html(
|
||||
'<span style="color: #{};">{}</span>',
|
||||
self.color_code,
|
||||
self.first_name,
|
||||
)
|
||||
colored_first_name.admin_order_field = 'first_name'
|
||||
styled_first_name.admin_order_field = 'first_name'
|
||||
|
||||
|
||||
class PersonAdmin(ModelAdmin):
|
||||
model = Person
|
||||
list_display = ('colored_first_name', 'last_name')
|
||||
list_display = ('styled_first_name', 'last_name')
|
||||
|
||||
|
||||
The above will tell Wagtail to order by the ``first_name`` field when
|
||||
trying to sort by ``colored_first_name`` in the index view.
|
||||
trying to sort by ``styled_first_name`` in the index view.
|
||||
|
||||
To indicate descending order with ``admin_order_field`` you can use a
|
||||
hyphen prefix on the field name. Using the above example, this would look
|
||||
@ -206,7 +206,7 @@ A few special cases to note about ``list_display``:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
colored_first_name.admin_order_field = '-first_name'
|
||||
styled_first_name.admin_order_field = '-first_name'
|
||||
|
||||
|
||||
``admin_order_field`` supports query lookups to sort by values on related
|
||||
|
@ -60,7 +60,7 @@ Settings use edit handlers much like the rest of Wagtail. Add a ``panels`` sett
|
||||
FieldPanel('sign_up_page'),
|
||||
]
|
||||
|
||||
You can also customize the editor handlers :ref:`like you would do for Page model <customising_the_tabbed_interface>`
|
||||
You can also customise the editor handlers :ref:`like you would do for Page model <customising_the_tabbed_interface>`
|
||||
with a custom ``edit_handler`` attribute:
|
||||
|
||||
.. code-block:: python
|
||||
|
@ -3,7 +3,7 @@ Pages
|
||||
|
||||
Wagtail requires a little careful setup to define the types of content that you want to present through your website. The basic unit of content in Wagtail is the :class:`~wagtail.models.Page`, and all of your page-level content will inherit basic webpage-related properties from it. But for the most part, you will be defining content yourself, through the construction of Django models using Wagtail's ``Page`` as a base.
|
||||
|
||||
Wagtail organizes content created from your models in a tree, which can have any structure and combination of model objects in it. Wagtail doesn't prescribe ways to organize and interrelate your content, but here we've sketched out some strategies for organizing your models.
|
||||
Wagtail organises content created from your models in a tree, which can have any structure and combination of model objects in it. Wagtail doesn't prescribe ways to organise and interrelate your content, but here we've sketched out some strategies for organising your models.
|
||||
|
||||
The presentation of your content, the actual webpages, includes the normal use of the Django template system. We'll cover additional functionality that Wagtail provides at the template level later on.
|
||||
|
||||
|
@ -132,7 +132,7 @@ Be careful if you're introducing new required arguments to the ``serve()`` metho
|
||||
.. code-block:: python
|
||||
|
||||
def serve_preview(self, request, mode_name):
|
||||
return self.serve(request, color='purple')
|
||||
return self.serve(request, variant='radiant')
|
||||
|
||||
.. _tagging:
|
||||
|
||||
|
@ -284,7 +284,7 @@ You must define a `heading` or `label` when using `collapsible` with `InlinePane
|
||||
|
||||
By default, Wagtail uses the field's label as placeholder text. To change it, pass to the FieldPanel a widget with a placeholder attribute set to your desired text. You can select widgets from {doc}`Django's form widgets <django:ref/forms/widgets>`, or any of the Wagtail's widgets found in `wagtail.admin.widgets`.
|
||||
|
||||
For example, to customize placeholders for a Book model exposed via ModelAdmin:
|
||||
For example, to customise placeholders for a Book model exposed via ModelAdmin:
|
||||
|
||||
```python
|
||||
# models.py
|
||||
|
@ -20,7 +20,7 @@ As a web developer, though, you probably already have a good understanding of tr
|
||||
captain-picard-day/
|
||||
winter-wrap-up/
|
||||
|
||||
The Wagtail admin interface uses the tree to organize content for editing, letting you navigate up and down levels in the tree through its Explorer menu. This method of organization is a good place to start in thinking about your own Wagtail models.
|
||||
The Wagtail admin interface uses the tree to organise content for editing, letting you navigate up and down levels in the tree through its Explorer menu. This method of organisation is a good place to start in thinking about your own Wagtail models.
|
||||
|
||||
|
||||
Nodes and Leaves
|
||||
@ -31,7 +31,7 @@ It might be handy to think of the ``Page``-derived models you want to create as
|
||||
|
||||
Nodes
|
||||
`````
|
||||
Parent nodes on the Wagtail tree probably want to organize and display a browse-able index of their descendants. A blog, for instance, needs a way to show a list of individual posts.
|
||||
Parent nodes on the Wagtail tree probably want to organise and display a browse-able index of their descendants. A blog, for instance, needs a way to show a list of individual posts.
|
||||
|
||||
A Parent node could provide its own function returning its descendant objects.
|
||||
|
||||
|
@ -337,7 +337,7 @@ Previously, the forms for creating and editing images followed Django's default
|
||||
``construct_wagtail_edit_bird`` hook has been renamed
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Previously you could customize the Wagtail userbar using the ``construct_wagtail_edit_bird`` hook.
|
||||
Previously you could customise the Wagtail userbar using the ``construct_wagtail_edit_bird`` hook.
|
||||
The hook has been renamed to ``construct_wagtail_userbar``.
|
||||
|
||||
The old hook is now deprecated; all existing ``construct_wagtail_edit_bird`` declarations should be updated to the new hook.
|
||||
|
@ -64,7 +64,7 @@ Other features
|
||||
* Updated documentation styling (LB (Ben Johnston))
|
||||
* Rich text fields now take feature lists into account when whitelisting HTML elements (Matt Westcott)
|
||||
* FormPage lists and Form submission lists in admin now use class based views for easy overriding (Johan Arensman)
|
||||
* Form submission csv exports now have the export date in the filename and can be customized (Johan Arensman)
|
||||
* Form submission csv exports now have the export date in the filename and can be customised (Johan Arensman)
|
||||
* FormBuilder class now uses bound methods for field generation, adding custom fields is now easier and documented (LB (Ben Johnston))
|
||||
* Added ``WAGTAILADMIN_NOTIFICATION_INCLUDE_SUPERUSERS`` setting to determine whether superusers are included in moderation email notifications (Bruno Alla)
|
||||
* Added a basic Dockerfile to the project template (Tom Dyson)
|
||||
|
@ -91,7 +91,7 @@ Bug fixes
|
||||
* Bypass select/prefetch related optimisation on ``update_index`` for ``ParentalManyToManyField`` to fix crash (Tim Kamanin)
|
||||
* 'Add user' is now rendered as a button due to the use of quotes within translations (Benoît Vogel)
|
||||
* Menu icon no longer overlaps with title in Modeladmin on mobile (Coen van der Kamp)
|
||||
* Background color overflow within the Wagtail documentation (Sergey Fedoseev)
|
||||
* Background colour overflow within the Wagtail documentation (Sergey Fedoseev)
|
||||
* Page count on homepage summary panel now takes account of user permissions (Andy Chosak)
|
||||
* Explorer view now prevents navigating outside of the common ancestor of the user's permissions (Andy Chosak)
|
||||
* Generate URL for the current site when multiple sites share the same root page (Codie Roelf)
|
||||
|
@ -21,10 +21,10 @@ In-place StreamField updating
|
||||
|
||||
StreamField values now formally support being updated in-place from Python code, allowing blocks to be inserted, modified and deleted rather than having to assign a new list of blocks to the field. For further details, see :ref:`modifying_streamfield_data`. This feature was developed by Matt Westcott.
|
||||
|
||||
Admin color themes
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
Admin colour themes
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Wagtail’s admin now uses CSS custom properties for its primary teal color. Applying brand colors for the whole user interface only takes a few lines of CSS, and third-party extensions can reuse Wagtail’s CSS variables to support the same degree of customization. Read on :ref:`custom_user_interface_colors`. This feature was developed by Joshua Marantz.
|
||||
Wagtail’s admin now uses CSS custom properties for its primary teal colour. Applying brand colours for the whole user interface only takes a few lines of CSS, and third-party extensions can reuse Wagtail’s CSS variables to support the same degree of customisation. Read on :ref:`custom_user_interface_colours`. This feature was developed by Joshua Marantz.
|
||||
|
||||
Other features
|
||||
~~~~~~~~~~~~~~
|
||||
|
@ -58,7 +58,7 @@ Individual fixes were implemented by a large number of first-time and seasoned c
|
||||
|
||||
* Comments icon now matches link colour (Dmitrii Faiazov, LB (Ben Johnston))
|
||||
* Sidebar logo is now visible in high contrast mode (Dmitrii Faiazov, LB (Ben Johnston))
|
||||
* Icons in links and buttons now use the appropriate “active control” color (Dmitrii Faiazov, LB (Ben Johnston))
|
||||
* Icons in links and buttons now use the appropriate “active control” colour (Dmitrii Faiazov, LB (Ben Johnston))
|
||||
* Comments dropdown now has a border (Shariq Jamil, LB (Ben Johnston))
|
||||
* Make StreamField block chooser menu buttons appear as buttons (Dmitrii Faiazov, LB (Ben Johnston))
|
||||
* Add a separator to identify the search forms (Dmitrii Faiazov, LB (Ben Johnston))
|
||||
|
@ -126,7 +126,7 @@ The internal (undocumented) class-based view `wagtail.admin.views.generic.Delete
|
||||
The new sidebar largely supports the same customisations as its predecessor, with a few exceptions:
|
||||
|
||||
- Top-level menu items should now always provide an `icon_name`, so they can be visually distinguished when the sidebar is collapsed.
|
||||
- `MenuItem` and its sub-classes no longer supports customizing arbitrary HTML attributes.
|
||||
- `MenuItem` and its sub-classes no longer supports customising arbitrary HTML attributes.
|
||||
- `MenuItem` can no longer be sub-classed to customise its HTML output or load additional JavaScript
|
||||
|
||||
For sites relying on those capabilities, we provide a `WAGTAIL_SLIM_SIDEBAR = False` setting to switch back to the legacy sidebar. The legacy sidebar and this setting will be removed in Wagtail 2.18.
|
||||
|
@ -20,7 +20,7 @@ Wagtail isn't fully compliant just yet, but we have made many changes to the adm
|
||||
Here are changes which should make Wagtail more usable for all users regardless of abilities:
|
||||
|
||||
* Increase font-size across the whole admin (Beth Menzies, Katie Locke)
|
||||
* Improved text color contrast across the whole admin (Beth Menzies, Katie Locke)
|
||||
* Improved text colour contrast across the whole admin (Beth Menzies, Katie Locke)
|
||||
* Added consistent focus outline styles across the whole admin (Thibaud Colas)
|
||||
* Ensured the 'add child page' button displays when focused (Helen Chapman, Katie Locke)
|
||||
|
||||
|
@ -57,7 +57,7 @@ Bug fixes
|
||||
|
||||
* Added line breaks to long filenames on multiple image / document uploader (Kevin Howbrook)
|
||||
* Added https support for Scribd oEmbed provider (Rodrigo)
|
||||
* Changed StreamField group label color so labels are visible (Catherine Farman)
|
||||
* Changed StreamField group label colour so labels are visible (Catherine Farman)
|
||||
* Prevented images with a very wide aspect ratio from being displayed distorted in the rich text editor (Iman Syed)
|
||||
* Prevent exception when deleting a model with a protected One-to-one relationship (Neal Todd)
|
||||
* Added labels to snippet bulk edit checkboxes for screen reader users (Martey Dodoo)
|
||||
|
@ -340,18 +340,18 @@ You can encode the image into lossless WebP format by using the ``format-webp-lo
|
||||
|
||||
.. _image_background_color:
|
||||
|
||||
Background color
|
||||
----------------
|
||||
Background colour
|
||||
-----------------
|
||||
|
||||
The PNG and GIF image formats both support transparency, but if you want to
|
||||
convert images to JPEG format, the transparency will need to be replaced with a
|
||||
solid background color.
|
||||
solid background colour.
|
||||
|
||||
By default, Wagtail will set the background to white. But if a white background
|
||||
doesn't fit your design, you can specify a color using the ``bgcolor`` filter.
|
||||
doesn't fit your design, you can specify a colour using the ``bgcolor`` filter.
|
||||
|
||||
This filter takes a single argument, which is a CSS 3 or 6 digit hex code
|
||||
representing the color you would like to use:
|
||||
representing the colour you would like to use:
|
||||
|
||||
.. code-block:: html+Django
|
||||
|
||||
|
@ -4,7 +4,7 @@
|
||||
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 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 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 organised 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. Decide carefully if the content type you would want to build into a snippet might be more suited to a page.
|
||||
|
||||
|
@ -140,14 +140,14 @@ urlpatterns += [
|
||||
# This must be the last URL in this file!
|
||||
|
||||
if settings.APPEND_SLASH:
|
||||
# Only catch unrecognized patterns with a trailing slash
|
||||
# Only catch unrecognised patterns with a trailing slash
|
||||
# and let CommonMiddleware handle adding a slash to every other pattern
|
||||
urlpatterns += [
|
||||
re_path(r"^.*/$", home.default),
|
||||
]
|
||||
|
||||
else:
|
||||
# Catch all unrecognized patterns
|
||||
# Catch all unrecognised patterns
|
||||
urlpatterns += [
|
||||
re_path(r"^", home.default),
|
||||
]
|
||||
|
@ -17,7 +17,7 @@ from .permissions import user_can_edit_setting_type
|
||||
class SettingMenuItem(MenuItem):
|
||||
def __init__(self, model, icon="cog", classnames="", **kwargs):
|
||||
|
||||
# Special-case FontAwesome icons to avoid the breaking changes for those customizations.
|
||||
# Special-case FontAwesome icons to avoid the breaking changes for those customisations.
|
||||
if icon.startswith("fa-"):
|
||||
icon_name = ""
|
||||
icon_classes = "icon icon-" + icon
|
||||
|
Loading…
Reference in New Issue
Block a user