I have finally found the answer of this completely crazy stuff looking at Django's documentation for Django 1.7 ! Here : https://docs.djangoproject.com/en/1.7/ref/contrib/admin/#django.contrib.admin.autodiscover it says that until Django 1.7 you needed to call "admin.autodiscover()" by yourself. And Mezzanine uses autodiscover in its LazyAdmin, but it is never called in Django 1.6 until the user calls it explicitly !
So as a conclusion : if you use *Django 1.6.x, add* admin.autodiscover() At the end of your *admin.py* application's file ! Hope this will help, my problem is now fixed! Le vendredi 12 septembre 2014 16:39:57 UTC+2, Stephen McDonald a écrit : > > My test app that contains my profile model is at the top of INSTALLED_APPS > too. The order is important, but any importance is forced into place by the > call to `set_dynamic_settings` at the end of the settings module (I believe > it forces mezzanine.boot to the top) - if you've removed it, that could > explain it. > > Otherwise I'd suggest trying a new project with no modifications other > than adding an app with a profile model, the relevant settings, and nothing > else. Presumably that should work - you'll then be in a position to apply > your changes to it step by step, until you can reproduce the error. That > will at least help you isolate the problem. > > Good luck. > > > > > On Sat, Sep 13, 2014 at 12:33 AM, Jérôme Sivadier <[email protected] > <javascript:>> wrote: > >> Maybe it's my settings.py file then :/ The order of INSTALLED_APPS and >> shouldn't be important, should it? >> Here's my order just in case : >> INSTALLED_APPS = ( >> "myApp_theme", >> "myApp", >> "django.contrib.admin", >> "django.contrib.auth", >> "django.contrib.contenttypes", >> "django.contrib.messages", >> "django.contrib.redirects", >> "django.contrib.sessions", >> "django.contrib.sites", >> "django.contrib.sitemaps", >> "django.contrib.staticfiles", >> "mezzanine.boot", >> "mezzanine.conf", >> "mezzanine.core", >> "mezzanine.generic", >> # "mezzanine.blog", >> # "mezzanine.forms", >> "mezzanine.pages", >> # "mezzanine.galleries", >> "mezzanine.twitter", >> "mezzanine.accounts", >> #"mezzanine.mobile", >> ) >> >> >> >> Le vendredi 12 septembre 2014 16:28:20 UTC+2, Stephen McDonald a écrit : >>> >>> I didn't use one. >>> >>> On Sat, Sep 13, 2014 at 12:26 AM, Jérôme Sivadier <[email protected]> >>> wrote: >>> >>>> Thanks for your answer. Could you post your gunicorn configuration >>>> file? I have certainly made some errors in this part of my project :/ >>>> >>>> Le vendredi 12 septembre 2014 16:25:12 UTC+2, Stephen McDonald a écrit : >>>>> >>>>> I'm unable to reproduce this - works fine for me with the same >>>>> gunicorn version. >>>>> >>>>> On Thu, Sep 11, 2014 at 6:40 PM, Jérôme Sivadier <[email protected]> >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I've digged for one day to find what is the problem and here is an >>>>>> interesting conclusion : Mezzanine was the problem because of >>>>>> mezzanine.boot.lazy_admin. >>>>>> Let me explain a bit : >>>>>> >>>>>> So I am using Mezzanine (3.0.10) + Gunicorn (19.1.1) and I discovered >>>>>> model registration does not have the same behaviour using the built-in >>>>>> Django webserver and using Gunicorn. Indeed when I use Gunicorn, all >>>>>> custom >>>>>> models calling *admin.site.unregister* and then *admin.site.register* >>>>>> (for instance *User*) are not updated in Django. >>>>>> >>>>>> After a lot of debugging (based on file writing), I realized that : >>>>>> * On the first call of *admin.site.register(User, UserAdmin)* (by >>>>>> Django), *django.contrib.admin.sites.AdminSite.register* is called >>>>>> and then *mezzanine.boot.lazy_admin.LazyAdminSite.register(User, >>>>>> UserAdmin)* >>>>>> * Then Mezzanine calls *admin.site.unregister(User)* but it doesn't >>>>>> go to AdminSite.unregister, it only goes to LazyAdminSite.unregister >>>>>> * After this, Mezzanine calls *admin.site.register(User, >>>>>> UserProfileAdmin)* but it doesn't go to AdminSite.register, it goes >>>>>> right to LazyAdminSite.register >>>>>> ... >>>>>> And so on. >>>>>> >>>>>> In the end, only Mezzanine's LazyAdminSite knows what is the "real" >>>>>> admin model associated with the given model class but Django does not ! >>>>>> Here is a trace of the register/unregister calls done by Mezzanine >>>>>> and Django : >>>>>> REGISTER <class 'django.contrib.auth.models.Group'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.auth.models.Group'> AS < >>>>>> class 'django.contrib.auth.admin.GroupAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'django.contrib.auth.models.User'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.auth.models.User'> AS < >>>>>> class 'django.contrib.auth.admin.UserAdmin'> >>>>>> calling super... >>>>>> MEZZANINE UNREGISTER <class 'django.contrib.auth.models.User'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.auth.models.User'> AS < >>>>>> class 'mezzanine.core.admin.SitePermissionUserAdmin'> >>>>>> >>>>>> MEZZANINE UNREGISTER <class 'django.contrib.auth.models.User'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.auth.models.User'> AS < >>>>>> class 'mezzanine.accounts.admin.UserProfileAdmin'> >>>>>> >>>>>> MEZZANINE UNREGISTER <class 'django.contrib.auth.models.User'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.auth.models.User'> AS < >>>>>> class 'bm_marketplace.admin.CustomUserProfileAdmin'> >>>>>> >>>>>> REGISTER <class 'django.contrib.redirects.models.Redirect'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.redirects.models.Redirect'> >>>>>> AS <class 'django.contrib.redirects.admin.RedirectAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'django.contrib.sites.models.Site'> >>>>>> MEZZANINE REGISTER <class 'django.contrib.sites.models.Site'> AS < >>>>>> class 'django.contrib.sites.admin.SiteAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'mezzanine.conf.models.Setting'> >>>>>> MEZZANINE REGISTER <class 'mezzanine.conf.models.Setting'> AS <class >>>>>> 'mezzanine.conf.admin.SettingsAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'mezzanine.generic.models.ThreadedComment'> >>>>>> MEZZANINE REGISTER <class 'mezzanine.generic.models.ThreadedComment'> >>>>>> AS <class 'mezzanine.generic.admin.ThreadedCommentAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'mezzanine.pages.models.Page'> >>>>>> MEZZANINE REGISTER <class 'mezzanine.pages.models.Page'> AS <class >>>>>> 'mezzanine.pages.admin.PageAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'mezzanine.pages.models.RichTextPage'> >>>>>> MEZZANINE REGISTER <class 'mezzanine.pages.models.RichTextPage'> AS < >>>>>> class 'mezzanine.pages.admin.PageAdmin'> >>>>>> calling super... >>>>>> REGISTER <class 'mezzanine.pages.models.Link'> >>>>>> MEZZANINE REGISTER <class 'mezzanine.pages.models.Link'> AS <class >>>>>> 'mezzanine.pages.admin.LinkAdmin'> >>>>>> calling super... >>>>>> REGISTER = Django's AdminSite.register() >>>>>> MEZZANINE REGISTER = Mezzanine's LazyAdminSite.register() >>>>>> >>>>>> >>>>>> So I have tried to Monkey-patch LazyAdminSite.register() by calling >>>>>> super on register and unregister and it basically works great on my >>>>>> Gunicorn installation ! But I guess it will have embarrassing >>>>>> consequences? >>>>>> Here's the working code of LazyAdminSite >>>>>> def register(self, *args, **kwargs): >>>>>> for name, deferred_args, deferred_kwargs in self._deferred: >>>>>> if name == "unregister" and deferred_args[0] == args[0]: >>>>>> self._deferred.append(("register", args, kwargs)) >>>>>> break >>>>>> #else: >>>>>> super(LazyAdminSite, self).register(*args, **kwargs) >>>>>> >>>>>> def unregister(self, *args, **kwargs): >>>>>> self._deferred.append(("unregister", args, kwargs)) >>>>>> super(LazyAdminSite, self).unregister(*args, **kwargs) >>>>>> >>>>>> I can provide additional information / tests if needed. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> Le mercredi 10 septembre 2014 10:50:32 UTC+2, Jérôme Sivadier a >>>>>> écrit : >>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I am currently working on a website based on Django (1.6.7) + >>>>>>> Mezzanine (3.1.10) and I am facing problems with the Admin side. >>>>>>> In my application I have a custom User model (named BMUser) and I >>>>>>> have declared it in *settings.py* like this : >>>>>>> AUTH_PROFILE_MODULE = "myApp.BMUser" >>>>>>> >>>>>>> On the development side, everything works great but when I go on the >>>>>>> production side (same code but I use postgres instead of sqlite and >>>>>>> gunicorn) Mezzanine's *UserProfileAdmin* doesn't show up... I only >>>>>>> get Django's UserAdmin which doesn't add a reference to "myApp.BMUser" >>>>>>> at >>>>>>> the bottom of the user management. >>>>>>> >>>>>>> I have *Mezzanine.accounts* in my INSTALLED_APPS (settings.py) and >>>>>>> the configuration between development and production side seem to be >>>>>>> the >>>>>>> same. >>>>>>> >>>>>>> Any ideas? Thanks in advance ! >>>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
