We’re aiming to share point releases of Wagtail on a monthly basis, around the end of each month. Point releases are traditionally focused on bug fixes and cleanups, and these certainly form a good proportion of our changes, but we’re using the same monthly cycle to add features and improve existing user experiences. Here are some of the highlights from May’s 0.3 release:
The idea that CMSs should allow editing from the 'front end' has been in and out of vogue, rougly since the dawn of contentEditable. There are some impressive implementations – Squarespace is a good example - but it becomes a complicated UI problem when pages are made of up content from elsewhere on the site. With Wagtail, we've taken the position that content authoring should be handled within an interface which is optimised for writing, rather than reading, but our new 'edit bird' feature is a nod towards the quicker gratification of the alternative approach. It’s a toolbar which sits discreetly on the edge of public pages and is only visible to logged-in editors, who can expand it to edit the current page or add another one like it, provided they have the relevant permissions. For greater consistency, we’ve consolidated the approve / reject options from the moderation workflow into the same toolbar.
Alternative image processing backends
This is a feature for site developers, allowing them to replace Wagtail’s standard Pillow image processing library with an alternative, like Wand, the Python wrapping for ImageMagick. Unlike Pillow, Wand handles a feature commissioned by the RCA: support for resizable animated GIFs! Does this make Wagtail the first Django CMS with this crucial capability? More importantly, this feature illustrates our push to modularize Wagtail, allowing developers to swap in alternative libraries where our defaults aren’t the most suitable for their projects.
You can now create single-page forms, such as a ‘Contact us’ form, as pages of a Wagtail site. Editors can build forms within the usual page editor, consisting of any number of fields. Form submissions are stored for later retrieval through a new ‘Forms’ section within the Wagtail admin interface, and can be optionally e-mailed to an address specified by the editor.
Static site generation
Static Site Generators (SSGs) have been all the rage in CMS-land over the last couple of years, with the rise of tools like Jekyll, and high-profile posts from organisations like Development Seed on embracing the simple file. Wagtail has now muscled in on this game, with the help of Context Information Security, who commissioned Torchbox to add static site generation to Wagtail’s feature list. If you want to generate a version of your Wagtail site as static files, either for performance, or security, or simply as a snapshot of your content which will last longer than the whims of CMS suppliers, we have a new command for you: ./manage.py staticsitegen. This piggy-backs on the django-medusalibrary, and will whirr away building each page before uploading them to your server, or to Amazon S3.
Among the other changes in 0.3, we’re particularly pleased with the improvements to Wagtail’s documentation, and grateful for Jeffrey Hearn’s eloquent contributions to it. Keep track of ongoing work on our Github repo, and stay tuned for 0.4!