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`
