Doing so would mean the "models" module of the app that contains the
custom user model will be used in favour of the models module of the
wagtail.users app, which contains the UserProfile model. As a result,
the UserProfile model becomes mistakenly picked up by the wagtailcore
app, creating a bogus migration when makemigrations is run.
This partially reverts the docs to the version before
449a48d7f9, in particular the paragraphs
about creating the custom AppConfig subclass for wagtail.users.
This text existed since Wagtail 1.x and is referring to the original database backend that just did substring matches (which is now the fallback backend), before we supported database-backed full-text search.
In 5a8c33f34a the minimum version was set to 7.3 to allow use of the long-form `--fail-on-warning` option, but this is not compatible with Python 3.8. Revert this to the original `-W` option and set 7.0 as the minimum version.
Also deprecate the `window.ActivateWorkflowActionsForDashboard` and
`window.ActivateWorkflowActionsForEditView` functions as they no longer
need to be globally-accessible
This speeds up application startup. The hash is now a query param, injected in the template. As this param is only needed for cache invalidation, it's optional. A helper method is provided to generate the URL, along with a template tag.
This also migrates to an `lru_cache` over a global variable for simplicity.
Fixes#11680
Added back a line that was removed in a previous commit,"rendition.file.open("rb")" in serve.py.
Also, created a test in admin/tests/viewsets , test_image_presence.py that confirms that
the issue has been resolved. The test looks for a status error code 500 in the display of an image,
something that happenned when the dynamic serve view failed. If it finds it, the test fails.
The test also passes when we dont't use a dynamic serve view.
Co-authored-by: SebCorbin <sebastien@rgoods.com>
Django provides an `HttpRequest.resolver_match` attribute [0] that
allows downstream code to inspect a request object to see how its URL
was resolved to a view.
Wagtail's RoutablePageMixin does its own sub-URL routing to call
different view functions on a page object, but the resolver result isn't
similarly made available.
This commit sets a new `routable_resolver_match` attribute on the
request object, akin to Django's `resolver_match`, that stores this
sub-URL routing information for downstream use.
Documentation has been updated appropriately (along with a couple of
other minor broken things in the RoutablePageMixin docs).
[0] https://docs.djangoproject.com/en/5.0/ref/request-response/#django.http.HttpRequest.resolver_match