- This allows us to pass extra data for the widget to use in a backwards-compatible way.
- FieldBlock: render 'required' and 'aria-describedby' attributes when appropriate
- Ensure options passed to `render` override defaults
- FieldBlock: add test proving options are constructed and passed down
- Allow Telepath's widget rendering to take options
- Include extra accessibility-related attributes in html output
- Resolves missing required attribute on input elements for required fields
- Resolves missing aria-describedby attribute on input element when the field has help text.
- Partial work on #10300
- Add new stylelint fix script & generic 'fix' (all) script in npm scripts.
- Disable autofix on `stylelint-declaration-strict-value` as this requires a custom function to be created.
The rebuild_reference_index management command starts by
deleting the entire ReferenceIndex table.
In Wagtail versions 4.1 and 4.2, all models are tracked in the
reference index. Unfortunately this also includes the
ReferenceIndex model itself. This is changed in 5.0 to only track certain Wagtail-related models [0].
This means that when rebuild_reference_index runs in versions
4.1 or 4.2, and deletes the ReferenceIndex table, it runs the code that checks whether ReferenceIndex instances have any
references.
If the index contains a large number of references (as could
happen if an upgrade to 4.1 built an index for a non-Wagtail
model), this process becomes extremely slow. There's no need
for the rebuild_reference_index command to update the index
when deleting it, so this can be significantly optimized by
disabling auto update here.
[0] https://docs.wagtail.org/en/stable/releases/5.0.html#referenceindex-no-longer-tracks-models-used-outside-of-wagtail
This migration would fail on Wagtail instances that have been around
since v0.5 (when we still used django-south), because the column order
of the wagtailsearch_querydailyhits table is different from the newly-created
wagtailsearchpromotions_querydailyhits.
If you hit this issue, you deserve a 🌟
This can be used in other places, but ensures caches are invalidated
whenever something about a page changes.
- Add a util to get wagtail-specific fragment cache keys
- Don't pollute context when injecting site variable
- Add documentation on wagtail fragment caching
- Define an intelligent cache key for pages
- Allow the components of the cache key to be easily modified
- Note that some manual changes may not create a new cache key
Co-authored-by: Andy Babic <andyjbabic@gmail.com>
Closes #5074
