### Support for background tasks using `django-tasks`
Wagtail now integrates with the [django-tasks](https://github.com/realOrangeOne/django-tasks) library to allow moving computationally-intensive tasks out of the request-response cycle, and improving the performance of the Wagtail admin interface. These tasks include:
* Updating the [search index](wagtailsearch_indexing)
* Updating or creating entries for the [reference index](managing_the_reference_index)
* Deleting image and document files when the model is deleted
In the default configuration, these tasks are executed immediately within the request-response cycle, as they were in previous versions of Wagtail. However, by configuring the `TASKS` setting with an appropriate backend [as per the django-tasks documentation](https://github.com/realOrangeOne/django-tasks?tab=readme-ov-file#installation), these tasks can be deferred to a background worker process.
* Add the ability to apply basic Page QuerySet optimizations to `specific()` sub-queries using `select_related`&`prefetch_related`, see [](../reference/pages/queryset_reference.md) (Andy Babic)
* Add the ability to restrict what types of requests a Pages supports via [`allowed_http_methods`](#wagtail.models.Page.allowed_http_methods) (Andy Babic)
* Set content security policy (CSP) headers to block embedded content when serving images and documents (Jake Howard, with thanks to Ali İltizar for the initial report)
* Ensure the accessible labels and tooltips reflect the correct private/public status on the live link button within pages after changing the privacy (Ayaan Qadri)
* Ensure `MultipleChooserPanel` using images or documents work when nested within an `InlinePanel` when no other choosers are in use within the model (Elhussein Almasri)
* Add missing `FilterField("created_at")` to `AbstractDocument` to fix ordering by `created_at` after searching in the documents index view (Srishti Jaiswal)
* Move the [model reference page](../reference/models.md) from reference/pages to the references section as it covers all Wagtail core models (Srishti Jaiswal)
* Move the [panels reference page](../reference/panels.md) from references/pages to the references section as panels are available for any model editing, merge panels API into this page (Srishti Jaiswal)
* Move the tags documentation to standalone [advanced topic for tagging](../advanced_topics/tags.md), instead of being inside the reference/pages section (Srishti Jaiswal)
* Refine the [](adding_reports) page so that common (page/non-page) class references are at the top and the full page only example has correct heading nesting (Alessandro Chitarrini)
* Recommend a larger `DATA_UPLOAD_MAX_NUMBER_FIELDS` when [integrating Wagtail into Django](../getting_started/integrating_into_django.md) (Matt Westcott)
* Update all JavaScript inline scripts & some CSS inline style tags to a CSP compliant approach by using external scripts/styles (Aayushman Singh)
* Update usage of `mark_safe` to `format_html` for any script inclusions, to better avoid XSS issues from example code (Aayushman Singh)
* Update documentation writing guidelines to [encourage better considerations](documentation_code_example_considerations) of security, accessibility and good practice when writing code examples (Aayushman Singh, LB (Ben) Johnston)
* Document usage of [Custom validation for admin form pages](form_builder_custom_admin_validation) when using `AbstractEmailForm` or `AbstractForm` pages (John-Scott Atlakson, LB (Ben) Johnston)
* Add a new [](headless) section to the documentation, incorporating parts of the 'are we headless' website content (Sævar Öfjörð Magnússon, Alex Fulcher)
* Add a new Stimulus `RulesController` (`w-rules`) to support declarative conditional field enabling from other field values in a form (LB (Ben) Johnston)
* Migrate the conditional enabling of fields in the image URL builder view away from ad-hoc jQuery to use the `RulesController` (`w-rules`) approach (LB (Ben) Johnston)
* Enhance the Stimulus `ZoneController` (`w-zone`) to support inactive class and a mechanism to switch the mode based on data within events (Ayaan Qadri)
* Use the Stimulus `ZoneController` (`w-zone`) to remove ad-hoc jQuery for the privacy switch when toggling visibility of private/public elements (Ayaan Qadri)
* Only call `openpyxl` at runtime to improve performance for projects that do not use `ReportView`, `SpreadsheetExportMixin` and `wagtail.contrib.redirects` (Sébastien Corbin)
It's recommended that all projects set the `DATA_UPLOAD_MAX_NUMBER_FIELDS` setting to 10000 or higher.
This specifies the maximum number of fields allowed in a form submission, and it is recommended to increase this from Django's default of 1000, as particularly complex page models can exceed this limit within Wagtail's page editor:
### Form builder - validation of fields with custom `related_name`
On previous releases, form page models (defined through `AbstractEmailForm`, `AbstractForm`, `FormMixin` or `EmailFormMixin`) did not validate form fields where the `related_name` was different to the default value of `form_fields`. As a result, it was possible to create forms with duplicate field names - in this case, only a single field is displayed and captured in the resulting form. As of Wagtail 6.4, validation is now applied on these fields. Existing forms will continue to behave as before and no data will be lost, but editing them will now raise a validation error.
### Background tasks run at end of current transaction
In the default configuration, tasks managed by `django-tasks` (see above) run during the request-response cycle, as before. However, they are now deferred until the current transaction (if any) is committed. If [`ATOMIC_REQUESTS`](inv:django:std:setting#DATABASE-ATOMIC_REQUESTS) is set to `True`, this will be at the end of the request. This may lead to a change of behaviour on views that expect to see the results of these tasks immediately, such as a view that creates a page and then performs a search query to retrieve it. To restore the previous behaviour, set `"ENQUEUE_ON_COMMIT": False` in the `TASKS` setting:
### Added `page` as a third parameter to the `construct_wagtail_userbar` hook
In previous releases, implementations of the [`construct_wagtail_userbar`](construct_wagtail_userbar) hook were expected to accept two arguments, whereas now `page` is passed in as a third argument.
### Changes to `content_panels`, `promote_panels` and `settings_panels` values on base `Page` model
Previously, the `content_panels`, `promote_panels` and `settings_panels` attributes on the base `Page` model were defined as lists of `Panel` instances. These lists now contain instances of `wagtail.models.PanelPlaceholder` instead, which are resolved to `Panel` instances at runtime. Panel definitions that simply extend these lists (such as `content_panels = Page.content_panels + [...]`) are unaffected; however, any logic that inspects these lists (for example, finding a panel in the list to insert a new one immediately after it) will need to be updated to handle the new object types.
The unused JavaScript include `wagtailadmin/js/vendor/rangy-core.js` has been removed from the editor interface, and functions such as `window.rangy.getSelection()` are no longer available. Any code relying on this should now either supply its own copy of the [Rangy library](https://github.com/timdown/rangy), or be migrated to the official [`Document.createRange()`](https://developer.mozilla.org/en-US/docs/Web/API/Range) browser API.
### Deprecation of `window.buildExpandingFormset` global function
The undocumented global function `window.buildExpandingFormset` to attach JavaScript insertion / deletion behavior for Django formsets has been deprecated and will be removed in a future release.
Within the Wagtail admin this only impacts a small set of basic expanding formsets in use across Workflow and Group view editing. `InlinePanel` is not affected.
Previously these expanding formsets required a mix of specific id attribute structures and inline scripts to instantiate with callbacks for handling deletion. User code implementing this functionality through `buildExpandingFormset` should be updated - the following data attributes can be used to emulate the same behavior. These are likely to change and should not be considered official documentation.
