* Update references to `master` branch to say `main`
* Update external links
* Update links in old release notes
Use tagged versions of code rather than current code
Fix code block indentation in tutorial.rst
Prevent it from being displayed as a quote.
Fix indentation in pages.rst
Fix indentation in indexing.rst
Fix indentation in searching.rst
Fix indentation in backends.rst
Fix indentation in renditions.rst
Fix indentation in custom_image_model.rst
Fix indentation in feature_detection.rst
Fix indentation in image_serve_view.rst
Fix indentation in custom_document_model.rst
Fix indentation in i18n.rst
Fix indentation in privacy.rst
Fix indentation in page_editing_interface.rst
Fix indentation in rich_text_internals.rst
Fix indentation in extending_hallo.rst
Fix indentation in configuration.rst
Fix indentation in usage.rst
Fix indentation in theory.rst
Fix indentation in model_reference.rst
Fix indentation in queryset_reference.rst
Configure editors to indent .rst files with 2 spaces
In order for the documentation to be styled correctly, the generator
depends on indentation. Too much indentation can result in the content
being wrapped in a quote block, which looks bad.
Fix indentation in sitemaps.rst
Fix indentation in frontendcache.rst
Fix indentation in routablepage.rst
Fix indentation in table_block.rst
Fix routablepage.rst autodocs disppearing
Fix indentation in table_block.rst
Fix indentation in redirects.rst
Fix indentation in table_documentation-modes.rst
Fix indentation in browser_issues.rst
Fix indentation in release_process.rst
Fix indentation of release notes
One more indent fix in the release notes
Fix indentation warnings
Fix warning about undefined label in docs
Error during `make html`:
wagtail/docs/releases/1.7.rst:25: WARNING: undefined label: jpeg_image_quality
While we very much want to introduce an "explanation" section in some form, I don't think this should be the inaugural item in that section, as it's 'meta' documentation about the Wagtail documentation process, rather than information directed at Wagtail site creators.
These are now returning the correct canonical URL (thanks to a Cloudflare worker script), and letting search engines spider them again will hopefully boost visibility of that canonical URL.
Fixes#5983; possibly also has a bearing on #4306. A CSS rule dating from the original StreamField design was hiding the 'required' asterisk on fields within a required StreamField, presumably on the mistaken belief that they duplicate the information given by the top-level asterisk on the streamfield. (In #5983 this was reported as a regression in 2.7 when the react-streamfield CSS was introduced, so it's possible that the old design had something to mitigate this, e.g. an asterisk being inserted elsewhere.)
This fixes#6393 by modifying the constraint to use an IN condition
which supports both Postgres and SQL Server. Previously, the `|` (OR)
condition was only supported by Postgres because SQL Server only
supports AND conditions.
The implementation follows suggestions from @gasman in
https://github.com/wagtail/wagtail/issues/6393#issuecomment-732161057:
* Migration 0050 is modified to not break on SQL Server
* Added migration 0060 to add or replace the constraint
Additionally, this allows for and documents a `DATABASE_DRIVER` env
variable to be set for testing, to allow a different SQL Server driver
(e.g. FreeTDS on Mac/Linux); and adds the specific `host_is_server`
option for FreeTDS (won't affect SQL Server Native Client on CI).
Facebook and Instagram embeds configuration section should include the default finders for all other providers. It's unclear for someone who just wants to fix his facebook embeds
Same approach as 4023a90d6e for images - define an UploadedDocument model to hold the uploaded file up to the point where the required metadata has been supplied.
Boto3 has been around for a long time now. Adding a Boto-specific parameter in a tutorial is confusing (it was for me) as people are likely to install Boto3 directly and skip Boto. The `AWS_HEADERS` parameter was replaced by the `AWS_S3_OBJECT_PARAMETERS` parameter in Boto3 and the parameter that controls the access control list specifically is the `ACL`.
By the way, are the instructions on line 50 still relevant today?
Signal receivers must accept `**kwargs`, otherwise one runs into this:
```
File "/lib/python3.8/site-packages/django/dispatch/dispatcher.py", line 94, in connect
raise ValueError("Signal receivers must accept keyword arguments (**kwargs).")
ValueError: Signal receivers must accept keyword arguments (**kwargs).
```
This PR adds the 'choose' permission discussed in #4488. It limits Image and Document choosers to showing only those Collections (and their contents) for which the current user has the Choose permission.
It grants Choose permissions to the Root Collection to every existing Group that has the "Can access Wagtail admin" perm, via data migration. So there will be no change in behavior unless the user goes in and alters the Choose perms for their site's groups.
This PR has no effect on anything except choosers. The Image and Document index pages are still controlled solely by the 'add' and 'change' permissions, as those are only accessible by users who have those permissions in the first place. This means that it's now possible to configure a Group to allow its members to choose images from existing Collections when editing pages, *without* them being able to edit said images or add new ones.
It's a really small thing, but I honestly feel like Cynthia did most of the work of taking my workaround to production quality code and pushing it over the finish line. So she should be first here.
... 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.
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
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
* 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.
naglis