Hacker News new | comments | ask | show | jobs | submit login
Show HN: Wagtail, our new Django CMS
166 points by tomd on Feb 13, 2014 | hide | past | web | favorite | 95 comments
Wagtail is a new, open-source Django CMS focused on flexibility and user experience. It was originally built for the Royal College of Art, but now we're able to share it with everyone. See

https://github.com/torchbox/wagtail

and

http://wagtail.io (marketing site)

and

http://www.rca.ac.uk/ (first big site built on Wagtail)

We're really proud of the user interface, and we hope that Wagtail will make it easy for Django developers to build beautiful, modern sites. Feedback very welcome!

Tom Dyson, Technical Director at Torchbox (Wagtail developers)





This HN no-link-doctrine is really annoying...


I did the whole vagrant setup demo thing - this CMS looks unbelievably nice. Kudos to the design team. Stock Django admin (even with Grappelli) is kinda ugly now.

Like others mentioned, a live demo is definitely preferable - not many will go through the vagrant setup.

Also there's a bug when trying to view a sample page:

'embed_filters' is not a valid tag library

But good stuff otherwise!


oops, hazards of working off a live Git repo there :-) Fixed now - please run a git pull / pip install -r requirements/dev.txt and try again!


The first thing I look for on a marketing site for a CMS is the link to the demo, which isn't there.

Generally, I think demo videos don't fill this void and this one does a particularly bad job, unless maybe played at half speed.

Apart from that, Wagtail looks very interesting and I'll take the time and install the demo app. Thumbs up for choosing Postgres and integrating CoffeeScript and LESS.


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.


I generally prefer SCSS to LESS as it's essentially a superset of LESS.

Relevant link: http://metaskills.net/2012/02/27/too-less-should-you-be-usin...


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.

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?


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


+1 for compiled CSS/JS. I'd love that and it would get me up and playing with it much faster, personally.


It would be great if you would switch it to SASS in the future. Although for me personally its not the npm dependency but that i like SASS much better then LESS.


SASS for sure. I've used sass in development for years now, and I prefer to not use LESS. Having LESS as a requirement was an immediate read flag for me :)


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


I struggled with finding a way to compile SASS last summer and my solution wasn't great[1]. Nowadays, this version of libsass for Python[2] looks pretty stable, and failing that Grunt would work well enough.

[1] http://blog.danieljost.com/scss-on-a-remote-server/ [2] https://github.com/dahlia/libsass-python



I haven't. I've never used SASS directly on the production server, I just run Compass on dev and push the compressed css to a cdn or media server.

You might want to look into the C implementation? https://github.com/hcatlin/libsass


So, were you hired to make a site for the RCA and decided to build a CMS first? I'm interested in how this came about.


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.


This is pretty awesome. A non-PHP CMS is long, long overdue. I know there already are some, but I think the challenge is that non-technical types are still more able to quickly get started by just dragging some PHP into their shared hosting service and turning it on. I hope this will change, and a project like yours is key to making that transition.


Congrats on open sourcing this. It looks great! I'm very pleased to see a Django app where the design hasn't come as an afterthought.

I'm just about to test it out but I have a question – how easy is it to to integrate this into an existing project?


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.


Quick tip on the video: I felt it moved a little too quickly. I tried keeping up with the text, and it seemed to get pulled away from me as I was about 2/3rds through each time. At the end I was slightly dizzy :/


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.


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


Really nice. One question:

One feature I always wanted implemented in whatever CMS I was using was the ability to enter, say, a comma-delimited list of page titles, select the parent page and template to use, and have the CMS generate those pages in one go, instead of having the content editors hit the "New page" button fifty times.

I used to work for a large medical company, and they're departments always had special requirements, with lists of sub-pages to create for their department. Three hours later (it was a Java-applet-based CMS :( ), I was just about done with creating their pages.


Wagtail is open-source, so there's nothing stopping you/someone adding that functionality - indeed, it'd be pretty trivial do to as a Django management command that would work something like:

     ./manage.py create_page_stubs path/to/your/list.csv


Anyone got a working dockerfile for the demo? Took a stab at it, but it doesn't work :(

https://index.docker.io/u/oyvindsk/wagtaildemo-incomplete/

https://github.com/oyvindsk/docker-playground/tree/master/do...


