RoutablePageMixin has a default index_route method that is decorated
with `@route(r'^$')`. This way, including RoutablePageMixin doesn't
force you to re-enable the default functionality you would expect from a
Page anyways.
index_route behaves exactly like a standard Wagtail Page.
To override the default behaviour, one can simply override the route by
decorating another function with r'^$'.
(as disussed in issue #2866)
We have to run python manage.py migrate once, in order to create the necessary tables for the postgres search backend.
Otherwise we get an error, as the insert in the table is not possible.
* Adds PostgreSQL search backend.
* Isort nitpicks.
* Fixes PostgreSQL versions incompatibilities.
* Uses Django lru_cache instead of building our own.
* Fixes PostgreSQL search index on some empty vector & query cases.
* Never sets the PostgreSQL search vector to NULL.
* Simplification + removes caching on two fast enough functions.
* Rewrites stale entries deletion to use the ORM.
* Split `helpers.py` into separate `url.py`, `permission.py` and `button.py`, dedicated to those separate concerns and update the docs accordingly
* Move `ThumbnailMixin` out to `mixins.py` and update documentation accordingly
* Ad #NOQA to import lines to hush pep errors
* Alphabetise helper import order
* - Delete `helpers/helpers.py`
- wagtal -> wagtail in docs
- Remove imports at the top of options.py and views.py that result in ImportError when those apps aren’t installed
- Alter ThumbnailMixin and InspectView to use the `wagtail.wagtailimages.shortcuts.get_rendition_or_not_found()` method to render images, which handles missing image source files gracefully, and reduces code duplication.
- Simplify `get_field_display_value()` by not limiting image and document rendering to ForeignKey fields. It should work consistently for property methods or other attributes too.
Stylistically this sentence is somewhat content-free (if the API is really "relatively straightforward", users can see that for themselves rather than us informing them of that fact...), and we don't want to encourage people to use undocumented methods (because we can't guarantee that the API for them will remain stable).
This is the correct lexer for interactive console sessions, according to
<http://pygments.org/docs/lexers/>. This does require command lines to
be prefixed with `$`, otherwise they are interpreted as the output of a
command. It highlights the command nicely, including environment
variables, strings, and comments.
* `result_row_display` adds a `data-object_pk` attribute to each row, to make items easier to identify with JS
* Adds `get_extra_attrs_for_row()` method to `ModelAdmin`, to give developers a way of adding further attributes to the `<tr>` element
* added base cloudfrontbackend and testcase
* added boto3 cloudfront client
* implemented create invalidation method
added error handling botocore
* added aws docs
* fixed typo
* flake8 fixes
* added boto3 configuration docs
* removed return
* purge path instead of full url
* added multisite hostname mapping
* added validation of DISTRIBUTION_ID
* renamed Cloudfront to CloudFront
* added note to include www in mapping
added tests for cloudfront site mapping
* removed deprecated has_key, used in
fixed _create_invalidation
* changed type checking of dict
removed debug line of code to check hostname
* fixed dict type checking condition
added assert t make sure no invalid cache is being purged
* changed import order
* fixed isort error
* more detailed error message for cloudfront
pep8 fixes 120 chars per line
* Log missing cloudfront distribution id as info
Was logging as error, but it may be possible that a developer wants cloudfront on only specific hostnames.
* , => .
* Docs edits
* Removed hard-dependency on boto3
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).
