tomd

Wagtail (our open-source Django CMS [1]) can generate a static HTML export of your site to the filesystem, Amazon S3 or Google App Engine, piggy-backing on the excellent django-medusa library [2]. This feature was commissioned by a security company who didn't want to risk an embarrassing exposure to new vulnerabilities in Drupal, Rails, Django etc.

Search is an issue for static HTML sites. Swiftype [3] and Algolia [4] look like solid options - has anyone used these in production?

[1] https://github.com/torchbox/wagtail

[2] https://github.com/mtigas/django-medusa

[3] https://swiftype.com/

[4] https://www.algolia.com

Thanks for the feedback, @thruflo.

The project site is really focused on potential clients, but you're right that the documentation should be clearer about these basics. The README lists a 'feature' as 'Configure content types through standard Django models', which hopefully makes sense to Django developers; essentially you configure your own content types as Django models and register them as pages, where they inherit tags, slugs, publication dates etc. Users are standard Django users and can be augmented with profiles if you want. The wagtaildemo project [1] includes blog posts as a fully worked-up content type, but you don't have to include these in your project. Pages are constructed on the fly, and Wagtail is Varnish- / Squid-friendly if you have lots of traffic. FWIW we're working on a static HTML export feature which could be used for archiving or publishing to S3 etc. Edited content is stored in the database. You can intermingle CMS and UGC content - students at the Royal College of Art are uploading their own work alongside the content managed by the site's administrators, for example.

Plus it's really beautiful, light and agile :)

[1] https://github.com/torchbox/wagtaildemo

Yes - we're currently building a multilingual site for an international NGO - but it doesn't currently do anything clever to link different language versions of the same content; in this implementation we're simply allowing editors to reference translated pages with a page chooser UI.

xaritas's reply is a more eloquent version of what I would have written. We used Mezzanine - e.g. for http://datakind.org - before building Wagtail, which was partly inspired by Mezzanine's pages-are-just-Django-models approach. Mezzanine's excellent documentation and installation process, along with its maintainer's community management, remain reference points for us.

The areas where Wagtail departs most significantly from Mezzanine - the editor experience, moderation based workflow, content revision tracking - aren't features which can be easily tacked on to another system. Our goal is the best possible user experience for content management, and I don't think it's feasible to build that as a skin for the Django admin. In terms of structural differences, django-modelcluster [1] is a key part of what makes this user experience possible:

[1] https://github.com/torchbox/django-modelcluster

Thanks for the CMS grid link. We'll add Wagtail to it.

For a site with a handful of pages and a single author who's happy to use django.contrib.admin I agree with you that plain DIY Django will probably get you there more quickly. But Wagtail (and other Django CMSs) gives you a lot more than that:

- a fast, intuitive content authoring experience

- preview / submit / moderate / publish workflow

- a UI which scales to very large numbers of authors, pages, images

- powerful full-text search in the front- and back-ends

- strong support for image handling (e.g. animated gifs via Wand) and media embedding (OEmbed or Embedly)

As an agency, these points are all pretty much requirements for the sites we build. We couldn't find anything else which gave us these as well as allowing us to build models and templates in plain Django, and we had a client - the Royal College of Art - who agreed to let us open source Wagtail on the back of what we developed for them.

I'm from Torchbox, the creators and maintainers of this project. It's nice to see Wagtail back on HN. For those who saw my original Show HN post a couple of months ago, here's as overview of progress since then:

- Tests: stung by some of the (very reasonable) criticisms after launch, we worked hard to increase our test coverage - https://coveralls.io/r/torchbox/wagtail

- Docs: still a way to go, but our documentation is much better, and now includes an editor's manual: http://docs.wagtail.io/en/latest/editor_manual/

- Translations: we were delighted by the immediate response of translators, whose work we're managing through the excellent Transifex: https://www.transifex.com/projects/p/wagtail/

- Installation: we reduced dependencies (including Sass instead of LESS, and plain JS instead of Coffeescript, so we could drop npm); we made Redis and Elasticsearch optional; we wrote one-liners for Debian and Ubuntu; we improved the installation docs; third parties contributed Docker images.

