A new Django content management system(github.com)
github.com
A new Django content management system
https://github.com/torchbox/wagtail/
42 comments
When you say "translations" I assume you mean just the admin. But does Wagtail support multilingual websites (nothing seems to be in the docs)?
Thank you for making all this work available to everyone.
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
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.
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.
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.
- 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.
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.)
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.)
On the 'framework on top of the framework' point - one thing we've aimed to do with Wagtail is to preserve Django's approach to models, templates and so on, rather than falling into the 'inner platform' trap and building a totally new system that just happens to use Django under the hood. So, for example, page layout is still done with Django's template system, and new page types are just Django models with some additions. As a result, using Wagtail is actually not massively different to the DIY route, at a functional level - but you get the extra bells and whistles like revision tracking and workflow as well.
It's a shame you didn't attempt to integrate with the standard admin.
That alone makes you slightly 'an island apart' as I now face the challenge of either:
a) build my own CRUD for parts of the system that aren't directly related to the CMS (products, crm etc etc)
or b) rely on integration with your admin - which I'm guessing isn't as extensible or mature as Django's
That alone makes you slightly 'an island apart' as I now face the challenge of either:
a) build my own CRUD for parts of the system that aren't directly related to the CMS (products, crm etc etc)
or b) rely on integration with your admin - which I'm guessing isn't as extensible or mature as Django's
Wagtail's authoring interface and Django's admin coexist. I believe the demo sets up the Wagtail interface at /admin and puts the standard admin at /django-admin. Presumably you can change those in your urls.py to whatever you like.
Two admin interfaces with different appearances and UI conventions isn't a terribly optimal user experience.
If Wagtail even attempted to smooth the differences between the two (i.e. a custom skin and some customizations to the default admin to make them more similar) then it might be a bearable compromise.
If Wagtail even attempted to smooth the differences between the two (i.e. a custom skin and some customizations to the default admin to make them more similar) then it might be a bearable compromise.
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?
Can someone help me understand why I should prefer one over the other?
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.
(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.
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/ ?
> 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/ ?
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.
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.
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.
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.
xaritas has hit the nail on the head with the key differences...
As I see it, Django CMS's philosophy is to pass on as much flexibility as possible to the editor in terms of page layout. Wagtail takes a more 'prescriptive' approach where the page content has to fit a particular data model (such as an event page that has a start/end date, list of speakers and so on) - which means a little less freedom for editors, but on the flipside, it gives the site creator a lot more control over page layout and design, makes it easier to repurpose that data, and goes a long way to making the editor UI friendlier (since it's a case of 'fill in the gaps' rather than a blank canvas).
As I see it, Django CMS's philosophy is to pass on as much flexibility as possible to the editor in terms of page layout. Wagtail takes a more 'prescriptive' approach where the page content has to fit a particular data model (such as an event page that has a start/end date, list of speakers and so on) - which means a little less freedom for editors, but on the flipside, it gives the site creator a lot more control over page layout and design, makes it easier to repurpose that data, and goes a long way to making the editor UI friendlier (since it's a case of 'fill in the gaps' rather than a blank canvas).
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?
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?
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/
[1]: http://processwire.com/
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.
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.
Any chance you are going to release your project management system in the PW modules directory?
Back in the day, CMS Made Simple (http://www.cmsmadesimple.org/) was pretty excellent, but I haven't used it in a few years. PHP-based (so you can host it pretty much anywhere), and fairly easy to use.
I made a demo here : http://runnable.com/U14o8gNBvRl84F7n/wagtaildemo-git-for-pyt...
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.
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.
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".
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".
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
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
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...
Just as a ref, here's a CMS intro that focuses on the content model and workflow: https://github.com/SpontaneousCMS/spontaneous#features-curre...
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?
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/, 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.
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.
[deleted]
I like the design of wagtail admin very much. Can I extract it & use it in other django app? (I'm asking for permission)
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.
The setup.py makes clear that Django 1.7 is not supported. 1.6.2 or higher should be used.
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.
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!
Thanks for the feedback!
Your wish is their command:
https://github.com/torchbox/wagtail/commit/860c3e036f2df1596...
https://github.com/torchbox/wagtail/commit/860c3e036f2df1596...
Why there is not the demo; I don't evaluate web products which do not provide a demo in their site
There is a demo, you can run it locally using vagrant and it's linked in the README: 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.
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
There's an 'unofficial' online demo (with some limitations - image / file uploads aren't supported) courtesy of Wagtail contributor Serafeim Papastefanos here: http://gentle-refuge-2590.herokuapp.com/
- 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!