If validation rules prevent the multiple image upload view from
creating Image objects from just the image file, an UploadedImage object is
created instead, and turned into an image once the form is filled in.
* Fixes #847
* Add UploadedImage model and related views
* Update custom image model docs
According to the ARIA spec:
> A region that contains mostly site-oriented content, rather than page-specific content.
> Site-oriented content typically includes things such as the logo or identity of the site sponsor, and a site-specific search tool. A banner usually appears at the top of the page and typically spans the full width.
Where the `banner` role was applied was more page-specific than
site-specific. In addition, tags with `banner` roles should not live
under another landmark. To rectify, removed the misused banner roles.
Remove inappropriate contentinfo landmarks
According to ARIA spec 1.1
> A large perceivable region that contains information about the parent document.
> Examples of information included in this region of the page are copyrights and links to privacy statements.
They don't apply to the action buttons on where this was applied to.
Add main landmark to 404 page
- fixes #5099
- test_copy_page_with_excluded_parental_and_child_relations
- ensure the tests are wrapped in a try/finally so that the model is always reset back even if tests fail
- update page model tests
Fixes wagtail/wagtail#5937
This reverts Wagtail's behaviour to match Django's, where an error is
raised as a safety mechanism.
Projects relying on the non-safe behaviour should update e.g.
`MyModel.objects.delete()` to `MyModel.objects.all().delete()`.
Currently a select set of StreamField blocks like PageChooserBlock
expose a bulk_to_python method that is used to optimize their
retrieval from the database. As reported in issue 5926, ListBlock could
take advantage of this so that its child items are loaded at once,
instead of one at a time.
This change modifies how ListBlock.to_python works so that it calls its
child block's bulk_to_python, if defined. This allows for a single query
instead of one query per child item.
Note that this change doesn't add bulk_to_python to ListBlock itself,
meaning that individual ListBlocks in a StreamField or StructBlock are
still retrieved independently. But it does optimize the lookup for each
ListBlock.
Image operations sometimes calculate a target width or height of zero, which
make Willow raise a ValueError.
If an user uploads one such image it's possible to break the whole Wagtail
image manager/picker/uploader for all users.
The fix is to use a minimum of 1 pixel for either the target height or the
width. The image might lose some aspect ratio, but it's better than an
exception.
Building the docs currently generates a warning:
wagtail/docs/reference/contrib/modeladmin/indexview.rst:423: WARNING: Could not lex literal_block as "python". Highlighting skipped.
This is due to use of backticks instead of single quotes on this page:
https://docs.wagtail.io/en/v2.8/reference/contrib/modeladmin/indexview.html#modeladmin-get-queryset
In practice this doesn't seem to actually break highlighting, but it's still good to fix.
* Implement MultipleChoiceBlock (squashed commits from #5592)
* Omit widget from frozen kwargs
* Rename get_callable_choices to indicate it is an internal method
* Add release notes for MultipleChoiceBlock
* Add to Dashboard docs
* Replace Dashboard image to show locked pages
* Add further explanatory text to Dashboard
* Improve image readability, add missing bracket
Co-authored-by: jacobtoppm <55137073+jacobtoppm@users.noreply.github.com>
The CHANGELOG docs say that contributor names should only be included if
they are not a core committer, but historical practice has been to
always include names. Per discussion on the core team, we want to change
this guidance to explicitly recommend always including contributor
names.
This not only encourages and recognizes contributions but also helps
future contributors know who worked on different parts of the code. This
record (along with git history) provides a good reference to understand
who made certain changes or features.
Currently it is possible to pass the target attribute to a button
created using ModelAdmin's ButtonHelper framework. This allows you to
generate button links like <a ... target="_blank">.
For example, if adding a new button and modeling it after the existing
edit_button code [0], you can add {'target': "_blank"} to the returned
dict and it'll get passed to the template when the button is rendered.
To be consistent with PR 4844, and to be consistent with what seems to
be the best practice ([1], [2]), we should also support passing the rel
attribute, which would allow for creation of button links like <a ...
target="_blank" rel="noopener noreferrer">.
[0] 5e2f50403b/wagtail/contrib/modeladmin/helpers/button.py (L61-L73)
[1] https://developers.google.com/web/tools/lighthouse/audits/noopener
[2] https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/
The order of nested InlinePanels (recently formally added in 5566)
doesn't get saved properly due to some now-invalid assumptions in the JS
selector code.
Currently, Wagtail users can use the editor up/down arrows to order
InlinePanel elements that contain child InlinePanels, but these may not
be properly saved.
Before InlinePanel nesting was supported, it was a safer bet that a
child panel would only contain one hidden input named "-ORDER". With
nesting, however, a parent panel will also contain hidden inputs named
like this for its child panels. This breaks the logic used in the
ordering code.
This change modifies the logic to use the jQuery `.children()` selector
instead of `.next()`, ensuring that we reference the correct adjacent
panel item.
An easy way to test this against current master is to use the Wagtail
testapp test models that exercise this behavior:
1. `wagtail start testwagtail` to create a new project.
2. `cd testwagtail`
3. Edit testwagtail/settings/base.py to add the Wagtail test
application `'wagtail.tests.testapp'` to the list of `INSTALLED_APPS`.
For the admin to work properly with this app, you also need to add
`'wagtail.contrib.settings'` to that list and copy the definition of
`WAGTAILADMIN_RICH_TEXT_EDITORS` from wagtail/tests/settings.py.
4. `./manage.py migrate` to create your local database.
5. `./manage.py createsuperuser` to create an admin user.
6. Create a new Event Page
(http://localhost:8000/admin/pages/add/tests/eventpage/3/).
7. Fill in all required items, and then add multiple speakers under
"Speaker Lineup". For each speaker, add at least one Award. Save the
page.
8. Try using the up/down arrows to reorder the speakers (the parent
InlinePanel), and save the page.
9. Note that when the page reloads, the ordering hasn't been saved. If
you debug using the developer tools, you'll notice that this is because
the code being modified here selects the child panel items instead of
the adjacent parent panel item.
The `wagtail_urls` patterns is a catch-all list of urlpatterns, and will
prevent any patterns later in the list from being matched. The default
case when Django is in debug mode for local development is to use
`django-admin.py runserver`, and in this case the static patterns in the
example [are redundant][1]. However for anyone using a different server
for local development, this makes them work again.
[1]: https://docs.djangoproject.com/en/3.0/howto/static-files/#serving-static-files-during-development
Trying to compare revisions of a page that includes changes to a foreign key
field of a related model that declared a custom primary key failed with an
uncaught exception.
The root cause was ForeignObjectComparison filtering by the id field, which is
not present in models that declare a custom primary key.
The solution is simply to filter by pk instead of id, which always maps to the
primary key of the corresponding model.
Include a regression unit test.
* Add Recipe doc for implementing AMP on a site
* Fix typos
* Add section on using a different page template for AMP
* Move AMP recipe out of images
Not very image specific anymore
* Wording tweaks and grammar fixes
- items longer then the page height are no longer broken by the submenu footer
- long lists of submenu items are no longer blocked by the footer (version number)
Other changes
- documents listing template - clean up white space
Documentation changes (editors manual)
- update images
- remove popular tags mention as this is no longer applicable
- add references to 'collection'
Resolves #2827
* note Python 3.8 support as provisional
* Remove mentions of minor doc fixes (there are many more fixes beyond the ones mentioned here, and including them all in the release notes would add too much noise...)
As per #5620 - signals are often overlooked as a way of customising model-level behaviour. We should recommend them over admin hooks where possible, as they aren't reliant on users taking one particular path through the admin - for example, an 'add document' signal will be triggered regardless of whether a document is created through the single uploader, multiple uploader, chooser model or a scripted task, whereas a hook would not catch all of these cases.
Fixes #5539. Transifex and Django's makemessages command have validation to catch invalid placeholder variables within translated strings - for example, where the translator has translated the variable name - but these only recognise old-style `%` formatting, not the `format` method, and so it's better for us to standardise on % formatting.
To reduce the burden on translators having to re-translate these strings, only the ones using named placeholders (`"Edited page {title}"`) rather than numeric ones (`"Edited page {0}"`) have been changed - hopefully the latter give less room for error.
Also fixed some incorrect use of plurals (verbose_name vs verbose_name_plural) in snippet confirmation messages.
- Typo in readme (verb did not agree with the subject)
- Grammatical error in topics/pages
- #5364 - Update URL config code block in getting-started/integrating-into-django
Work on compatibility is ongoing while Django 3.0 is still in development; we don't want this to be misinterpreted as a statement of formal Django 3.0 support (which we can't promise until the final release)
As per https://twitter.com/SaraSoueidan/status/1177622630763028480, certain browsers apply heuristics to decide whether `<table>` elements exist for layout or data purposes, and adjust the behaviour of their accessibility features accordingly. Given that TableBlock intentionally doesn't allow markup within cells, we can be reasonably sure that any tables created with it are genuine data tables, and should therefore indicate that using `role="table"`.
Fixes #5442. Building a User object for david@torchbox.com may cause problems if a custom user model is in use, and is redundant anyhow because there's no longer a registered gravatar for that email - we should just hard-code the default blank avatar instead.