- UI: we've continued to refine the interface, with feedback from our own clients as well as helpful strangers. In 0.3 we added the 'edit bird', a toolbar allowing logged-in users to add and edit pages from the site's front-end.

- Modularisation: Wagtail now supports alternative backends for image processing (currently PIL and Wand), searching (currently Elasticsearch and SQL) and content embedding (currently OEmbed and Embedly).

- Compatibility: we're working on Python 3 and Django 1.7 support. We've recently added tox to help us test multiple versions for thoroughly.

We're also adding features, but slowly and carefully. A form-builder and scheduled publishing should be released imminently.

We're very grateful for everyone's interest and contributions, even if it's just a harsh word on HN!

Here's the promised walk-through: https://vimeo.com/86719782

Hi eknuth. There's a brief mention of this elsewhere in the thread: "[Wagtail does support multiple languages] but it doesn't (yet) do anything clever like link different language versions of the same article. On a related subject, we're starting on i18n next week, with the first localisation - Greek - following shortly."

Thanks. Can you recommend a pure-Python SASS compiler? The ones we've found seem to struggle with relative imports.

Yes, but it doesn't (yet) do anything clever like link different language versions of the same article.

On a related subject, we're starting on i18n next week, with the first localisation - Greek - following shortly.

The Royal College of Art (for whom Wagtail was originally developed) have commissioned an 'archive' feature, which will take a snapshot of the whole site, or a sub-section of it, and export as standalone HTML with all assets. We're planning to extend this feature to support publishing to S3 / Github Pages / SFTP etc.

Yes, we focused on Python 2.x support for initial release. I'm afraid we haven't even tried Wagtail on Python 3 yet. Having said that, at Torchbox (where Wagtail originated) we have a general if somewhat vague principle that - as responsible Python developers - we should support the adoption of Python 3, so 3.x support is certainly a goal for the project.

If anyone has time to test Wagtail on Python 3 and report any problems to https://github.com/torchbox/wagtail/issues that will accelerate the work!

Thank you very much for your thoughtful feedback. We're pleased with the UI but obviously it's not perfect - I've just started using slack.com which is also pretty flat but feels like a new benchmark for usability. I'll discuss it with the design team, and if you have any more specific feedback we'd love to hear it.

There are still a couple of Wagtail features which rely on contrib.admin. We have to decide whether to smarten up the contrib.admin UI or pull them into the Wagtail admin. Is your CMS available somewhere public?

Please let us know if you end up using it. We'll post a Wagtail t-shirt to your sister's bakery!

Thanks! In case you missed it elsewhere there's a tutorial by Wagtail contributor Serafeim Papastefanos here: https://gist.github.com/tomdyson/8974456 but we're working hard on official docs and a proper screencast.

Thanks for the feedback. It's my fault - I kept asking our video guy to speed it up! We're working on a proper 3 minute walk through right now. It should be ready in the next day or so.

I was hoping no-one would ask that :)

