I recently was working on a project in which I was making use of Cartridge and needed to collect extra info when users added particular products to their order. I wanted this to be toggleable via the backend so that certain products would require extra information and others wouldn't.
Recently while working on developing a Mezzanine powered site I was asked to make it possible to edit the footer in the Mezzanine admin. In this case the footer contained a block of text that was contact info and two blocks that were links, some within the site, some external. In the past I've created a
ContentBlock model that is just a title and
RichTextField. I then have created an accompanying templatetag that looks content blocks up by title and displays the associated content field. That approach works but it's brittle because if someone changes the title of a content block it will no longer be displayed. It also results in extra overhead because displaying three sections would require three database calls. This time around I thought about the problem some more, and came up with a superior solution which makes use of Mezzanine's
This is the fourth and final part of my tutorial series on creating Mezzanine themes. Throughout the tutorial I have been going over the process of taking static html and using it to develop a Mezzanine theme. I've been working with the html template that is available here, but the methods I discuss could be used to develop a Mezzanine theme based on a PSD to html conversion, or any other number of potential sources of styled html. The first post went over the process of creating base.html which is the foundation of the rest of a Mezzanine theme. Part two taught you to take that foundation and create a backend editable page to be your site's home page. The third post described how to make templates DRY and applied those principals to styling Mezzanine's default pages, including a custom design for the gallery. This post will focus on styling the blog and creating more custom content types, adding Portfolio capabilities to our theme.
This is the second post in a series of posts on how I create Mezzanine themes. These posts are a walkthrough of how I take an html template (the one I am using is freely available here, and turn it into a fully functional Mezzanine site. I would recommend starting with the first post, if you haven’t yet read it. In that post I went over how I took the downloaded html template and created a base.html file for Mezzanine. These posts assume some level of familiarity with Mezzanine and Django. It is my belief that struggling, failing, trying again and sticking with something is a great way to learn. I'm posting a lot of code but some pieces may be left up to the individual reader to figure out or do for themselves. If you are having a lot of trouble, or get stuck, sound off in the comments below! The final product, Lucid, is available on MEZZaTHEME.
This is the first part of a series of blog posts that describes the process that I use to create themes for Mezzanine. In this case you will be following along as I create the theme Lucid, which you can purchase on MEZZaTHEME. Lucid is based on the responsive Twitter Bootstrap template that you can find here. Keep in mind that there are many approaches that could be used to create a theme for Mezzanine and this is just one of them. If you see something that I could do better, notice a bug, or have anything else to say, sound off in the comments below!
I was working on further developing a website that is built in Mezzanine and needed to completely disable the built in comments. As far as I know there is no setting that controls this so I wanted to figure out the easiest/most efficient way to do this. Obviously I could go through every template that used the comments_for template tag and remove it (removing the comment form from the associated page), but that would make it more difficult to re-enable comments in the future if so desired. What I ended up settling on was creating an empty generic/includes/comments.html and then adding the following line to my project's url.py:
A question that often comes up on the Mezzanine mailing list is "how can I make Mezzanine do x". Modifying Mezzanine's code directly is an option but that will make upgrading Mezzanine painful. Below I discuss a number of techniques that can be used to modify Mezzanine without actually touching Mezzanine's codebase.
I was working on developing a Mezzanine site where a desired feature was to allow marking BlogPosts as login required, the same way that Pages can be marked as login required. After implenting a solution I decided it would be nice to document it for myself, and anyone else who is interested.
I was recently working on a project that required combining a Django model and another model related to it via a ForeignKey in a single form. At first I considered generating fields for the related model in the ModelForm's init, the more I thought about it though, the more I realized that would be messy, brittle and not easy to make changes to in the future.
I recently ran into a situation where I wanted to make an EmailField unique. The problem was that the field had blank set to True so the field couldn't be unique because when testing uniqueness Django (and AFAIK the underlying databases) consider '' to match ''. This is differnet than when you have null=True as well because django and the underlying database do not consider None and None to be a match when checking for uniqueness.