|
@@ -11,6 +11,20 @@ depth: 1
|
|
|
|
|
|
## What's new
|
|
|
|
|
|
+### 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)
|
|
|
+ * Calculating [image focal points](image_focal_points)
|
|
|
+ * Purging [frontend caching](frontend_cache_purging) URLs
|
|
|
+ * 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.
|
|
|
+
|
|
|
+This feature was developed by Jake Howard.
|
|
|
+
|
|
|
### Other features
|
|
|
|
|
|
* Add search terms report (Noah van der Meer, Sage Abdullah)
|
|
@@ -160,6 +174,20 @@ DATA_UPLOAD_MAX_NUMBER_FIELDS = 10_000
|
|
|
|
|
|
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:
|
|
|
+
|
|
|
+```python
|
|
|
+# settings.py
|
|
|
+TASKS = {
|
|
|
+ "default": {
|
|
|
+ "BACKEND": "django_tasks.backends.immediate.ImmediateBackend",
|
|
|
+ "ENQUEUE_ON_COMMIT": False,
|
|
|
+ }
|
|
|
+}
|
|
|
+```
|
|
|
+
|
|
|
## Upgrade considerations - deprecation of old functionality
|
|
|
|
|
|
## Upgrade considerations - changes affecting Wagtail customizations
|