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.
