Currently, we only allow the following format for the serve view:
/images/<signature/<id>/<filter>/
This URL doesn't look nice as an image is expected to be a standalone file. This commit makes the following format possible:
/images/<signature/<id>/<filter>/test.jpg
Drone will now check that
from __future__ absolute_import, unicode_literals
is part of every Python source file, to ensure a consistent experience
across all versions of Python.
See #2392 for an instance where missing `unicode_literals` was causing
problems.
Add missing absolute_import, unicode_literals to all files
Explicitly ensure strings are of the correct types
Now that unicode_literals is in every file, some things that used to
be py2 `str`s were now `unicode` instead. This caused issues with
generated class / function names, which must be `str` in all versions of
Python. This means bytes in py2, and unicode in py3. A test also checked
for the incorrect type of SafeString. HTML content should always be
unicode, so this has been fixed.
The "icon-" prefix is automatically added in SettingMenuItem.
Using "icon-placeholder" as suggested would thus result in
the CSS class "icon-icon-placeholder".
Previously, the POST data could not be empty for some views, otherwise
they would not work. This caused the workarounds to be necessary. The
request method detection was fixed in the previous commit, so this
commit removes the workarounds.
Check `if request.method == 'POST':`, instead of `if request.POST:`. The
latter works as long as there is POST data, but on a delete form, for
example, there isn't any. It works fine usually, as the `csrf_token`
counts as POST data, and is included in all requests, but leads to
strange work arounds being required in tests.
These tests sent some Python 2 `str`s to unidecode via taggit, which
raised a RuntimeWarning. These strings should be unicode, and are
unicode when they come from Django outside of the tests.
unicode_literals should be added to all Python files to ensure
consistent handling of strings across Python versions, but that is a
larger and more controversial change.
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.
Some code was using methods from Wagtail, even though those methods were
deprecated with alternatives provided. Those alternatives are now used
instead.
Forms for Page classes must subclass WagtailAdminPageForm. If they do
not, an error will be thrown for invalid arguments when the Page editor
is opened.
Partial fix for #2267.
Unless overridden by passing `base_form_class=CustomFormClass` to an
EditHandler, the EditHandler now gets the base form class from the
model. People who override the EditHandler of a model no longer have to
also override the base_form_class if the model needs a custom one.
Fixes#2267
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
Karl Hobley