* Created Elasticsearch 2 backend
* Added tests for Elasticsearch 2 backend
* Split models up into different indices
pages, images and documents are now in separate indices
* Prefix fields of child models to prevent mapping clashes
* Replaced index_analyzer with analyzer/search_analyzer
index_analyzer has been removed in Elasticsearch 2.0
https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking_20_mapping_changes.html#_analyzer_mappings
There's no indication in Elasticsearch's docs that this wouldn't work on Elasticsearch 1.x. However, we found that the new configuration isn't reliable on Elasticsearch 1.6 and below (causes the test_query_analyzer test to fail randomly).
* Implemented new way of representing content types in search index
Instead of using a long string of model names that is queried using a
"prefix" query, we instead use a multi-value string field and query it
using a simple "match" query.
The only reason why this isn't implemented in the Elasticsearch 1.x
backend yet is backwards compatibility
* Added another child model of SearchTest with clashing field mapping
This checks that the namespacing of fields on child models is working properly (if it doesn't the update_index tests will fail)
* Added tests for get_model_root function
* fixup! Added tests for get_model_root function
* Docs updates for Elasticsearch 2 support
Also tweak examples to use elasticsearch2 backend by default
* Test against Elasticsearch 2 on travis
* 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
* Ship our own copies of urlify.js and xregexp.min.js
This avoids issues with missing files when using Django 1.8 or omitting django.contrib.admin from INSTALLED_APPS (#2927), and guards against any breaking changes to these files in future Django releases.
* Add a WAGTAIL_ALLOW_UNICODE_SLUGS setting
Django's standard behaviour is to preserve managers that are set on abstract
superclasses, so this allows us to eliminate the metaclass hackery.
Fixes#2933
It should be max and min value - not length. See [here](07c3ba84fb/wagtail/wagtailcore/blocks/field_block.py (L306)).
So this would work
`blocks.IntegerBlock(max_value=10, min_value=0)`
but this wouldn't do anything
`blocks.IntegerBlock(max_length=10, min_length=0)`
This is where developers expect it to be, similar to Django and other
projects. The version info still exists at the old `wagtail.wagtailcore`
location, for backwards compatibility.
Fixes#2557
Client-side validation fails on forms with prefilled file upload fields -
see https://code.djangoproject.com/ticket/27037. This is fixed in Django 1.10.1,
so as a workaround we disable client-side validation (using the 'novalidate'
attribute) for forms with enctype="multipart/form-data" on Django 1.10 only.
Fixes#2897
When building a dummy request, you can now pass in the original request object
to add additional information to the dummy. Currently, that includes the
following headers:
REMOTE_ADDR
HTTP_X_FORWARDED_FOR
HTTP_COOKIE
HTTP_USER_AGENT
More may be added later.
This changes ensures that middleware which work on the client IP aren't flumuxed
by its absense, and also makes it possible for previews to be rendered as the
logged in user (they had previously been rendered using an AnnonymousUser).
Because the user's logged in state is now detectable in a Page previews, the
Wagtail userbar now hides itself explicitly during previews, rather than relying
on the fact that previews used to be built with AnonymousUser.
As mentioned in the comments I didn't see the first pull request (https://github.com/torchbox/wagtail/pull/2509)
However, I think my changes were a tiny bit more complete in terms of UI/UX. I allow to delete a user directly from the user list + you can delete any user if you are superuser, except yourself. This way we are sure to keep at least one superuser but we can still delete superusers.
I added some tests from this PR to my code and also added the permission denied on the delete page.
Update render and render_basic methods on Block to take a context kwarg
Update TableBlock to support passing extra context to render
Implement render_as_block on BoundBlock, StreamValue and StructValue.
Collectively, these are the objects encountered during template rendering which typically render
a block template when output inside {{ ... }} tags. Implementing render_as_block allows us to do
the same thing, but passing a template context as well.
Implement include_block tag
Support extra context vars on include_block via 'with foo=bar'
Support 'only' flag on include_block tag, to omit the parent context
Update StreamField documentation to cover the include_block tag
Rewrite 'BoundBlocks and values' docs based on the include_block tag
Add tests for blocks with legacy render / render_basic methods
Any bits of StreamField infrastructure that attempt to call render or render_basic
on a block with a 'context' kwarg, should (for now) also work on blocks that don't
accept the context kwarg, but output a RemovedInWagtail18Warning.
Explicitly test whether render / render_basic will accept a 'context' kwarg
This avoids unexpected behaviour when the method legitimately accepts a context
kwarg, but happens to throw an unrelated TypeError - in this situation, the final
output (or error diagnostics) will behave as if the context was never passed,
making debugging difficult. See https://github.com/torchbox/wagtail/pull/2786#discussion_r69563984
The `form_template` attribute was mentioned in passing in the docs, but was missing various things
to make it fully useful:
- context passed to form_template now includes 'prefix' and 'block_definition'
- context for the form is now populated in a separate overrideable `get_form_context` method
- full documentation and tests for form_template and get_form_context added
The individual `error_message` kwarg on RegexField is deprecated in Django 1.8
(and removed in Django 1.10), so it's appropriate for RegexBlock to follow the
same convention.
Form media declarations are output in edit.html, but this is redundant as they're already output in _editor_css.html / _editor_js.html,
and the duplicate definitions cause the rich text editor to fail to activate for some reason.
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
When decorate_urlpatterns apply a decorator to a view function it lost spec names, docs, and the module where it was imported, making it uneasy to inspect when debugging (Like getting the name view and docs when using django-debug-toolbar)
Using functools.update_wrapper it updates the resulting function to look like the original wrapped view function.
Without the use of this decorator factory, the name of the wrapped view function would have been 'decorated_view'.
If the developer had overridden MESSAGE_TAGS in their site, Wagtail
messages used these classes in the admin. This caused the messages to
lose their styles.
Wagtail now ignores the MESSAGE_TAGS setting, using the default classes
defined in `django.contrib.messages.constants.LEVEL_TAGS`.
Fixes#2551
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".
Switching explorer from position absolute to position fixed.
I did it in a pure CSS way but it would be good to be able to modify jquery.dlmenu.js line 213 to avoid it adding automatically a CSS property top on the element.
Make collection field on document chooser upload respect user permissions
failing test for #2511 for image uploader
Make collection field on image chooser upload respect user permissions
The "icon-" prefix is automatically added in SettingMenuItem.
Using "icon-placeholder" as suggested would thus result in
the CSS class "icon-icon-placeholder".
Making developers opt out of extra security is better than making them
opt in, especially when they may not be aware of the security they are
missing out on.
Fixes#2369
The static() function was being called during app load which caused a crash when the user is using STATICFILES_STORAGE=ManifestStaticFilesStorage, DEBUG=False and haven't yet collected static files.
I've moved it into a property and it's now only called when a view is being rendered. This also is more consistent because we usually set media using properties (and so does Django admin).
In Django 1.9+ if you do not add: 'builtins': ['overextends.templatetags.overextends_tags'], to your TEMPLATES section you will receive a TemplateSyntaxError when the overextends template files are rendered: "Invalid block tag on line". Including 'builtins': ['overextends.templatetags.overextends_tags'], per the overextends docs (and experience) resolves this error.
https://github.com/stephenmcd/django-overextends
Indexed.search_fields used to be a tuple. This is incorrect, and it
should have been a list. Changing it to be a list now would be a
backwards incompatible change, as people do
search_fields = Page.search_fields + (
SearchField('body')
)
Adding a tuple to the end of a list causes an error, so this would
cause all old code that used tuples to throw an error. This is not
great.
A new ThisShouldBeAList class, which subclasses list, has been added.
It additionally allows tuples to be added to it, as in the above
behaviour, but will raise a deprecation warning if someone does this.
Old code that uses tuples will continue to work, but raise a deprecation
warning.
See #2310
This is accomplished by using PasswordChangeForm instead of SetPasswordForm.
This adds extra security, as without this commit, an attacker that has access to
a user's session at one point in time will be able to change the user's password
and gain permanent access.
This more reliably ensures that the user has up-to-date dependencies (e.g. without it, a
beta version of a package like Willow or modelcluster won't get installed if the user has
a stable version already installed)
The raw html which can be found on the repository states:
Update 08/09/2015: This tutorial has been written during the first days of Wagtail, when documentation and tutorials about it were sparce; right now it should be considered by all accounts obsolete and not be followed! Instead, you should read the official (and very well written) tutorial in the official Wagtail documentation!
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.
The construct_homepage_summary_items hook allows to add items, but if
you use exactly the same markup as wagtail you end up with a bad layout
because the items form rows with no whitespace between them.
This commit changes the padding-bottom of the section into a margin-bottom
of it's <li> items, meaning that they form rows with enough whitespace
in between them, and the whitespace at the bottom is preserved.
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.
- keep ordering and pagination as two distinct operations
- only perform the 'annotate' hack when ordering by latest_revision_created_at
- entries with a null latest_revision_created_at should appear at the top when
ordering oldest first
- don't uselessly call order_by twice
- actually test that the 'ordering' parameter orders the results :-)
* Removed requirements-dev.txt
* Added dependencies to setup.py using the extras_require option
* Updated the documentation to use pip instead of setup.py develop
* Updated .drone.yml to reflect updated installation
On SQLite, not all moderators would receive a notification.
On Postgres, a “more than one row returned by a subquery used as an
expression” error was thrown.
I think the words "Wagtail site" implies that Wagtail sites are a thing when they are in fact just Django projects with Wagtail installed.
So I think "Using Wagtail" is less likely to cause confusion.
tagit was initialized from both the AdminTagWidget, and from the `done`
method in the image uploader. Initializing it twice led to strange
errors and ultimately the tags not being saved on the image model.
As the tag widget now contains its own initialisation <script>, tag
inputs do not need to be specially handled by AJAX code any more, so
this can simply be removed.
Fixes#2142
If the Wagtail install has only one site, link to the homepage of that
site from the dashboard page summary instead of the root page of the
hierarchy.
Hopefully this will prevent some of the confusion causing people to
create pages under the root page, where they are inaccessible. See #1612
for more information around this issue.
Wagtail installs with multiple (or zero) sites retain the old behaviour
of linking to the root page.
Previously, if a developer wanted to use a custom Manager on their Page
subclass, some fairly hacky hacks were required. Now, the `objects`
attribute is only overridden if it is a plain `Manager`. If it is
anything else, it is left alone. A system check has been added to ensure
that all `Page` managers inherit from `PageManager`
Django 1.9 requires this line before importing any models. Autodoc
imported models to get their docstrings, causing errors in the build
process.
Fixes#2014.
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 SiteManager class was not used on the Site model, or anywhere else.
This was not caught by the tests, because nothing tested the relevant
attributes on the Site model, nor were they used in the code base. Tests
have been added now.
The `alt` attribute that was automatically generated as part of the
`{% image %}` tag could not be overridden. If template authors passed
their own `alt="..."` attribute in, two would be printed out instead
of the default one being overridden.
The relevant code has been refactored to build a dict of attributes,
allowing the default set to be overridden, and then printing them using
`flatatt`.
Fixes#1933
The Elasticsearch tests now depend on an environment variable being set so we can safely install elasticsearch-py without Wagtail automatically assuming Elasticsearch is installed and running the tests.
This makes developer setup slightly easier, but also opens up the possibility for running some of the ES tests that don't depend on a running ES instance.
The translator list now only includes translators specifically identified in the .po files, so that we're not listing dormant Transifex accounts that didn't actually do anything :-)
