This (hopefully) fully replicates the old behaviour of stream_data, returning raw JSON data for lazy StreamValues and the tuple representation for non-lazy values.
It seems quite likely that the lack of nice representations for these in the shell / debugger is what stopped people from realising that they could index StreamValue as an array, and led them towards stream_data instead ("ooh, this looks like an array of data... I know how to deal with this")
This matches the old behaviour of stream_data for lazy StreamValues. Given that a lazy StreamValue is what you get as standard when retrieving a model instance from the database (or from a PageRevision), any existing user code that casually tinkered with stream_data unaware of the lazy versus non-lazy gotcha is almost certainly expecting it to behave this way - therefore in 99% of cases those users should be able to replace `stream_data` with `raw_data` and have their code work as before, with the added bonus that it won't fall over on page previews (which get their data from a form submission in Python format rather than JSON, and are thus NOT lazy).
Since stream_data existed in lazy (JSONish dicts) and non-lazy (tuples containing native values) variants, retrieval and serialisation each required two separate code paths. We now have a single representation, consisting of the raw JSONish data in _raw_data (unused if we were initialised with native data) and a cache of StreamChild objects in _bound_blocks (prefilled if we were initialised with native data).
Make sure document chooser pagination preserves the selected collection when moving between pages
Co-authored-by: Alexander Sajzew <a.sajzew@alexsa.de>
Co-authored-by: Thibaud Colas <thibaudcolas@gmail.com>
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.
Matt Westcott