ALmost works now:

docker run -p 8000:8000 oyvindsk/wagtail-demo

https://index.docker.io/u/oyvindsk/wagtail-demo/


Nice presentation on the marketing side.

Is there a live demo anywhere or plans for one? In particular to try out the admin functionality.


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.


Seems really good! Are you planning to compare it with other CMS (especially Django-CMS)? I would like to see its performances (with or without varnish).

Would you like to add OAuth support or other auth mechanisms like CAS? =) I didn't find documentation for the "WAGTAIL_PASSWORD_MANAGEMENT_ENABLED" option.


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.


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

Yes, please keep that focus. A well-focused project is both refreshing and produces extraordinary results. You also appear to have a 'bigger-picture' view than many CMS creators - i.e. on the designers and the people who end up using it, not just the developers.

Congratulations Tom!


Very nice! Thanks for the good work! Will check it out.

Feedback: I hope for some good documentation like a starter tutorial and video screencast so more people can understand your CMS and use it.


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.


> To follow this tutorial you will need to have Python 2.7 installed with a working version of pip and virtualenv.

Is that true in general for this CMS, that Python 2.7 will be needed? Python 3 isn't supported?


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!


Would you gents (upstream wagtail guys) be interested if I took a shot at integrating pelican into this? I'd like a static blog and semi dynamic site and <3 django.


That sounds very delicious to me. this CMS to build sites, and S3 static to host them :)


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.


Thanks for the hard work. We need more CMSs in Python!


What's API support like? IE if I wanted to create a search widget that uses JSON. Have you considered something like Django REST Framework?


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.


Having used piston, then tastypie, and now django-rest-framework for a number of json rest services, drf is hands down the nicest. Also, Tom Christie (main author) is super responsive via twitter or IRC so you can get bugs fixed / prs merged super fast. I literally can't recommend it enough


Looks really nice.. I can't wait to pull and try it out. Just out of curiosity: Is the marketing site also built using Wagtail??


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.


Looks great. One thing that I find not so good is: There are no tests.

It would be hard to convince anyone to contribute without some unit tests.


There are some https://github.com/torchbox/wagtail/blob/master/wagtail/wagt... - but not enough, we know. We're on it!


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/


Wow, this is really beautiful. Just in time for my next project: a tiny ERP to manage my sister's bakery.

Thanks for open sourcing this. :)


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


Nice! I was just reevaluating the django cms world and happened to stumble on this post.

Any support for multiple languages, yet?


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


Are there any developer docs? How extensible is it? How we do integrate 3rd party apps into the wagtail admin?


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!


That looks interesting. I've got a CMS which shares some philosophical similarities to Wagtail. It's a lot clunkier and uglier though. I wish I had the time to add some polish. I think the 'pages have types' idea is spot on and something all the other Django CMS's I've seen seem to get wrong. (too much freedom for the user to create 'Frankenstein pages' by arbitrarily combining blocks).

The editor and image library is very nice.

I feel you've gone slightly too far in the 'flat and beautiful' direction. Some UI elements lack affordance and I think usability has suffered slightly at the hand of aesthetics.

Finally I still feel there's a case for not completely replacing contrib.admin but that is a complex debate and I can see in your specific case you probably made the right decision. I'd really like to see if I could achieve some of your elegance without abandoning (or reinventing!) contrib.admin.

Best of luck!


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?


Not public public but there's a Git url, I'm happy to share if you drop me an email: andy@andybak.net


Mezzanine takes that exact approach where pages are of specific types, and has consistently rejected calls to add arbitrary block features (although you can do that with add-ons).

Surprised you haven't looked at it - it's the most downloaded of all the Django CMSes.


Python 2 or 3?


Classifier say 2:

    'Programming Language :: Python :: 2.7'


Does it support handling multiple sites? If not, do you have any plans for adding multi site feature?


Yes, multiple sites are supported - there's a single tree for all pages in the system, and any number of sites can be 'rooted' at different points in the tree. (Currently this is configured in Django's own admin interface, but we'll be moving this into the Wagtail interface proper.)


After watching your marketing video I now know why I don't get much done. You guys work fast.


Just tested out the demo site on local machine. The admin pages look gorgeous!!! Great work!


