Mezzanine doesn't appear to be compatible with Django 1.5

[natea]

Line 28 in setup.py: https://github.com/stephenmcd/mezzanine/blob/master/setup.py#L28

django>=1.3.3

Means that Django 1.5 will be installed. It appears that Mezzanine is not compatible with 1.5 as all the pages return "An error has occurred."

Pinning the version to 1.4.5 in my own requirements.txt made the error go away:

Django==1.4.5

[rgamez]

I'm running Mezzanine with Django 1.5, the only message of error that I had was a deprecation warning related to an unset variable, once ALLOWED_HOSTS was set the message it's gone.

python2.7/site-packages/mezzanine/utils/conf.py:48: UserWarning: You haven't defined the ALLOWED_HOSTS settings, which Django 1.5 requires. Will fall back to the domains configured as sites. warn("You haven't defined the ALLOWED_HOSTS settings, which "

$ python --version Python 2.7.3

$ pip freeze Django==1.5 Mezzanine==1.4.3

[stephenmcd]

Works for me as well.

Any idea what the actual error is? What's the exact Mezzanine version? There was a patch release about a week ago that fixed a few Django 1.5 issues.

[natea]

I was actually using Mezzanine 1.3.0 so that probably explains why I was getting the error under Django 1.5. Btw, the PyPi page still says under "Dependencies": Django 1.3 ... 1.4

That should probably be updated to read: Django 1.3 ... 1.5

[stephenmcd]

Yep the README needs updating.

