[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/ ?

[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.

[tomd]

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.