Why is npm listed as dependency ? Just curious. Congrats on this, it looks awesome.


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!


SASS or one of its variants (SCSS, Bourbon, Compass) would be lovely!


Can we use our own frontend stacks to design the frontend?


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.


Really excited for a CMS that takes the writing experience into account


Does it support content in two languages?


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.


Brilliant name! Good work chaps!


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


You missed out on a great naming opportunity:

    pip install pipit


Here in Hertfordshire too!


Frameworks on frameworks on frameworks.


What's the third 'framework'?


Its a CMS built on a framework.


Whats wrong with that?


This looks interesting, but I can't take it seriously. From what I can tell, you haven't written any tests at all.


So a CMS that works as the client requires and has a very nice UI can't be taken seriously because it has no tests?

That's a very developer focused mindset.

I'm glad it's been open sourced and I hope to see tests added by them or the community, but it's not a deal-breaker for me.

And if you contribute tests I hope they'll be full functional tests to spot cross-browser regressions, JS breaks and the rest ;)


Yeah, it's probably a developer focused mindset, but I'm a developer.

Without a test suite, it makes it very difficult for anyone to contribute, because there isn't a clear way to tell if they broke something. How do you decide to accept a pull request?

Then there is the entire issue of security. Without proper tests, how can you test that login/logout/sessions work? How can you tell if the csrf token is present? The list goes on.

What about databases? Does it work with Postgres? MySQL? How do you know?

I'll say it again, I think it's a cool project - but it needs tests. Tests are a developer's best friend.


Do you TDD kids never try to read and understand the code? Just assume because it passes a test it is working?


Clients do care about having a stable and bug free software. Tests is one of the best way to achieve this.


I know and I agree, but I feel tests often cover the wrong thing, or what the developers feel is most important. Unit testing libraries within the system: great. Leaving the rest: not so great. Or aiming for 100% code coverage: uggh.

Playing devil's advocate here: Testing the system throughout to ensure components play nicely together and that functionally the system works as expected - this is in my opinion more important than unit testing.


There are two types of tests.

unit tests - most common and are tightly tied to the code. integration tests - simulate example user behavior and test the pieces work together as expected. For this type of app, selenium is the best tool for the job and splinter is an amazing python abstraction ontop of selenium. For instance, I have Jenkins setup splinter to run chrome and Firefox tests headlessly using a frame buffer (xvfb) to test the apps I'm responsible for as part of $dayjob.

Both types of tests are necessary and equally important.

http://splinter.cobrateam.info


I applaud your view. Here in the PHP universe we're only starting to exit the "Everything must be unit tested" phase of programmer evolution, and integration/functional testing is still a novelty.

I've not come across Splinter before, that looks interesting. I've been using PhantomJS via CasperJS but my tests so far have been brittle...


Well we used to be in the same boat and then... A new developer wrote a few new bit pieces of code that were supposed to work together. He overly unit tested each piece discretely, but they didn't work together. So when we pushed it out to staging and I manually tried to look at things, the entire design was wrong and would never work.

From then on, the next task said individual worked on was setting up selenium and write integration tests. Now we are in a pretty sweet place.

We have unit tests, which verify each discrete thing works as it is expected to and make refactoring large swaths of code a breeze. Then we have integration tests, which run on IE (in a windows vm that is on our build server), firefox, and chrome via xvfb. It even helps us catch those obnoxious conditions where javascript runs fine in "real browsers" and fails on IE's lameness. Give it a try :)


According to this, it doesn't help that much compared to other things.

http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-y...


Interesting article. Although I doubt most project will have 1000 beta testers ready to fill up detailed bug reports or some benevolent code inspectors.

A couple of simple integration tests go a long way detecting the most visible bugs.


Some of the tests are the default django assert 1 + 1 = 2, but there are quite a few others scattered about the directories.


I wasn't counting the default django 1 + 1 test, but I did find one actual test. It's obvious that a lot of work was put into this, and I think it has potential. My suggestion to the creators is to start with tests from the beginning. However, it's not too late to start now and add tests for everything. It's a lot of work initially, but it will pay off for years to come.


Agreed, proper test coverage is absolutely something we want to achieve. We're working on it as we speak... https://github.com/torchbox/wagtail/blob/master/wagtail/wagt...

- Matt (lead Wagtail dev)




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: