- apply general fixes to existing markdown documentation
- various cases of rst syntax still used
- update some links to be the new format
- clean up line breaks (prettier)
- Postgres does not provide true control the search ranking using the database search backend.
- Postgres only supports four weight levels and this should be clarified in the documentation
Relates to #8383
* Convert the image tag topic to Markdown
* Convert the permissions usage to Markdown
* Convert the topic of snippets to Markdown
* Convert the streamfield topic to markdown
* Convert the writing templates doc to Markdown
I have just tried to follow the original instructions and got an `AttributeError: 'str' object has no attribute 'source'` when trying to append a rich text block to a `StreamField` programmatically.
Wrapping the value in a `RichText` object solved the issue. This seems to be in line with the behavior described further down the page.
This argument should be used on all new StreamFields created under Wagtail 3. It does add some clutter to the examples, but only using it in select cases would create more confusion...
As per discussion on https://github.com/wagtail/wagtail/discussions/7732, the changes in the upcoming release (sidebar redesign, removal of hallo.js, module reorganisation) warrant a version bump to 3.0 if we're following semantic versioning.
Add system check for use_json_field in StreamField
Change system check level to Warning
Add use_json_field argument to StreamField in test models
Use RemovedInWagtail219Warning instead of a system check
Handle unpacked values in to_python when use_json_field is True
Duplicate models and tests for JSONField-based StreamField
Add basic tests for JSONField-based StreamField
Add json_field property in StreamField to unify JSONField usage
Add docs
Don't use destructuring for kwargs in deconstruct
Add versionchanged note to StreamField reference
Currently Wagtail defines `request.is_preview` as a way for both page
rendering and template rendering to modify logic based on whether the
page is being previewed.
If a page supports multiple preview modes, though, the information about
which mode is being previewed isn't made available. So, for example,
it's not possible to customize `Page.serve` or `Page.get_context` based
on a different preview mode. Or, consider customizing
`Page.get_template` so that it uses a different page template depending
on the mode being previewed.
This commit adds `request.preview_mode` so that the mode is available
downstream of previews, both in the page rendering logic and also in the
template itself.
A minor documentation change mentions this new property.
The "Page models" documentation page in the Wagtail usage guide has
several broken links (see current page at
https://docs.wagtail.io/en/stable/topics/pages.html).
These links work when developing the documentation locally, but not when
served on ReadTheDocs (docs.wagtail.io)
The broken links are all of the form /some/page.html#anchor - somehow
this format doesn't translate properly to get the necessary RTD prefix
(for example /en/stable/).
I've modified these links to use RST references, which will also make
them more robust to future changes.
Documentation examples of `Page.get_context` and `Page.get_template`
lack `*args` and `**kwargs` parameters (which were added way back in
8c4c268641).
This commit adds those missing parameters.
This replaces several US English dialectical uses of _regular_ with
British English equivalents _normal_ or _standard_. This is the result
of a search of the docs for the string 'regular', rather than due to any
US English seen in the user interface.
This search also found one use of _regularly_ where _often_ was closer
to the intended meaning, a change which is less about dialect than about
word choice.
This prevents duplicated headings in places where the second-level index page has intro blurbs for each subsection (and also means we're not listing out long multi-section pages in full in the index, but given how big these indexes are that's probably not a bad thing).
"How to use StreamField" is a pretty useless title unless you already know what StreamField is, in which case you don't need the howto... I'll go with "How to use StreamField for mixed content" so that it's at least vaguely result-focused (while still keeping "how to" and "StreamField" as keywords).
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
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.
The current text still mentions the rich-text class (which is now formally deprecated) alongside responsive-object (which is not deprecated, but off by default). Split up the CSS snippet to make it clear that these are two distinct cases, and eliminate use of rich-text.
Page.context_object_name can be used to define a more meaningful name
for the page variable in the template.
If defined, the default `page` and `self` are still available for use in
shared templates.
Resolves#5213
* Implement MultipleChoiceBlock (squashed commits from #5592)
* Omit widget from frozen kwargs
* Rename get_callable_choices to indicate it is an internal method
* Add release notes for MultipleChoiceBlock
- 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
Fix doc and test on ES6 python client compat
This commit changes the statement that version < 6.3.1 of the
elasticsearch python client should be used to instead state
that 6.4.0 is fine.
It also update the tests to reflect the statement.
Initially the `update_all_types` argument has been used to work
around an issue described in:
https://github.com/wagtail/wagtail/issues/2968
This argument was removed in elasticsearch-py 6.3.1 and making
use of it was raising an error.
With 6.4.0 nothing is raising anymore.
This generated block of code needs to stay or else there will be an error while running ./manage.py migrate. It is misleading that it is not included in this tutorial.
LB Johnston