It was popped from the menu_items, so it's not in that list when we loop
through to collect the media files.
And add an early return if the default item is undefined (e.g. if a
construct hook caused the list to be empty), so it doesn't crash when it
tries to render to action menu.
and reuse the markup for footer actions.
With this commit, all form footer actions are now using the single
implementation in generic/form.html template.
This allows us to reuse more markup from the generic templates,
including the code for footer actions dropdown. This also gives us the
unsaved changes warning to these views.
This gives us the disabled button with spinner upon clicking, as well as
the ability to use ctrl+s to save.
Note that we do not introduce a custom label for the in-progress state
of the button yet.
With this added, we can now simplify the overrides in snippets templates
for the footer actions to only override the action buttons to use the
class component.
This now gives us the dropdown button for the footer actions in most
areas of the admin:
- Generic views (ModelViewSets)
- Images
- Documents
- Sites
- Locales
- Collections
- Redirects (edit view, create view TBC)
The following areas have footer actions with their own implementation,
and will be refactored in subsequent commits:
- Workflows
- Workflow tasks
- Settings
The following areas need further work before it can use footer actions,
as they still use function-based view and may not work with the generic
templates yet:
- Redirects create view
- Search promotions
Lastly, for pages and snippets, they have their own footer actions
implementation for now because they use the ActionMenu class components.
Despite this, we also want to move the 'Delete' action to the header
'more' actions dropdown rather than the footer actions. This means we'll
get rid of the extra_actions block in generic/edit.html template in the
next commit. However, we'll keep the actual dropdown markup in
generic/form.html as it's still going to be needed by the workflows and
tasks edit templates to show the enable/disable buttons.
This was only recently introduced in
08fd30cb65 (not yet released).
We already have a documented 'fields' block in groups and users' create
and edit views for customisation. Using the same name for the overall
form content (other than the actions) would prevent us from making use
of this block for those documented templates.
Rename the block to form_content, so we can override the block while
also defining the documented 'fields' block in groups and users' create
and edit views.
TypedTableBlock did not provide a `get_api_representation` method, so it fell back on returning the database JSON representation as returned by `get_prep_value`. This resulted in an API representation that was mostly usable, but failed to respect child blocks that override `get_api_representation` themselves.
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
