Mezzanine, a Django powered CMS, reaches 1.0 | Hacker News Reader

Mezzanine, a Django powered CMS, reaches 1.0

groups.google.com

97 pointsstephen_mcd20 comments

Congrats on the 1.0 release! This looks very polished and a strong contender for the king of the django cms's title.

I've been evaluating Django cms's over the last couple days and have narrowed it down to Mezzanine or django-cms. Would love to hear if anyone (especially developers from either package) has any compelling arguments for one vs the other.

I haven't tried mezzanine, but I'd recommend against Django CMS. Using Django CMS, we were finding it took 3-4 seconds for the server to render a page, particularly if pagination is involved (e.g., galleries). I'm sure at least part of this is our fault, since we didn't spend a lot of time trying to optimize this.

We are now using Hyde, which is incredibly flexible (it's just files) and which is about as fast as a CMS can get (hyde is statically generated). I recommend taking a look.

We are currently working to more tightly integrate django with hyde (i.e., share templates, {% url foo %} across both worlds).

Thanks randlet!

I can't really comment objectively on Django CMS, as I've had no exposure to it. Too busy working on Mezzanine.

I did at one point take at look at their page model, which I imagine in both projects is the heart of the CMS. It was a relative mess compared to Mezzanine's, which has always strictly strived to keep a painstakingly clean code base and design, to make jumping in and hacking on as easy as possible.

I've also seen a lot more complaints from frustrated Django CMS users than I have with Mezzanine, many of those who have come to Mezzanine afterwards and really enjoyed it. But that is most likely a result of Django CMS being much more popular - something Mezzanine has a much harder time achieving without a generic name :-)

But please, take that comparison with a grain of salt. Go ahead and try both!

It does looks good. I need a BLOG system and have been working on rewiring django-article module to have the twitter-bootstrap and lot of other modifications. After reading the feature list of MZ, I was ready to make the switch but when I tried it out and saw the system missing the features I needed, I decided to stay with what I got. - writing article in Textile/Markup/restructured text - thumbnail generation

side-note: How about a rename to something with django in it? i.e Better Django CMS?

Personally, Mezzanine does not rolls right off my tongue and my brain is just refusing to memorize it.

There's a third party app that integrates Markdown into Mezzanine: https://bitbucket.org/onelson/mezzanine-mdown

Mezzanine also contains automated thumbnailing for any images at the template level: http://mezzanine.jupo.org/docs/packages.html#mezzanine.core....

Can't help you out with the project name however, sorry :-)

This completely beside the point, but Mezzanine immediately struck me as a wonderful project name - exotic and at the same time mundane. Congratulations for a 1.0 release!

I have been working with Mezzanine for close to a year and a half now and it has been great. The community is awesome and Steve (and others) are very responsive and helpful on the mailing list. I really like page_processors (http://mezzanine.jupo.org/docs/content-architecture.html#pag...) which allow you to easily add additional functionality on a per slug or per model basis. You can also specify templates on a per slug or per model basis. The simplicity, ease of getting started and ease of modifying Mezzanine push it beyond the competition IMHO. It takes care of plenty of things for you and gets out of your way and lets you develop when you need it to.

Note: I don't actually have much/any experience with Django-CMS so I can't make a fair comparison.

I can't really tell if it's possible to start with a plain Django project and then add Mezzanine. I have a project or two that could use a better CMS, but only for a very small subsection of the pages.

The documentation seems to indicate that you really need to start with a Mezzanine project, and then add all your Django bits. It makes a lot of sense for a huge number of sites, but perhaps not so much for the type of projects that are primarily need an easy editor for just a few pages of the overall site.

This came up on the mailing list a few weeks ago and it is doable. The Docs are geared towards new projects but you'll want to look at the INSTALLED_APPS and the urls.py to see what you'd need.

Agree completely. This should be front-and-centre in the documentation. A CMS built on top of Django should, by default, be just another Django reusable app. It shouldn't take over your entire project.

The `mezzanine-project myproject` bootstrapping command should be just an optional shortcut for projects which are completely CMS-based. Which, in my experience, is the minority of projects.

Mezzanine provides a platform that allows you to do a lot more than just CMS stuff, so some projects aren't completely CMS-based. The mezzanine-project command just creates a django project that has some settings already configured (installed_apps, middleware, urls, etc...) so you definitely could integrate Mezzanine into an existing project. In reality Mezzanine is a Django reusable app.

There's a section about integrating into existing projects in the README, which forms the overview section of the docs, as well as the front page of the GitHub repo:

http://mezzanine.jupo.org/docs/overview.html#integrating-an-...

You basically just need to add the relevant settings and urlpatterns.

I've done some testing with the previous version of Mezzanine (0.12?) and preferred it to Django-CMS. I preferred mezzanine to django-cms but with this latest version does not contain the css files in the static directory, which leave the populated demo version broken.

I was also unsure how to get (South?) to update to my Postgre db instead of the dev.db.

I'd suggest going over the Django docs a bit more.

Mezzanine 1.0 makes full use of Django's staticfiles app. With DEBUG enabled, all your static content will be served dynamically from within each app's static directory. Once DEBUG is off, as you'd do for production, you need to run the collectstatic command to move all those files into a single static directory, which you then alias to in your web server's config, be it Apache, NGINX or something else.

https://docs.djangoproject.com/en/dev/howto/static-files/

As for your database settings, simply define those in your project's settings module. Mezzanine will create a local_settings module for you with the SQLite settings defined for development. This shouldn't be checked into version control, as it will be different per environment.

https://docs.djangoproject.com/en/dev/ref/settings/#database...

If you hit any other things like these, please feel free to post to the mailing list where I and others will be only too happy to guide you.

http://groups.google.com/group/mezzanine-users

Hi Stephen. Congratulations, it looks great. I can't wait to play around with it.

Quick question: have you any idea if it works with django-nonrel or if it could be ported to a non-relational database? I've thought building a CMS on App Engine but I may just try porting one of the Django solutions instead.

Thank you!

Using a non-relational store with Mezzanine would be an ambitious task, as Mezzanine makes heavy use of Django's ORM in a relational way.

However I was recently contacted by someone from the App Engine team offering to help ensure Mezzanine deployed smoothly onto it. I mentioned the above and was told that Django is now a first class citizen on App Engine, with relational data supported via "Google Cloud SQL" which is their MySQL offering: https://developers.google.com/cloud-sql/docs/django

I haven't gotten around to making sure everything works smoothly, but it's toward the top of my todo list, so if it doesn't deploy cleanly at the moment, it will soon.

I love the name. In fact, that's the name I've been kicking around for my CMS :D

Man, what a coincidence.

Now, I shall call it ... "Hot Website Makr"! (without the "e") I'd like to see someone take THAT!

Too bad it requires Django 1.3, given the fact that RHEL 6 comes with Django 1.2.

I would suggest that if you're using your system's version of Django, you're not doing things optimally. Check out virtualenv for more info: http://www.virtualenv.org/en/latest/index.html

As Stephen mentions, this is easy to work around using virtualenv and pip. The venv/pip combo make it very easy to work around using whatever outdated packages your distro uses.

Reply on news.ycombinator.com