Re: [mezzanine-users] Adding a collection of Images to a custom model in Mezzanine
Hey Guys, This is may seem like a very broad question but how do you create a foreign key to Gallery in Activity model... I wrote this line in my Activity model: *activity_gallery = models.ForeignKey(Gallery, null=True, blank=True, related_name=ActivityImages)* When I drop my database and re-create it, there is an error which shows up. I can't seem to be able to resolve it. *File /Users/shaunaks/Documents/MyProjects/AGToysVE/lib/python2.7/site-packages/django/db/models/fields/related.py, line 1227, in get_default* *if isinstance(field_default, self.rel.to):* *TypeError: isinstance() arg 2 must be a class, type, or tuple of classes and types* Please help! -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com' to..
I've been getting this error message since I've deployed my mezzanine website: [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com' to ALLOWED_HOSTS where domain.com is most of the times the IP of the server, few times a secondary domain which redirects to the main one and one time www.fbi.gov :-) I've read the pages below, so I think that I can just ignore the error (I'm sure that my ALLOWED_HOSTS is restrictive). I guess that I can wait for Django = 1.7b4 in Mezzanine and then I won't get any error message. Right? http://stackoverflow.com/questions/15238506/djangos-suspiciousoperation-invalid-http-host-header https://code.djangoproject.com/ticket/19866 https://github.com/django/django/commit/d228c1192ed59ab0114d9eba82ac99df611652d2 (added in django 1.7b4) -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: Proposal: page_move signals
Seems incomplete for the use-case - couldn't the user create a new MyPage instance as a top-level page? On Mon, May 26, 2014 at 10:26 PM, Ahmad Khayyat akhay...@gmail.com wrote: Any comments? Any additional information required? Here is an example that uses this feature to disallow pages of type MyPageto be top-level pages: from mezzanine.pages.signals import pre_page_move @receiver(pre_page_move, sender=MyPage)def my_move_constraints(sender, page, new_parent, **kwargs): if new_parent is None: return Pages of type MyPage cannot be top-level pages If a user drags a MyPage to a top-level position in the page tree in Mezzanine admin, the page will be moved back to its original position, and an error message will be displayed using Django messages. The text of the error message is the returned string: “Pages of type MyPage cannot be top-level pages”. A subsequent valid move will remove the error message. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: Proposal: page_move signals
Put another way: creating an instance is not a page move. On Mon, May 26, 2014 at 4:21 PM, Ahmad Khayyat akhay...@gmail.com wrote: Right. Yes, they can. But that would be handled by the save method of the MyPage model (this is what I do in my app). I don't know of a way to handle it in the page tree. On Mon, May 26, 2014 at 4:18 PM, Stephen McDonald st...@jupo.org wrote: Seems incomplete for the use-case - couldn't the user create a new MyPage instance as a top-level page? On Mon, May 26, 2014 at 10:26 PM, Ahmad Khayyat akhay...@gmail.comwrote: Any comments? Any additional information required? Here is an example that uses this feature to disallow pages of type MyPage to be top-level pages: from mezzanine.pages.signals import pre_page_move @receiver(pre_page_move, sender=MyPage)def my_move_constraints(sender, page, new_parent, **kwargs): if new_parent is None: return Pages of type MyPage cannot be top-level pages If a user drags a MyPage to a top-level position in the page tree in Mezzanine admin, the page will be moved back to its original position, and an error message will be displayed using Django messages. The text of the error message is the returned string: “Pages of type MyPage cannot be top-level pages”. A subsequent valid move will remove the error message. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/bIxUJkOIdUM/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] The SECRET_KEY setting must not be empty error
Here you go! https://docs.djangoproject.com/en/dev/ref/settings/#std:setting-SECRET_KEY On Mon, May 26, 2014 at 2:30 PM, val_erie vlawso...@gmail.com wrote: Hi, I have Mezzanine 3.1.4 installed in virtualenv and I would like to run it using Apache2 and mod_wsgi. I followed https://docs.djangoproject.com/en/1.6/howto/deployment/wsgi/modwsgi/#how-to-use-django-with-apache-and-mod-wsgito configure apache. I do have SECRET_KEY in local_settings.py, but I am getting this error when try to run mezzanine through apache: ImproperlyConfigured: The SECRET_KEY setting must not be empty. Any help is greatly appreciated. Valerie -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] The SECRET_KEY setting must not be empty error
if you have SECRET_KEY defined in local_settings.py, you might find that local_settings.py actually isn't being imported. You could verify this by editing settings.py towards the end where it imports local_settings.py, to allow it to throw an error if the import fails, which would show what the real error is. On Tue, May 27, 2014 at 4:30 AM, val_erie vlawso...@gmail.com wrote: Hi, I have Mezzanine 3.1.4 installed in virtualenv and I would like to run it using Apache2 and mod_wsgi. I followed https://docs.djangoproject.com/en/1.6/howto/deployment/wsgi/modwsgi/#how-to-use-django-with-apache-and-mod-wsgito configure apache. I do have SECRET_KEY in local_settings.py, but I am getting this error when try to run mezzanine through apache: ImproperlyConfigured: The SECRET_KEY setting must not be empty. Any help is greatly appreciated. Valerie -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: modeltranslations - round 2
Fair enough - just wanted to make sure something simpler hadn't been overlooked. On Tue, May 27, 2014 at 12:30 AM, Mathias Ettinger mathias.ettin...@gmail.com wrote: Well, I started from something similar in the first place. I think it is good enough for an external app, but not so good if we want a tight integration. First off all, the field duplication issue mentionned in the project is directly handled when modifying mezzanine and using the right base classes for the admin. As opposed to either patch django-modeltranslation or add redundant information in the translation.py file. Then, the form submit button issue requires a (minor) modification to mezzanine to works properly. Both the slugs being generated for the active language issue and the language selection on the frontend site need mezzanine to be aware of modeltranslation to work. Or at least mezzanine should consider the USE_I18N setting for these tasks. Translatable settings such as SITE_TITLE or SITE_TAGLINE would be a pain in the ass to handle from an external app. Needless to say it would be even harder to make it support custom translatable settings (those defined in an external app default.py). With this implementation it comes out of the box. I understand your reasoning in the sense that: the less file we modify, the less error-prone it will be and the less cumbersome it will be to maintain. But I have the feeling that a tighter integration will both make issues easier to spot and fix and ease the development of future features with translation needs. As an example, the pull request I made for cartridge compared to the two-files approach I proposed in the bug tracker ( https://gist.github.com/Kniyl/11249940). Defining model methods outside of their class is anything but a good idea. That is why I spend my time trying to provide the best approach within mezzanine: I’d like to get rid off the ugly external app that I’m using. I’m also confident that this work is very close to completion. Missing features are: translation field for keywords (that I don’t know how to handle, yet), translation field for slug (that need further discussion) and a nice tab-based grouping of fields in the admin (that Eduardo plan on doing). The only concern for now is about where to put the translation validation logic. In my opinion, the admin is a good place rather than in the model, because it lets people who knows what they are doing achieve their goals more easily. But I might be wrong. Le lundi 26 mai 2014 15:24:50 UTC+2, Stephen McDonald a écrit : Any thoughts on this implementation? https://github.com/Romamo/mezzanine-modeltranslation/blob/master/ mezzaninemodeltranslation/translation.py It was mentioned in the discussion against the pull request but no comments were made. I really like how this approach doesn't require any change to Mezzanine itself, as opposed to the proposal here which is a real concern. On Mon, May 26, 2014 at 10:52 PM, Mathias Ettinger mathias@gmail.com wrote: I need to take a decision, so I’ll ask here instead. I was trying to write some tests for modeltranslation integration and I stumbled upon an issue. Basically I was trying to test that slugs are always generated based on the default language using the model logic (Page.save()) whereas the slug issue was fixed using the admin logic (ModelAdmin.save_model()). Obviously my test fails. But I’m wondering wether it should be fixed by testing the admin behavior or by implementing the slug logic into the Page model. As a more general question, there are some fields that are auto-populated based on other one and both are marked for translation. They are handled by the admin which saves the model several times (one for each language). Is it acceptable or should this logic be moved to the Displayable model? -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[mezzanine-users] Re: [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com' to..
Hi Federico, If you're using NGINX you can add a rewrite to your sites .conf file. http://jarednielsen.com/blog/how-to-configure-server-name-redirect-in-nginx/ I was receiving the same error (and an inbox full of Django notices) but fixed it with the solution linked above. Cheers. On Monday, May 26, 2014 5:34:23 AM UTC-6, Federico Bruni wrote: I've been getting this error message since I've deployed my mezzanine website: [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com' to ALLOWED_HOSTS where domain.com is most of the times the IP of the server, few times a secondary domain which redirects to the main one and one time www.fbi.gov:-) I've read the pages below, so I think that I can just ignore the error (I'm sure that my ALLOWED_HOSTS is restrictive). I guess that I can wait for Django = 1.7b4 in Mezzanine and then I won't get any error message. Right? http://stackoverflow.com/questions/15238506/djangos-suspiciousoperation-invalid-http-host-header https://code.djangoproject.com/ticket/19866 https://github.com/django/django/commit/d228c1192ed59ab0114d9eba82ac99df611652d2(added in django 1.7b4) -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com' to..
Hi Jared, I don't think that's Federico's issue. I have my ALLOWED_HOSTS set to the domain name(s) I allow, but quite often will get the error email with my site's IP address, which is not in ALLOWED_HOSTS (as I don't want people accessing the site using the IP). I suspect it's some malicious bot out there trying to run some sort of exploit on the site, and the error from Django is just an indication that this is happening. Prior to Django 1.6, I would get these errors as proper error reports with a full traceback, sent to me via Error stack (I have some handlers set up in my code for this). Usually the access was to admin.php or some other non-existent PHP file. However, since moving to Django 1.6/Mezzanine 3.x only the email errors come directly from Django - with a repr() unavailable message instead of a traceback, and the handlers set up in my settings.py are completely skipped. I'm not sure what changed so that this sort of error is not passed to my custom error handler, but it's not something that's easy to replicate for testing purposes, so I'm basically just ignoring the messages... Any pointers as to how to get these error messages sent with a proper traceback, or to be passed to my error handler (and thus to ErrorStack) would be greatly appreciated. All the best, Seeya. Danny. On 27 May 2014 07:53, Jared Nielsen nielsen.ja...@gmail.com wrote: Hi Federico, If you're using NGINX you can add a rewrite to your sites .conf file. http://jarednielsen.com/blog/how-to-configure-server-name-redirect-in-nginx/ I was receiving the same error (and an inbox full of Django notices) but fixed it with the solution linked above. Cheers. On Monday, May 26, 2014 5:34:23 AM UTC-6, Federico Bruni wrote: I've been getting this error message since I've deployed my mezzanine website: [Django] ERROR: Invalid HTTP_HOST header: 'domain.com'.You may need to add u'domain.com' to ALLOWED_HOSTS where domain.com is most of the times the IP of the server, few times a secondary domain which redirects to the main one and one time www.fbi.gov:-) I've read the pages below, so I think that I can just ignore the error (I'm sure that my ALLOWED_HOSTS is restrictive). I guess that I can wait for Django = 1.7b4 in Mezzanine and then I won't get any error message. Right? http://stackoverflow.com/questions/15238506/djangos- suspiciousoperation-invalid-http-host-header https://code.djangoproject.com/ticket/19866 https://github.com/django/django/commit/d228c1192ed59ab0114d9eba82ac99 df611652d2 (added in django 1.7b4) -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- molo...@gmail.com -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [mezzanine-users] Re: Proposal: page_move signals
On Mon, May 26, 2014 at 11:52 PM, Ahmad Khayyat akhay...@gmail.com wrote: Sure, but one issue is that violating the rule is expected to result in different reactions when creating vs. when moving a page. If a rule is violated in a page move, the page goes back to its original position. If a rule is violated while creating a page, there should be a way to determine a default position of the page. How about this, along the lines of page permission methods: can_move(self, new_parent) That sounds spot on - and I think it'd work well with most of the work you've done. We'd just replace the signals with a call to can_move and all the error propagation stuff should work the same way you've got so far. Since we have the other page permission methods, and no signals defined throughout Mezzanine, this really makes sense in terms of consistency. Should make documenting easier too since everything's falls under the same umbrella. Should return a Boolean and an alternative new_parent and error message if the Boolean is False? It would be called by Page.save() and by admin_page_ordering. The problem with creating a page is that you cannot modify the page order in the change form, so using validation won’t work. Disallowing the save is not really desirable because the user would have to recreate the page and reenter all the data. But still, what should happen if the rule disallows top-level pages and an alternative parent is not provided? -- Back to the original pull request, note that the current situation is that I can enforce rules for page position during page creation by overriding the save method, but there is no mechanism for applying any rules to page moves. The purpose of the pull request is just to introduce that hook. On Mon, May 26, 2014 at 4:26 PM, Stephen McDonald st...@jupo.org wrote: Sure - but if that's the intended use case then perhaps we need a better approach. I tried to implement something like this with page permissions, but I don't think they cover the case of moving a page: http://mezzanine.jupo.org/docs/content-architecture.html#page-permissions There really should be one way to implement these rules. On Mon, May 26, 2014 at 11:23 PM, Ahmad Khayyat akhay...@gmail.comwrote: Put another way: creating an instance is not a page move. On Mon, May 26, 2014 at 4:21 PM, Ahmad Khayyat akhay...@gmail.comwrote: Right. Yes, they can. But that would be handled by the save method of the MyPage model (this is what I do in my app). I don't know of a way to handle it in the page tree. On Mon, May 26, 2014 at 4:18 PM, Stephen McDonald st...@jupo.orgwrote: Seems incomplete for the use-case - couldn't the user create a new MyPage instance as a top-level page? On Mon, May 26, 2014 at 10:26 PM, Ahmad Khayyat akhay...@gmail.comwrote: Any comments? Any additional information required? Here is an example that uses this feature to disallow pages of type MyPage to be top-level pages: from mezzanine.pages.signals import pre_page_move @receiver(pre_page_move, sender=MyPage)def my_move_constraints(sender, page, new_parent, **kwargs): if new_parent is None: return Pages of type MyPage cannot be top-level pages If a user drags a MyPage to a top-level position in the page tree in Mezzanine admin, the page will be moved back to its original position, and an error message will be displayed using Django messages. The text of the error message is the returned string: “Pages of type MyPage cannot be top-level pages”. A subsequent valid move will remove the error message. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/bIxUJkOIdUM/unsubscribe . To unsubscribe from this group and all its topics, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to a topic in the Google Groups Mezzanine Users group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/mezzanine-users/bIxUJkOIdUM/unsubscribe . To unsubscribe
Re: [mezzanine-users] Re: modeltranslations - round 2
BTW to answer your earlier question - any slug creation logic definitely belongs on the model (Slugged I believe) rather than an admin class. On Tue, May 27, 2014 at 12:30 AM, Mathias Ettinger mathias.ettin...@gmail.com wrote: Well, I started from something similar in the first place. I think it is good enough for an external app, but not so good if we want a tight integration. First off all, the field duplication issue mentionned in the project is directly handled when modifying mezzanine and using the right base classes for the admin. As opposed to either patch django-modeltranslation or add redundant information in the translation.py file. Then, the form submit button issue requires a (minor) modification to mezzanine to works properly. Both the slugs being generated for the active language issue and the language selection on the frontend site need mezzanine to be aware of modeltranslation to work. Or at least mezzanine should consider the USE_I18N setting for these tasks. Translatable settings such as SITE_TITLE or SITE_TAGLINE would be a pain in the ass to handle from an external app. Needless to say it would be even harder to make it support custom translatable settings (those defined in an external app default.py). With this implementation it comes out of the box. I understand your reasoning in the sense that: the less file we modify, the less error-prone it will be and the less cumbersome it will be to maintain. But I have the feeling that a tighter integration will both make issues easier to spot and fix and ease the development of future features with translation needs. As an example, the pull request I made for cartridge compared to the two-files approach I proposed in the bug tracker ( https://gist.github.com/Kniyl/11249940). Defining model methods outside of their class is anything but a good idea. That is why I spend my time trying to provide the best approach within mezzanine: I’d like to get rid off the ugly external app that I’m using. I’m also confident that this work is very close to completion. Missing features are: translation field for keywords (that I don’t know how to handle, yet), translation field for slug (that need further discussion) and a nice tab-based grouping of fields in the admin (that Eduardo plan on doing). The only concern for now is about where to put the translation validation logic. In my opinion, the admin is a good place rather than in the model, because it lets people who knows what they are doing achieve their goals more easily. But I might be wrong. Le lundi 26 mai 2014 15:24:50 UTC+2, Stephen McDonald a écrit : Any thoughts on this implementation? https://github.com/Romamo/mezzanine-modeltranslation/blob/master/ mezzaninemodeltranslation/translation.py It was mentioned in the discussion against the pull request but no comments were made. I really like how this approach doesn't require any change to Mezzanine itself, as opposed to the proposal here which is a real concern. On Mon, May 26, 2014 at 10:52 PM, Mathias Ettinger mathias@gmail.com wrote: I need to take a decision, so I’ll ask here instead. I was trying to write some tests for modeltranslation integration and I stumbled upon an issue. Basically I was trying to test that slugs are always generated based on the default language using the model logic (Page.save()) whereas the slug issue was fixed using the admin logic (ModelAdmin.save_model()). Obviously my test fails. But I’m wondering wether it should be fixed by testing the admin behavior or by implementing the slug logic into the Page model. As a more general question, there are some fields that are auto-populated based on other one and both are marked for translation. They are handled by the admin which saves the model several times (one for each language). Is it acceptable or should this logic be moved to the Displayable model? -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-use...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Stephen McDonald http://jupo.org -- You received this message because you are subscribed to the Google Groups Mezzanine Users group. To unsubscribe from this group and stop receiving emails from it, send an email to mezzanine-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