No: the marketing site (http://wagtail.io/) is a single static HTML page. But we're about to add a blog, so we'll convert the whole thing into a Wagtail site, hopefully next week.

Thanks! Wagtail is just a collection of apps which can be added to a standard Django project. Serafeim's tutorial demonstrates this: https://gist.github.com/tomdyson/8974456#creating-and-config...

Note https://github.com/torchbox/wagtaildemo/blob/master/wagtaild... (from the example Wagtail site). To incorporate it into an existing app you'll just need to adjust the URLs so Wagtail isn't taking over the whole URL space.

Developer docs: currently https://github.com/torchbox/wagtaildemo/blob/master/README.m... and this tutorial from contributor Serafeim Papastefanos: https://gist.github.com/tomdyson/8974456

Clearly this isn't enough and we're working on proper Sphinx docs which should be ready in the next few days.

Extensibility: it's just a Django app, so you can include it in your existing project, or add your own apps / views / middleware etc. There are some hooks, e.g. for including your app into the main admin navigation - see https://github.com/torchbox/wagtail/blob/master/wagtail/wagt... for an example of where a hook gets called. It's a good candidate for developer docs!

As it happens, the predictive search already returns JSON, but we don't have a general purpose API yet. It's on the list! Pages are just plain Django models under the hood, so Django REST Framework would be a good fit.

Yes, absolutely! Our first principle for Wagtail is that it should in no way impede design decisions.

LESS is (currently) used for the admin UI, and the compiler / compressor is available to the front-end if you want it, but you can easily plug in your own compilers or use plain CSS if you prefer.

See below - there are tests, see

https://github.com/torchbox/wagtail/blob/master/wagtail/wagt... and https://github.com/torchbox/wagtail/commit/a77977a31cdfcdf95...

but we need more, and to make it more obvious how to run them. You're right that we have to do more to attract contributors. In the meantime we're offering t-shirts for pull requests...

https://twitter.com/WagtailCMS/status/432166799464210432/

Django CMS definitely has more features than Wagtail (and contributors, and impressive example sites). There's a large grid of CMSs and features at https://code.djangoproject.com/wiki/CMSAppsComparison which we haven't added ourselves to yet. We want to resist getting into a CMS feature race - the focus for Wagtail is providing a thoughtful and attractive user interface, and making it as easy as possible for designers to build beautiful sites. As for performance, we haven't done any proper benchmarking, but it feels very fast!

We already support LDAP auth, and CAS and / or Shibboleth is on the roadmap for the near future. More importantly, we'll have proper Sphinx docs soon, with details of the features that are already available.

Yes, sort of. We evaluated the options of sticking with their commercial CMS or switching to a famous open source CMS which we're very familiar with, but we estimated that it would be cheaper to build the site they wanted from scratch in Django. When we'd finished it felt like a lot of the work was reusable, and the RCA kindly agreed to let us open source the project. We've spent the last few weeks extracting it into a standalone package, but there are definitely still some rough edges: documentation, obviously; more tests; i18n.

We currently need npm for lessc, as part of django-compressor, to compile LESS. We want to reduce the dependencies as much as possible, so we're looking into converting to SASS / SCSS, which has a pure-Python compiler, or simply shipping the compiled CSS / JS files for people who don't need to change them.

Thanks for the congrats!

> An idea for a content reset, would be to warn the user before it actually happens and/or having a visible countdown widget that tells you when reset happens.

Right, that doesn't sound too hard, we'll aim to add that.

> I see that the npm dependency might draw away people, maybe provide and add-on that depends on npm and makes it easy to integrate CoffeeScript, LESS, SASS?

Or perhaps we'll just ship the compiled CSS / JS and provide instructions for people who want to use LESS etc in their Wagtail sites.

Thank you! It's named after these lovely little birds which hang round our offices (near Oxford, in the UK) from spring to autumn:

https://www.rspb.org.uk/wildlife/birdguide/families/pipits.a...

The video is intended to pique the interest of CMS choosers with short attention spans... you're right that it's a poor substitute for a real demo, and we'll try to get something up as soon as possible. What's the best practice for refreshing the content on demo sites? I worry that a scheduled content reset will confuse people who are halfway through trying publishing a test page.

The CoffeeScript and LESS integration is a tricky one. We like LESS but we're worried that npm / lessc is an annoying dependency, and we're considering switching to SASS / SCSS, which has a pure-Python compiler, unlike LESS. Opinions very welcome.

Thanks! Yes, we'll have a live demo soon, and a more in-depth video of the admin functionality even sooner - hopefully in the next few hours.

If you have Vagrant and a reasonable internet connection, the easiest way to try out the admin UI is to clone the demo site at https://github.com/torchbox/wagtaildemo, which includes a range of example content types.

I wrote a slightly frivolous one-page app which scrapes National Grid frequency data:

http://www.caniturniton.com/

Someone used its API (/api/json) to make a load-sensitive kettle:

http://elsmorian.com/Projects/CarbonKettle