21–30 of 43 posts
Earlier quoted context omitted.
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.
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
Earlier quoted context omitted.
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 feedback!
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…
- 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.
Earlier quoted context omitted.
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/
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 manage…
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…
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.
Earlier quoted context omitted.
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…
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…
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.
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?
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).