All other model attribute settings in Wagtail use lists now. This commit changes the api_fields docs to use a list as well.
Both list and tuple work, but list is now the recommended option
Concatinating with settings.STATIC_URL is no longer reccomended for creating
URLs to static resources, because it doesn't take the configured storage engine
into account. For example, a site using S3 to store its static files will need
static URLs that link out to S3, rather than relative URLs within the same
domain.
I replaced it with django.contrib.staticfiles.templatetags.staticfiles.static()
in python example code, and the {% static %} tag in template examples.
Most of the samples were already 4-space indented, but a few were using 2-space,
which is both inconsistent and, when it happened with Python code samples,
incompatible with PEP8.
You get a lexer error from the document builder if you use "code-block:: json",
and the json-style highlighting ends up not being applied. So I switched it to
"code-block:: text".
The "icon-" prefix is automatically added in SettingMenuItem.
Using "icon-placeholder" as suggested would thus result in
the CSS class "icon-icon-placeholder".
Generating links with `link text <./path/to/doc#anchor>`__ does not work for html.
It produces a link to `./path/to/doc#anchor` instead of `./path/to/doc.html#anchor`.
It would be tempting to add `.html` before `#` but would likely cause some more issues
when generating the documentation as pdf or epub.
References on the other hand will work regardless of the output format.
Since the collections infrastructure itself does not know about the object types that
can exist within collections, this requires a new hook `describe_collection_contents`
to allow collection contents to be discovered.
These two tests are used when checking if a new page type can be created
under a page instance, or if an existing page type can move under a page
instance.
Iterating over get_page_models means that these will be visited once
per superclass. To avoid this, we filter the page list to those exactly
matching the page class. This is done via a new `exact_type` method
on `PageQuerySet`.
The `wagtailsettings` module is useful enough that it should be included
in the Wagtail contrib section, to make it available to all Wagtail
developers.
All the code has been given a once-over to make sure it is nice and
polished before being copied in. As such, this is not a direct copy of
the `wagtailsettings` module. It should be backwards compatible though,
excepting the new location.
It has been moved to `wagtail.contrib.settings`, following the naming
scheme set out in #1504.
Documentation has been concatenated in to a single page, and added to
the contrib reference section.
All `.. code::` instances have been changed to use `.. code-block::`,
and have been properly formatted. The syntax names have been normalised,
so all django templates use the `html+django` syntax, shell commands use
`sh`, and plain text uses `text`.
`is_creatable` better reflects what it is used for, and stops any
confusion between Wagtail's `is_abstract` and Django's `Meta.abstract`.
`is_creatable` takes in to account `Meta.abstract` now, so developers
will no longer need to set both `is_abstract` and `Meta.abstract`.
Documentation for the new attribute has been added, as well as tests.
These were introduced in 9d7d016b7c to support menu item highlighting, but this mechanism was superseded by #1186. There's no sign of any code still using these classnames, and any code that relies on them would be liable to fail on non-English-language sites anyhow (since the menu item name is derived from the label by default, and the label is a translatable string).
