

A new Django content management system - aram
https://github.com/torchbox/wagtail/

======
tomd
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](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/](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/](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!

~~~
dragop
When you say "translations" I assume you mean just the admin. But does Wagtail
support multilingual websites (nothing seems to be in the docs)?

~~~
tomd
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.

------
mcescalante
Quite an interesting project, and was already posted by the dev team (with a
bunch more resources & info):
[https://news.ycombinator.com/item?id=7231164](https://news.ycombinator.com/item?id=7231164)

------
dguaraglia
Paraphrasing Bruce McKinney on Visual Basic (who was probably paraphrasing
someone else): "Django-based CMS systems make the easy easier and the hard
impossible".

I worked with Django for about 4 years of my life, maybe more if we consider
some proof-of-concept projects. Every single 'framework on top of the
framework' (with the exception of Django REST Framework) I've tried has been
'almost perfect', but that little delta between what you have and perfection
is impossible to bridge. Just the dependency hell introduced by some of the
projects is reason enough to give up.

If all you want is a simple CMS with support for some markup and adding
images/videos, you can throw that together using Django, the Markdown module
and one of the myriad upload plugins in a couple of days. You want to provide
RSS? Use the built-in feed system. You'll spend more time reading the
documentation and tweaking the settings file than putting the whole thing
together yourself.

~~~
tomd
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.

~~~
dguaraglia
Hi!

Sorry, I didn't mean my comment to come through as criticism to this
particular project. I meant it as a more of a warning to people who might be
tempted to use such a complex system for something like running a small few
entries in their website. Chances are the effort to integrate it would be
bigger than just writing a minimalistic thing in the existing codebase.

I agree that systems like these have a place if what you want is something
akin to Drupal (but with a nicer codebase.)

------
film42
At work a client wants to use Django CMS, so I considered this as an
alternative, but I'm not sure how the modularity of Wagtail compares to Django
CMS.

Can someone help me understand why I should prefer one over the other?

~~~
xaritas
It's not like django-cms or various PHP-based CMS (Conrete5 comes to mind)
where a template defines "slots" into which an administrator can drop
different type of content widgets. In spirit, it's much more like Mezzanine,
where each Page has a particular type and an associated template. Your page is
just a Django model, so if you want three areas for text, an image, and a
caption, you'll have a model which has three TextFields, a CharField, and an
ImageField.

(Having said that, the rich text editor is in Wagtail really is rich and can
support inserting images from the image library and links to documents in the
document library, as well as oEmbed stuff, so it has some wriggle room).

The two schools of thought ("each page is designed ahead of time with
structured content in mind" vs "each page is a collection of content objects")
have their adherents. Personally I prefer the Wagtail and Mezzanine approach,
but the right answer depends on what the client needs and the nature of your
relationship with them.

~~~
phaer
If you are part of the Wagtail team: Can you elaborate a bit on the
differences between Mezzanine and Wagtail? On the website it says:

> But having built content-managed websites for 14 years we have strong
> opinions about the editor experience and how a CMS should work and be
> structured, and we need to manage a more rapid pace of development than we
> can achieve by contributing to existing projects.

.. and your editor does in fact look really nice, but what are the structural
differences to mezzanine, why is it not just another backend for Mezzanine?
That would be a question your landing page or README.md should answer in my
opinion. Maybe you could also add Wagtail to the grid on
[https://www.djangopackages.com/grids/g/cms/](https://www.djangopackages.com/grids/g/cms/)
?

~~~
xaritas
I'm not on the team, but I've used both. I would be interested in seeing both
maintainer's answer to this, too.

At a high level, I can see how there might have been a bit of friction in
trying to implement Wagtail on top of Mezzanine. Mezzanine's features, admin
interface, and content model are fairly tightly integrated (I hope I'm not
misrepresenting Mezzanine here, I think that this is an affirmative goal of
the project). It provides a lot for the developer and the site admin out of
the box—usable templates, basic page types, a blog, an image library. On the
other hand, Wagtail core offers surprisingly little—the wagtaildemo project is
a nice starting point for some basic content types, but it's just another user
of the Wagtail API.

For me, the killer features of Wagtail are: deep integration with
ElasticSearch, a moderation based workflow, content revision tracking,
document library. It's feature list is like a love letter to institutional
clients. However, that's a lot of code that is not integral to Mezzanine, and
I don't think it fits with the maintainer's philosophy of "it's integrated,
but not a kitchen sink." [Note: I made up this quote.]

To both maintainers, nice work, and thanks.

------
marcosscriven
I have a couple of sites for friends, which I setup ages ago, for which I used
Drupal - only because a) My design skills weren't that great, and I could use
a package called Artisteer to create the theme b) It was a CMS - so my mates
could just add content themselves

Now - turns out that the Drupal interface is still a bit confusing for people
that don't care for tech. Plus, I'm having to host it on my own server. Can
anyone recommend a really simple CMS I could replace it with, preferably for
something I could host for free?

~~~
egeozcan
I'd recommend Processwire[1]. It's really easy to use any HTML template with
it and I personally find it much easier to work with than Drupal. The catch
is, by using this or Drupal, you are storing your models on the database and
you can't version control a model in a database without getting really
creative.

[1]: [http://processwire.com/](http://processwire.com/)

~~~
themodelplumber
ProcessWire is really great. Some people complain that it doesn't have quite
the off-the-shelf setup of pre-made modules for e.g. powerful e-commerce or
super easy theming, but I think regardless it's an example of the way a
CMS/CMF should be written in the 2010s. In fact I approached a developer of
one of the early CMSes that is still hanging around, and he was quite
interested in migrating to PW as a content management framework backend rather
than using an application framework. The CMS part of ProcessWire is built upon
the ProcessWire content management API and it's easy to build your own custom
back end if you don't like it.

With a content management framework (such as PW), so much has already been
done for you that you start to wonder why you will ever need an application
framework. Of course, application frameworks are very useful but CMFs are not
to be missed out on. I just finished writing a project management system using
ProcessWire and it's been a lot of fun. Like building-with-Legos fun. I hope
to see clones or variants appear in other languages as I'd happily give them a
try as I expand my CS education.

~~~
buovjaga
Any chance you are going to release your project management system in the PW
modules directory?

------
ritonlajoie
I made a demo here : [http://runnable.com/U14o8gNBvRl84F7n/wagtaildemo-git-
for-pyt...](http://runnable.com/U14o8gNBvRl84F7n/wagtaildemo-git-for-python)

Run it, expand the URL written in the top box (not sure why it's not working
properly).

Add /admin to the URL and log in with hnews/hnews for the admin area.

------
thruflo
I've browsed the site, the documentation, repo and tutorial. I still don't
know what the content model or publishing flow is.

I realise that the concept of a generic CMS implies DB backed with bespoke
content types. However, it would be nice to know whether there are any 'first-
class-citizen' types (user, profile, blog post, etc.), how pages are built or
constructed (static html export? dynamic templates?), how edited content is
stored and how / whether I might intermingle CMS edited content with UGC
content.

This kind of information would be much more interesting to me than learning
that the thing is "Beautiful", "Light" and "Agile".

~~~
tomd
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](https://github.com/torchbox/wagtaildemo)

~~~
thruflo
Thanks for the info. And for the record, I very much welcome the beauty,
lightness and agility :)

Just as a ref, here's a CMS intro that focuses on the content model and
workflow: [https://github.com/SpontaneousCMS/spontaneous#features-
curre...](https://github.com/SpontaneousCMS/spontaneous#features-currently-
supported)

------
timonweb
Played with Wagtail and the first thing I wanted to find out is how to
customize the wysiwyg editor. Is there any API to add / remove buttons,
markup, etc? Is it possible or we're stuck with what's offered?

~~~
mattwestcott
It's not quite possible yet, but that's a frequently requested feature, and
we're most of the way there. The wysiwyg component we're using,
[http://hallojs.org/](http://hallojs.org/), supports defining extra buttons
via plugins, and Wagtail provides a hook mechanism for passing in custom
JS/CSS to the editor - we're just missing a bit of glue to connect the two.

I'm cautious about overloading the rich text editor with too many features -
things like tables, say, would be better handled as an explicit part of the
page model / template rather than kept in an opaque blob of HTML - but I can
appreciate the need for more formatting options.

------
mtayseer
I like the design of wagtail admin very much. Can I extract it & use it in
other django app? (I'm asking for permission)

------
ryannevius
Can it be used with Django 1.7? What versions of Django are required? I didn't
see it listed anywhere...Maybe I'm blind.

~~~
JelteF
The setup.py makes clear that Django 1.7 is not supported. 1.6.2 or higher
should be used.

~~~
ryannevius
Of course it does. I'm trying to make the point that one shouldn't even have
to dig that minuscule amount to find out. It's as simple as adding a line to
their landing page: Wagtail supports Python 2.7 and Django 1.6.2.

~~~
timaua
Thanks for the comment ryannevius. Sometimes it's the obvious things that go
overlooked when writing a stack of documentation! There's now a note about
supported versions on the Github README and the Readthedocs landing page.

Thanks for the feedback!

------
izietto
Why there is not the demo; I don't evaluate web products which do not provide
a demo in their site

~~~
phaer
There is a demo, you can run it locally using vagrant and it's linked in the
README:
[https://github.com/torchbox/wagtaildemo/](https://github.com/torchbox/wagtaildemo/)
. If you are asking for a _hosted_ demo, then I don't know if there is one but
you could always set up your own one on services like OpenShift.

~~~
yen223
The Show HN link from the original creators has a link to a site built out of
wagtail.

[https://news.ycombinator.com/item?id=7231164](https://news.ycombinator.com/item?id=7231164)

