Upgrading to Mezzanine 4
This post assumes your project is currently using Mezzanine 3.1.10 and up to date with South migrations.
This post assumes your project is currently using Mezzanine 3.1.10 and up to date with South migrations.
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.
$ adduser new_user_name
then $ visudo
root ALL=(ALL:ALL) ALL
replicate it just below and replace root with the username created above.ALLOWED_HOSTS = ['example.com']
$ fab all
Logs end up in /var/log/
particularly:
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 SingletonAdmin
class.
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 recently integrated Django Sendfile with a website to provide downloads that required authentication (even knowing the location of an authentication requiring file in the static directory will not allow you to download it thanks to some Apache conf magic).
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.