Show HN: Wagtail, our new Django CMS
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)
98 comments
[ 3.3 ms ] story [ 169 ms ] threadIs there a live demo anywhere or plans for one? In particular to try out the admin functionality.
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.
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 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 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?
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.
Relevant link: http://metaskills.net/2012/02/27/too-less-should-you-be-usin...
[1] http://blog.danieljost.com/scss-on-a-remote-server/ [2] https://github.com/dahlia/libsass-python
You might want to look into the C implementation? https://github.com/hcatlin/libsass
https://www.rspb.org.uk/wildlife/birdguide/families/pipits.a...
http://wagtail.io (marketing site)
http://www.rca.ac.uk/
- Matt (lead Wagtail dev)
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 ;)
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.
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've not come across Splinter before, that looks interesting. I've been using PhantomJS via CasperJS but my tests so far have been brittle...
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 :)
http://kev.inburke.com/kevin/the-best-ways-to-find-bugs-in-y...
A couple of simple integration tests go a long way detecting the most visible bugs.
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.
Thanks for the congrats!
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.
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.
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, 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!
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!
It would be hard to convince anyone to contribute without some unit tests.
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/
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!
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!
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?
Surprised you haven't looked at it - it's the most downloaded of all the Django CMSes.
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.
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?
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.
Feedback: I hope for some good documentation like a starter tutorial and video screencast so more people can understand your CMS and use it.
Is that true in general for this CMS, that Python 2.7 will be needed? Python 3 isn't supported?
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!
https://index.docker.io/u/oyvindsk/wagtaildemo-incomplete/
https://github.com/oyvindsk/docker-playground/tree/master/do...
docker run -p 8000:8000 oyvindsk/wagtail-demo
https://index.docker.io/u/oyvindsk/wagtail-demo/
Thanks for open sourcing this. :)
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.
On a related subject, we're starting on i18n next week, with the first localisation - Greek - following shortly.