So the problem was two-fold: Mezzanine should have had Django 1.4 as its max requirement in its setup.py - our mistake that we can't really go back and fix now. The other side was that Django wasn't pinned in your own requirements. Anyone who did that (I think it's fairly common practice) wouldn't have hit this issue.

[natea]

Ok, I'm sorry to say that the problem is still occurring. I just updated my requirements.txt to:

Django==1.5
Mezzanine==1.4.3
South==0.7.6
psycopg2==2.4.6

And still have the "Sorry, an error occurred." message. See attached screenshot.

The logs don't show anything suspicious except for this warning:

[www.0] /home/dotcloud/env/local/lib/python2.7/site-packages/mezzanine/utils/conf.py:48: UserWarning: You haven't defined the ALLOWED_HOSTS settings, which Django 1.5 requires. Will fall back to the domains configured as sites.
[www.0]   warn("You haven't defined the ALLOWED_HOSTS settings, which "

Could it be that it's showing this error because I don't have a ALLOWED_HOSTS setting on my settings.py file?

[natea]

What's really bizarro about this error is that when I add this line to my settings file and re-deploy it:

DEBUG = True

Then the site comes up just fine: http://mezzanine143.appsembler.net

Any ideas why adding DEBUG=True would make the error go away? Of course, now the error isn't occurring so setting it to TRUE doesn't give me any more clues as to what the error was before. :(

[natea]

I see in the docs: https://mezzanine.readthedocs.org/en/latest/packages.html#module-mezzanine.utils

class mezzanine.utils.conf.SitesAllowedHosts
This is a fallback for Django 1.5’s ALLOWED_HOSTS setting which is required when DEBUG is False. It looks up the Site model and uses any domains added to it, the first time the setting is accessed.

So it appears that ALLOWED_HOSTS is required in settings.py if DEBUG=False.

[natea]

Can you confirm that the latest Mezzanine 1.4.3 does indeed work with Django 1.5, or should I revert to Django 1.4.5?

On Thu, Mar 7, 2013 at 3:22 PM, Stephen McDonald notifications@github.comwrote:

Yep the README needs updating.

So the problem was two-fold: Mezzanine should have had Django 1.4 as its max requirement in its setup.py - our mistake that we can't really go back and fix now. The other side was that Django wasn't pinned in your own requirements. Anyone who did that (I think it's fairly common practice) wouldn't have hit this issue.

— Reply to this email directly or view it on GitHubhttps://github.com/stephenmcd/mezzanine/issues/591#issuecomment-14583854 .

nate@appsembler.com +1 (617) 517-4953 http://twitter.com/natea | http://linkedin.com/in/natea

[stephenmcd]

Firstly, it'd be worthwhile to know what the actual error is - have you tried setting up emails being sent on exceptions?

Secondly, it may well be the ALLOWED_HOSTS setting - Django 1.5 requires this to be set, and it must contain all hosts that the site will be accessed by. In Mezzanine we try to alleviate this, by using the domains configured in the contib.sites app. So perhaps you don't have those set up in the DB?

[stephenmcd]

Lastly - yes Mezzanine 1.4.3 works with Django 1.5 out of the box, clearly something is amiss for you though!

[natea]

I'm deploying these sites to Dotcloud and I can see that the default Site object has a domain name setting of: mezzanine143-default-www-0

Could this be what was causing the problem before? Must it be set exactly to the full hostname?

As far as figuring out what the error is, I could remove the ALLOWED_HOSTS line and add some SMTP settings in the settings file to get the error report by email.

On Thu, Mar 7, 2013 at 4:59 PM, Stephen McDonald notifications@github.comwrote:

Lastly - yes Mezzanine 1.4.3 works with Django 1.5 out of the box, clearly something is amiss for you though!

— Reply to this email directly or view it on GitHubhttps://github.com/stephenmcd/mezzanine/issues/591#issuecomment-14588998 .

nate@appsembler.com +1 (617) 517-4953 http://twitter.com/natea | http://linkedin.com/in/natea

[stephenmcd]

Yep that sounds like the problem. I'm not sure how all the site lookups would work in Mezzanine with an invalid domain set up.

[kfehlhauer]

I had the same problem which was fixed by setting the ALLOWED_HOSTS. Originally my site would function just fine with http://www.example.com but would error out on http://example.com. Setting ALLOWED_HOSTS solved the issue. I noticed this setting is missing in the install of Mezzanine and probably should be added.

[kenbolton]

Should there be some integration between settings.ALLOWED_HOSTS and settings.FABRIC["hosts"]?

[kfehlhauer]

Ken, I would agree with that suggestion.

[stephenmcd]

I'd suggest having www.example.com redirect to example.com or vice versa at the nginx/apache conf level - as far as I understand having both serve the same site can affect SEO.

As for integrating with the fabric settings, I'm not sure if it's quite right. Technically the fabric HOSTS setting is the list of servers to deploy to - it could be a dozen different IP addresses, not necessarily the public-facing host name.

Now we have another fabric setting LIVE_HOSTNAME - this gets used to set up both the initial django.contrib.sites record, as well as "server_name" directive in the nginx.conf. So I think this might be much better suited to some kind of integration with the ALLOW_HOSTS setting, but there's still a bit of a mismatch given the above example of someone (incorrectly I feel) serving both example.com and www.example.com from a single instance, and assumedly, a single django.contrib.sites record (eg all the same database content).

Needs more thought I think.

Lastly just to be clear, this actual issue arose due to Mezzanine's own setup.py not specifying Django 1.4.x as a maximum Django version, so unfortunately people who hadn't pip-freezed their requirements would have had Django 1.5 installed for them, which required the ALLOW_HOSTS setting. This has since been addressed in Mezzanine, both by specifying a maximum Django version for situations like this in the future, as well as adding a fallback for ALLOW_HOSTS that uses the django.contrib.sites records in the database.

[kfehlhauer]

I agree with your comments. I just didn't know what the rules are. Thanks for the clarification.

[natea]

If I'm not mistaken, I think Django 1.4.4 also has the ALLOWED_HOSTS requirement. https://www.djangoproject.com/weblog/2013/feb/19/security/

On Tue, Mar 19, 2013 at 6:33 PM, Kurt Fehlhauer notifications@github.comwrote:

I agree with your comments. I just didn't know what the rules are. Thanks for the clarification.

— Reply to this email directly or view it on GitHubhttps://github.com/stephenmcd/mezzanine/issues/591#issuecomment-15147794 .

nate@appsembler.com +1 (617) 517-4953 http://twitter.com/natea | http://linkedin.com/in/natea

[dangayle]

I just ran into this issue myself. Is this the ALLOWED_HOSTS setting something that could be added to the install process?

[kenbolton]

It could be added to the install process, but then you run the very serious risk of forgetting to set it when you deploy to production. Erring on the side of caution and expecting developers to either already have an understanding of Django or spend the time to read the traceback and grow their understanding is the best solution available.

A possible compromise would be to add it to https://github.com/stephenmcd/mezzanine/blob/master/mezzanine/project_template/local_settings.py.templatewith an empty string in the list of ALLOWED_HOSTS with a link to the Django documentation.

I am opposed to including a security hole in Mezzanine out-of-the-box.

On Wed, Jul 3, 2013 at 1:36 AM, Dan Gayle notifications@github.com wrote:

I just ran into this issue myself. Is this the ALLOWED_HOSTS setting something that could be added to the install process?

— Reply to this email directly or view it on GitHubhttps://github.com/stephenmcd/mezzanine/issues/591#issuecomment-20396614 .