* Force __str__ of Locale to be a string
* Put some translation proxies in to test settings
* Fixed import in wrong place
* Added test for gettext in LANGUAGES to the Locale model
Co-authored-by: Andreas M <am@zauberberg-medien.de>
Move code from https://www.codista.com/en/blog/wagtail-instagram-new-oembed-api/ into core
Add custom oembed finder for Facebook
Apply suggestions from @originell's code review
Co-authored-by: Luis Nell <luis.nell@codista.com>
FIXUP More places to change the exception name (and a linter fix)
Extend Instagram/Facebook tests to check HTTP request
Add documentation for omitscript parameter
Requesting translations to be nested with each page causes major
performance problems when there are many languages. Mozilla have 61
languages, each with a separate homepage that's a translation of the
others, so the response for this query contains details of 61 * 61 pages
for them.
This isn't actually required since we only need to know the translations
if the user navigates into a page, and the translations are requested
again anyway by the getPageTranslations function.
* Handle get_supported_language_variant returning a language variant not in LANGUAGES
Fixes#6539
* Handle LANGUAGE_CODE that isn't in LANGUAGES
* Release note for #6547
Fixes#6540
There are various code paths where Page.localized and similar can be called even when WAGTAIL_I18N_ENABLED is False, and since it's entirely likely that hand-rolled i18n mechanisms and ad-hoc configuration changes (e.g changing LANGUAGE_CODE) will break the Locale model's assumptions about how things are meant to work, we need to provide sensible fallback behaviour for when the current active locale, or the default locale as per LANGUAGE_CODE, does not have a corresponding Locale record:
* Locale.get_active() will fall back on the default LANGUAGE_CODE locale, or raise Locale.DoesNotExist if that one does not exist either;
* TranslatableMixin.localized (along with Page.localized and Page.localized_draft) will handle a missing Locale record by falling back on the default LANGUAGE_CODE locale, or failing that, returning self.
Fixes#6510 and #6511
Catch the LookupError from get_supported_content_language_variant so that if the active language is not one that is recognised as a content language, the URL prefix will be left unchanged from the page's reported locale.
Additionally, skip the `translation.override` when WAGTAIL_I18N_ENABLED is false; this accounts for the fact that existing sites may have used alternative / custom i18n implementations involving i18n_patterns, and on these sites we can't rely on the page's locale field to be meaningful. That way, we restore the pre-2.11 behaviour: if the existing i18n code was using some kind of wrapper around the get_url_parts call, then that will work again; and if not, the URL will reflect the current active locale, which is no worse than before.
Fixes#6518
If the models.py containing a custom user model directly or indirectly imports wagtail.admin.auth, this causes a circular dependency because wagtail.admin.auth attempts to import django.contrib.auth.views, which in turn depends on the custom user model. Fix this by moving the django.contrib.auth.views import inside reject_request.
Previously, we were only doing this check for existing pages as there
was no way for a new page to be a site root.
But since internationalisation was implemented, new pages can be site
roots if they have a translation that is assigned in a `Site` record's
`root_page` field.
This commit removes a condition in `Page.save()` so `.is_site_root()` is
now called on new pages as well and the cache can get cleared if needed.
Matt Westcott