- Move model reference to directly under the references section, not the reference/pages section
- Move panel reference to directly under the references section, not the reference/pages section
- Merge panel API with panels reference pages
- Fix confusing heading levels in the page model recipes page
- Fix title in model reference to align with docs style guide
- Adopt US spelling for customize (panels) reference key
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
`BaseLogEntryManager` leaves this unimplemented, and `ModelLogEntryManager` implements it but `PageLogEntryManager` doesn't. The `LogActionRegistry.get_logs_for_instance` method calls this, which means it fails on page models.
Currently this is only used on generic views, which aren't used by page models (unless they're also registered as a snippet, which isn't really a supported setup) but LogActionRegistry is supposed to work transparently across log models, so this is clearly a bug.