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.
- 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...)
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.
Karl Hobley