- 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).
