Ensure the documented support for providing an array of SVG paths to the 'icon' attribute when using `register_rich_text_features` is correctly supported.
Fixes #11777
Fixes #11051
Fixes #10319
See https://docs.wagtail.org/en/stable/extending/extending_draftail.html#creating-new-blocks
> It can also be an array of strings, to use SVG paths, or SVG symbol references for example 'icon': ['M100 100 H 900 V 900 H 100 Z'],. The paths need to be set for a 1024x1024 viewbox.
- When provided with children (e.g. custom paths), render these instead of the `use` symbol reference
- Allow any valid SVG attribute to be passed to the component to render on the `svg` element
- Clean up rendering of className to avoid extra whitespace
- Clean up ordering of the props to be alphabetically sorted
- Update unit tests to be focused more on testing and less on snapshots
The current version is set to 2.3 at the top level of the test. If the
test case uses 5.15.1 as the latest version, then the test should've
failed – but it didn't because we're missing a few promises to be
awaited.
To verify, try reverting the version diff and re-run the test. It would
fail with the new assertions.
Now that the preview sizes are customizable, we can't rely on the
default being the mobile size when we want to force the size of the
preview unavailable screen.
- Avoid using a window global and inline scripts to declare the current bulk action's item time
- Deprecate the usage of `window.wagtailConfig.BULK_ACTION_ITEM_TYPE` with a release note and code comment so that it can be removed in a future release
- Update bulk actions footer template to accept a `item_type` arg, adding this to the DOM element for access within the JavaScript
- Allow a fallback on the model name for core models (e.g. page)
- Also ensure that `{{ block.super }}` is consistently added at the top of the `{% block extra_js %}` (as it is with most usage)
- Relates to #9771 and supports a future migration for bulk actions towards Stimulus
- Relates to ongoing work for CSP compliance #1288
The first step on cleaning up our client-side metadata configuration. With this approach, the values are computed in the `wagtail_config` template tag and passed into the template using Django's json_script.
Then, it's parsed on the client-side and set as `global.wagtailConfig` to retain compatibility with existing code that rely on `window.wagtailConfig`.
This allows us to remove our existing approach of putting metadata values in a `<script>` tag using Django templates directly in the HTML, without changing too much of the existing code, and allowing new code to import the values as `WAGTAIL_CONFIG` from `wagtailConfig.js` instead of using `window.wagtailConfig`. It also means we remove the inline script tag from the core admin base template.
Refactor wagtailConfig util
- Avoid extraneous named exports when they are included in the named WAGTAIL_CONFIG
- Simplify locale map generation
- Avoid reading from global, instead export util that can be used as a global
- Update unit tests for more robust checks
On Chrome, using scrollIntoView() while elements are still being
rendered does not work as expected (i.e. it would intermittently stop
midway).
We start by using getElementById instead of selecting :target, as the
latter doesn't always yield result until the 'load' event is fired. This
does not fix the issue.
The initAnchoredPanels() function is already being called in a 'load'
event handler, so this is as late as it can be, even after the
StreamField blocks have been initialized. However, clearly this doesn't
seem to be enough.
The only solution that seems to work is to use setTimeout, and that does
not even consistently work if the delay isn't high enough for the
elements to render. For now, use 100ms as it seems to be enough in most
cases.
This never really had any effect. Since the new tabs and slim header
designs in v3.0, window.scrollY always equals 0 because the scroll
container is a content element rather than the window itself.
You can verify this by opening the page editor, scrolling down a bit,
and checking window.scrollY on the browser console. It will print 0,
and if you call window.scrollTo(0, 0) it does not do anything.
Even if it did work, we don't want this behaviour either, because this
would interfere with the functionality of scrolling into a panel that
is selected by the URL anchor (#).
