Django-1.10-style middleware inherently doesn't support applying middleware to the request independently of running the view function, as the design of dummy_request requires. The current implementation of dummy_request unwittingly works around this by running the entire request/response cycle on the page's live URL (regardless of whether the page actually exists there at that moment), throwing away the response, and returning the request object to be used a second time (at which point it will be hopefully be populated with middleware-supplied attributes such as request.user and request.site - unless something caused the middleware to abort).
The new make_preview_request method wraps the call to serve_preview inside the middleware processing, so there is no longer a bogus 'background' request and no response has to be thrown away (meaning that any response returned by middleware will be correctly returned).
Fixes#3546
Responses returned by middleware (e.g. authentication failure) while creating the dummy request for a page preview. However, the current (broken) behaviour is to ignore the response, and attempt to serve the preview using the resulting request - which is likely to have incompletely-applied middleware, leading to hard-to-debug issues (usually involving a missing request.site).
Resolves "DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working" - see #5484
Modeladmin handles notification to the user if a model instance has protected ForeignKey
relationships. However, if the protected relation is a OneToOneField it raises an exception:
File ".../wagtail/wagtail/contrib/modeladmin/views.py", line 742, in post
for obj in qs.all():
AttributeError: 'MyRelatedModel' object has no attribute 'all'
because qs in this case is the related instance rather than a queryset of related instances
(as is the case for a ForeignKey).
This commit handles the OneToOneField case as well.
User interaction with the form within the 10s delay also won’t trigger the confirmation message. There will still be race condition issues if form widgets like rich text take 10+ seconds to initialise – but that doesn’t seem likely.
This hook mimics the functiolity provided by `construct_page_action_menu`
in that it constructs the final list of buttons to be shown in the wagtail
admin interface. This means that within this function button's can be
removed, added or re-ordered.
See #4925
Recent builds have been breaking due to the following error: `/post_build.sh: line 2: npm: command not found`. I’m not entirely sure this is the fix, but it looks like this `latest` tag is now resolving to `3.7.4-buster` (https://hub.docker.com/_/python). Debian Buster got released 2 weeks ago. It feels safer to have a pinned dependency, and Stretch is probably what it was resolving to before.
Testing the queryset in the if clause was causing the whole queryset
to be retrieved and populated from DB, all to check whether it was empty
or not.
The optimization is to rely on the strict behavior of
first_common_ancestor, which raises an exception if the queryset is
empty.
The USERNAME_FIELD exists to allow customisation. Therefore we should make an assumption that `.username` exists on the model. Instead, we need to pull the required value from the USERNAME_FIELD and add in a fallback default.
