- Add cross-links to documentation where possible from the 7.1 release notes
- Remove empty sections in the 7.1 release notes (upgrade considerations)
- Format whitespace int he 7.1 release notes
- Consistently use `user bar`, not `userbar` in release notes and related documentation & changelog
- Format bullet points (where diffs are minimal) to align with Markdown Prettier formatting
- Removed capfirst() when initializing the label from the related
model's verbose name, so it can be used for both the add-button and
the child panel's header. Further used capfirst in the template when
rendering the child panel's header and removed lower filter from the
add-button's label.
- Tests:
- changed labels and verbose names related to the InlinePanel to
the correct singular and lowercased form
- removed unnecessary heading kwargs, where the default heading
already equals that definition
- Docs: Removed unnecessary and verbose label and header definitions
from the documentation
Fixes#13221
The primary use-case for this was to point to the first item of a radio select, and Django no longer does this as of 4.0 (b9e872b593). In all other known cases, the default behaviour of returning the one input element's ID is sufficient - and if any other widget has non-standard handling of input elements to the point that this isn't the case, then it will certainly need its own Widget subclass on the JS side, and at that point it makes far more sense to provide a suitable JS implementation of idForLabel rather than doing a string replacement on whatever the Django function gives you.
This shouldn't break any documented APIs, as the base Widget class was not exposed outside of entrypoints/admin/telepath/widgets.js on previous releases, meaning that third-party widgets are expected to implement their own work-alike classes which will be unchanged by this. We update the widget API documentation to reflect the fact that an id_for_label parameter is no longer considered a good idea, though.
It references wagtailadmin/js/telepath/telepath.js and wagtail.admin.staticfiles, and we don't want wagtail core to depend on code in wagtail.admin. Also, we don't want to encourage use of this registry outside of admin views, as adapters registered here are likely to depend on admin-specific JS includes.