The logic for publishing a page exists in the create and edit views of
wagtailadmin.views.pages and in the publish methodd of hte PageRevision
model.
When a page is created and published (create view), if it has a go_live
in the future then it will not be live but the revision that will be
created will have the approved_go_live set to the corresponding datetime.
If the page is just saved or submitted for moderation the normal flow
will be followed.
When a page is edited and published (edit view):
* The approved_go_live_datetime will be cleared for all older revisions of
that page.
* If the edit has a go_live in the future then the new revision that will
be crated will have the approved_go_live set to that datetime. Also the
live attribute of the page will be set to False.
If the page is edited and not published the normal flow will be followed.
When a submitted for moderation page is published (publish method):
* If it has a go_live in the future then the live attribute will be set to
False, the approved_go_live_datetime of the revision will be set to the
go_live_datetime of the page and the approved_go_live_datetime of all
other revisions will be cleared.
* If it does not have a go_live in the future then the page will be live
and the approved_go_live_dattime of all other revisions will be cleard
Finally, if a page is unpublished then then approved_go_live_datetime of
all revisions of that page will be cleared.
Also add a clean method to Page to check that expiry date is in the
future and that go live date is before expiry date. In order to display
the correct error message the views/pages.py view has to be changed to
display the error message from clean.
Finally add the migration for the new fields.
a854c03f443083a1471dd066dece92527dbb7c7c improves the behaviour a lot, but it's
still fairly nasty for a text field to be rewriting text as you type it. It's
also unnecessary - you have to be pretty determined to submit the form without
triggering the blur event on the field, and if you do, all that happens is that
you fail server-side validation.
quality. Uses an IMAGE_COMPRESSION_QUALITY in the settings.py, which, if
set, will set a quality attribute in the image processing backends. Each
image processing backend then can use the quality attribute in its "save"
method.
This has been implemented in both Pillow and Wand backends. It has been
tested with image that support this setting (JPG) and images that do not
support it (GIF, PNG) and the behavior is consistent.
This is an implementation for #163.
