... when using the ``WAGTAILIMAGES_IMAGE_MODEL``/``WAGTAILDOCS_DOCUMENT_MODEL`` settings.
We can't really support this as we add new fields and methods to these base classes which all images/documents must support. If we did want to support swapping out the models entirely, every addition we make to the base models could be a breaking change.
* 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>
This change makes several improvements:
* Use in-memory SQLite database for test migrations
The default database is SQLite but its NAME (which SQLite uses as the
filename) was `wagtail`, which isn't valid since
the wagtail codebase already has a `wagtail/` directory. Trying to
run migration creation commands
(https://docs.wagtail.io/en/latest/contributing/developing.html#running-migrations-for-the-test-app-models)
produced an error:
django.db.utils.OperationalError: unable to open database file
because of this conflict.
This change uses an in-memory database as the default database for
tests. If DATABASE_NAME were set to a real file name, then
running the migration command with SQLite creates an empty db with
this filename on running `django-admin`.
Other non-SQLite engines continue to use the original `wagtail` name,
meaning that the `test_wagtail` database gets created just as before.
* Modifies the default values for database USER, PASSWORD, HOST etc to
being an empty string rather than None, to match Django's
[defaults](https://docs.djangoproject.com/en/stable/ref/settings/#host).
This helps avoid any potential issues when Django and database engines
are expecting this being a string.
* Adds documentation to `developing.rst` regarding installation of
required database modules and available environment variables for database
connection customisation
* Normalises the DATABASE_PASSWORD tests environment variable to match
the name in Django's database settings object
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.
Matt Westcott