Fixes #12098
This was used in two places: in WagtailImageField.to_python (where it can be replaced with willow's mime_type as per the TODO note) and wagtail.images.models.Picture (where it's applied to a fixed list of image formats, so we can just specify the mime types directly in that list).
jQuery data is used by the jQuery file upload widget and will automatically parse data attributes as objects/or JS primitive values - see https://api.jquery.com/data/
jquery File Upload will automatically parse the data attributes and treat as the default options for initialisation (already used for the url) - see https://github.com/blueimp/jQuery-File-Upload/wiki/API#data-attributes
- Closes #9771 - avoiding globals for UI specific configs
- Relates to #1288 - ongoing work for CSP compliance
- 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
Ensure multi-line comments are cleaned from custom icons in addition to just single line comments.
This doesn't affect Wagtail's, but could reduce the size of 3rd-party icons.
- `js_translation_strings` is no longer used by Wagtail admin code
- It was historically used for generating the JS config strings within templates, we now do this in Python and expose as JSON via the `wagtail_config` template tag
- Add a warning for deprecation so that we can remove this unused template tag in the next major version of Wagtail
- See #9771 for context
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 (#).
Fixes #12330
The filters "Redirect from", "Redirect to a page", "Target page route", "Redirect to any URL", "Automatically created" and "Created at" were introduced when `exclude = []` was set on the filter class in https://github.com/wagtail/wagtail/pull/8851/files#diff-a1afb82083d526ca8eee0f70b714bea11910ca7b12b8efe8acdcb3b8fc6c0519, and there's good reason to believe that this change was unintentional - there's no acknowledgement of it in the PR comments, the "Created at" filter is essentially non-functional since it filters on an exact timestamp rather than a date range, and the labels have not been changed from the verbose_name field defaults (which are somewhat confusing when used outside the context of the create/edit form).
The "Redirect to a page" filter in particular is causing issues on large sites as this dropdown can legitimately run to many thousands of entries and exceed web server resource limits.
Thus, roll back this filter set to its previous state of just `is_permanent` and `site`. If a user needs to find all redirects pointing to a given page, searching on the page title will generally be sufficient.
