Fixes#12688. Without this, commenting on a field of an ImageBlock will cause subsequent loads of the edit view to fail at the point that the comments validate that they are attached to a valid block path.
The get_usage() method returns a ReferenceGroups instance that defines a
__getitem__ method. Accessing get_usage().count() from the template
means that Django tries to access the count via ["count"], which fails,
then continues by using getattr(reference_groups, "count") before
finally calling the count method.
We have seen reports where the blocktranslate tag fails because the
usage_count_val is not a number. We haven't got a reproducible example,
but this would help surface any errors, as the exception would be raised
from the Python code rather than the template.
Currently, the code that handles the POST request for reverting a
revision lives in the EditView class, while the revisions_revert view is
a smaller view that tries to "mimic" the EditView for rendering the view
as part of a GET request. The view injects the revision ID into the
form, which has the action URL hardcoded to the EditView. Including the
revision ID in the form allows the EditView to tell whether it's in a
"reverting" mode or not, and adjust the POST logic accordingly.
However, this results in possible inconsistencies in both views.
Whenever we want to change EditView code or template, we need to make
sure to also update the revisions_revert view. The fact that the
revisions_revert view is a function-based view doesn't help.
Instead of copying the view code and reusing the template with the
addition of injecting the revision ID in the form, turn it into a proper
subclass of the EditView, and make use of Django's URL patterns to
retrieve the revision ID in the EditView.
This approach is similar to how reverting revisions is handled for
snippets.
Ideally, all the code for handling revisions revert should live in the
RevisionsRevertView, and the EditView shouldn't know about it at all.
This is how it's done for snippets: all the revisions revert-related
code is put in RevisionsRevertMixin.
However, this is currently not possible for pages without more
significant refactoring, so this commit does the minimal change needed
to achieve the goal of keeping the revisions_revert view in sync with
the EditView.
- window.buildExpandingFormset and using the base class `ExpandingFormset` can now be deprecated.
- Move the window global setting to core.js which avoids the need to add the import in editor_js, to align with other future deprecations in core.js
- Add upgrade considerations in release notes
- `ExpandingFormset` is still needed for other existing usage (InlinePanel/MultipleChooserPanel)
- Add additional JSDoc and updates to Eslint to advise developers that this feature is not to be used for new code
- Use the Wagtail admin formset mixin to adopt new data attributes on core form parts
- Update the edit/create templates to put the attributes on the remaining elements
- Add basic unit tests for smoke testing data attributes
- Remove CSP incompatible inline scripts approach
- Remove the now unused standalone static build/imports for the group edit view as this will not be needed
- Update Eslint accordingly
- Use the Wagtail admin formset mixin to adopt new data attributes on core form parts
- Update the edit/create templates to put the attributes on the remaining elements
- Add basic unit tests for smoke testing data attributes
- Remove CSP incompatible inline scripts approach
- Remove the now unused standalone static build/imports for the group edit view as this will not be needed
- Ensure that the edit workflow form does not render any JS or attributes when the pages are not actually editable (workflow disabled)
- Leverage the new Django 4.0 feature `deletion_widget` for formsets to attach data attributes and make the input a HiddenInput for existing and 'blank' forms.
- Add support for data attributes used by the new Stimulus FormsetController
Replaces the core functionality in `client/src/components/ExpandingFormset/index.js` and the Delete callbacks in other usage of the `window.buildExpandingFormset` function.
Provides limitations on add/delete once the min/max have been reached but does not set up any disabling of these buttons as this is currently in the remit of `InlinePanel`.
Includes a full test suite for error handling, updating inputs and nested usage which leverages Stimulus' scope management.
Does not rely on any id attribute structure or wrangling.
Relates to #7915
sage