These methods are no longer utilized in the codebase and have been superseded by JavaScript-based handling of active menu items. Specifically, the sidebar-menu-item--active class, responsible for theming active menu items via CSS, is now exclusively managed by JavaScript.
Cleaned up the related test from wgatail.admin.tests.tests.py : wagtail.admin.tests.tests.TestMenuItem.test_menuitem_reverse_lazy_url_pass
Fixes#11433
* Allow page types to specify the request methods they support and block unsupported requests in serve()
* Use 'before_serve_page' hook to serve OPTIONS responses
* Add checks to RoutablePageMixin.serve() where the parent implementation is bypassed
* Rename check_http_method to check_request_method and actually use the return value
* Support Python 3.9 through to current approaches for `http` method strings
* Include documentation, docstrings & changelog entry
Fixes#12561
When a ModelForm is constructed without passing an `initial` instance, the result of `StreamField.get_default()` will become the default value of the form field without the intermediate step of being set on a model instance and read back (which would have the side effect of calling `normalize()`). Form rendering only works with normalized values (e.g. StreamValue rather than list-of-tuples for a StreamBlock), so the return value from `get_default()` needs to be normalized.
As made famous by https://youtu.be/v3KEaMTfKg0?t=319 :-)
By design, Wagtail tolerates the default Site record being left at its default value of 'localhost' up to a certain point. Ideally, that point should be when it becomes strictly necessary for Wagtail to care about hostnames (such as when setting up the second site of a multi-site installation) and it should be clear to the developer what has happened and how to fix it.
In practice, that point often comes when the developer deploys their site to production, sets `DEBUG=False`, and is then required by Django to set `ALLOWED_HOSTS` to their real domain name. At this point, front-end page requests work (because the initial site record is default=True, matching any domain including the live one) but previews are broken (because the dummy request object is still formed using localhost as per the site's hostname field, which is disallowed by ALLOWED_HOSTS).
This is unnecessary, and can be avoided by validating the hostname against ALLOWED_HOSTS and substituting one that _is_ allowed if necessary, as we already do for pages that don't have an associated site record.
Return `cleaned_data` for more consistent subclassing.
Updated documentation with an example of adding custom page validation for form fields.
Add unit test to ensure that the documented usage of extending `WagtailAdminFormPageForm` works as expected.
Originally from #10375
This is necessary for rST docs, i.e. in docstrings and in eval-rst
blocks. Without this, Sphinx cannot seem to understand the role. See:
https://stackoverflow.com/questions/13387125
MyST-Parser seems to be smarter, it can figure out these custom
roles without having to register the types ourselves. This is evident in
the previous commits where I already use the :setting: role in markdown
docs.
Some link labels are changed to just the code part, because using Sphinx
roles for code objects (e.g. methods, attributes) would always format the
text as inline code.
It's currently impossible to customize the formatting of a link's text in
rST. See https://stackoverflow.com/questions/4743845
Add more emphasis on the divide between when to use Markdown and when to
use rST.
Also improve examples for versionadded and versionchanged directives.
- Changed style tag, to an external style file
- Also fixed minor spelling mistake "calender" -> "calendar" in line 190
- Avoid inline styles, instead ensure the example shows external style usage
Had to remove the <details> element for the section linking example in
the "Reference links" section.
This is because Sphinx/MyST renders a <section> element for each heading
and closes it when the next heading starts. If we create a heading
inside a <details> element, the <section> element will not be closed
until the next heading starts, which generates invalid HTML.
Also recommend increasing this in the "Integrating into Django" docs.
Fixes#12452
- Don't use commas for thousand separator
- Co-authored-by: Jake Howard <RealOrangeOne@users.noreply.github.com>
Fixes#11938
* Add `wagtail start` to the management commands reference
* Add detail on how to creating templates with the need to escape template syntax by using the verbatim tag
- Move all generic (page/non-page) class references to the top of the documentation
- Use better heading level nesting cleanly isolate the full page report example
- Relates to #12428
- 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
Previously, translations for messages such as "1 page and 3 child pages have been published" were handled with separate branches for the "one parent page" vs "multiple parent pages" cases, to work around ngettext only being able to handle pluralisation for one item in the string. This fails for languages such as Polish where the pluralisation does not follow the straightforward one/many distinction.
Instead, we can translate "N pages" and "N child pages" separately before forming the final message. We generally avoid translating sentence fragments in isolation as this can make things difficult for translators if the sentence structure does not match the English version - but this is hopefully an improvement over the current situation, as well as simplifying the code and reducing repetition.
However, leave behind notes that mark settings/features that are deprecated but not yet removed, as this would be removing information that isn't in the main body of the text (and moving it out of a versionchanged note would make it harder to find when we come to remove it properly in 7.0).
TypedTableBlock did not provide a `get_api_representation` method, so it fell back on returning the database JSON representation as returned by `get_prep_value`. This resulted in an API representation that was mostly usable, but failed to respect child blocks that override `get_api_representation` themselves.
jQuery data is used by the jQuery file upload widget and will automatically parse data attributes as objects/or JS primitive values - see https://api.jquery.com/data/
jquery File Upload will automatically parse the data attributes and treat as the default options for initialisation (already used for the url) - see https://github.com/blueimp/jQuery-File-Upload/wiki/API#data-attributes
- Closes#9771 - avoiding globals for UI specific configs
- Relates to #1288 - ongoing work for CSP compliance
- Avoid using a window global and inline scripts to declare the current bulk action's item time
- Deprecate the usage of `window.wagtailConfig.BULK_ACTION_ITEM_TYPE` with a release note and code comment so that it can be removed in a future release
- Update bulk actions footer template to accept a `item_type` arg, adding this to the DOM element for access within the JavaScript
- Allow a fallback on the model name for core models (e.g. page)
- Also ensure that `{{ block.super }}` is consistently added at the top of the `{% block extra_js %}` (as it is with most usage)
- Relates to #9771 and supports a future migration for bulk actions towards Stimulus
- Relates to ongoing work for CSP compliance #1288
Ensure multi-line comments are cleaned from custom icons in addition to just single line comments.
This doesn't affect Wagtail's, but could reduce the size of 3rd-party icons.
- `js_translation_strings` is no longer used by Wagtail admin code
- It was historically used for generating the JS config strings within templates, we now do this in Python and expose as JSON via the `wagtail_config` template tag
- Add a warning for deprecation so that we can remove this unused template tag in the next major version of Wagtail
- See #9771 for context