This is a fascinating analysis. I'm the CTO of the agency behind the Wagtail CMS (https://wagtail.io) which you reference. People like NASA, Google, Peace Corps, PBS run sites on Wagtail but I'd use WordPress for my friend's 5 page site because:
- < 5 minutes to organise cheap hosting
- automatic updates
- zillions of themes
- someone else can fix it when it goes wrong
I hope Daniele and his colleagues at Aldryn will help with quick cheap Django hosting (they do Wagtail too!). But I'm not sure that Wagtail or Django CMS will ever be the right choice for this use-case. Of course you _could_ build a WordPress equivalent in Django, using postmeta-style key-value tables that abuse relational database theory but allow plugins to define their own content types, and maybe someone should. Our effort is going into building a CMS which helps implementers of non-trivial sites do the 'right thing': keep their content structured, clean, related, filterable. Create once publish everywhere!
There's a lot to learn from WordPress but I don't think 'dynamic models' are the answer for situations where you have more than one developer (there's no guaranteed parity between developer and production environments) or lots of relations (postmeta-style tables have ugly joins, weak integrity checks, poor performance).
It would be fantastic if Wagtail had anything similar like the WP taxonomy - content organization idea, this is the only part missing on the way to a real WP killer.
This is not only about ui - giving users the power to build menus via the ui is great, but the real thing that happens is that people have a great way to actually _manage their content_ - for an experienced WP user it is easy to add a new category menu, add some special section for a limited time or completely restructure a site, etc., this is possible because of how they implemented the usage of taxonomies and how you can structure your site with menus and category pages based on that taxonomies or pull the content with a simple WPQuery. This is very powerful!
If the answers in this thread are right and it is only possible to implement this usecase with custom model classes for each category, then this is a serious design limitation that should be considered. I hope there is another way doing that and I simply missed it, if there is, please make a blog post about it, I beg!
It's about the ideas. I do not want to discuss WP vs. Django on the level of technical details, I understand the context, I understand the code and I know where WP is used and where Django and such a discussion is nonsense.
BTW I would love to use Wagtail for all projects, but easy handling of catregories (lots of them) is very important for long term content segmentation.
Most of the sites we build on Wagtail use taxonomies / categorisation, either with a foreign key to categories defined as snippets, or with custom model classes for each page type, as you describe. You're right that Wagtail has no 'native' equivalent of WP's Categories, and perhaps that's a mistake. You're also right to focus on ideas and usage over technical details; we fall into this trap too easily.
I'm very interested in talking more about this, but without derailing the topic. Please email me on my first name at torchbox.com.
- < 5 minutes to organise cheap hosting - automatic updates - zillions of themes - someone else can fix it when it goes wrong
I hope Daniele and his colleagues at Aldryn will help with quick cheap Django hosting (they do Wagtail too!). But I'm not sure that Wagtail or Django CMS will ever be the right choice for this use-case. Of course you _could_ build a WordPress equivalent in Django, using postmeta-style key-value tables that abuse relational database theory but allow plugins to define their own content types, and maybe someone should. Our effort is going into building a CMS which helps implementers of non-trivial sites do the 'right thing': keep their content structured, clean, related, filterable. Create once publish everywhere!
There's a lot to learn from WordPress but I don't think 'dynamic models' are the answer for situations where you have more than one developer (there's no guaranteed parity between developer and production environments) or lots of relations (postmeta-style tables have ugly joins, weak integrity checks, poor performance).