We're running a Django website with rough 45 install Django admin classes. The handler is mod_fastcgi. Every once in a while about half the admins disappear from /admin/ screen. Touching the production.fcgi file restores everything to normal, but we have yet to determine the underling cause.
Any thoughts on what the underlying issue might be?
Django turns off admin for the model when it encounters an exception in admin. Examine admin code and make proper exception handling.
Related
Django 1.11
If I click Groups in Django admin site, I can see a list of groups. Namely, the address is http://localhost:8000/admin/auth/group/
I monitor the CPU usage in terminal. Python is consuming 4-5 % now.
I have organized 4 groups. So, if I click any group, the server just calculating something for several minutes. The address now is like http://localhost:8000/admin/auth/group/6/change/
Maybe about 5 minutes the server is calculating something. And Python is now consuming 100 % of CPU resources.
Well, Django admin is analyzing something.
I have about 23-25 models. Well, this is not a very big number of models.
Each model is 3 standard permissions (add, change, delete). And I created one permission myself in the Meta class of a model.
So, as soon as "Change group" page is in front of me with available permissions and chosen permissions, CPU consumption by Python is again 4-5 %.
Could you comment on this? Is it curable?
Came across this issue when using django debug toolbar with the built in django admin app. The change/update page was incredibly slow locally (sometimes it would not load at all) but if I set DEBUG=False (thus turning the debug toolbar off) it worked as expected. In my particular case, I didn't need the debug toolbar for the admin app so I disabled it for only those admin URLS like so:
# settings.py
DEBUG = True
def show_toolbar(request):
# disable debug toolbar for built in admin app urls only
if request.path.startswith('/admin'):
return False
else:
return True
DEBUG_TOOLBAR_CONFIG = {
'SHOW_TOOLBAR_CALLBACK': show_toolbar,
}
We're using the same setup as Max Malysh:
Django 1.11
A custom User model based on django.contrib.auth.models.AbstractUser
The custom user model set in the settings via AUTH_USER_MODEL variable
We've got the same issues and I think I found the issue, or at least the module which is causing the delays. It has nothing to do with Django and/or the DEBUG mode itself, because I think the issue is within the debug_toolbar.
If you deactivate the debug_toolbar application and debug_toolbar.middleware.DebugToolbarMiddleware middleware, it works like a charm.
I didn't had the time to reverse-engineer it, but I'll have a look at it when I find the time. In the meantime and as a workaround, deactivate the debug toolbar if you don't need it.
Sorry, it's not a final solution yet, but I thought I'll share my findings in case they can help somebody.
Cheers
Domi
EDIT/UPDATE: It has something to do with the Template panel of the Debug Toolbar. If you deactivate it, you'll have a much faster response time!
I've encountered the same problem when adding a new group with Debug=True in settings.py.
The same code works fine with Debug=False.
Some background information:
We use Django 1.11
We use custom user model inheriting from AbstractBaseUser
There are ~30 models registered on the admin site
Django debug toolbar output:
I was experiencing this same problem, but probably for a different reason than the OP was.
If you have a large number of Users, look at your admin.py and make sure that you are not displaying Users inline on the Group admin page. That can cause very slow loading of the Group admin page if the Group has a large number of users in it.
I just started using django-cms 3.01 and django 1.6.4/python 2.7.6. My last experience with django was 1.4 and I've never used django-cms before now.
I am trying to follow the instructions in the official documentation on Extending the Page & Title Models, but I am experiencing an issue.
The custom field I need to add is very similar to the example, so I simply used their code exactly. Rand a syncdb, started the server and everything was going well. The field shows in the admin just fine. There is an entry in the admin menu for "Icon Extensions." I click add, and I get to the form to upload the file. I go to upload the file, and I receive the following error:
DoesNotExist at /admin/the_site_name/iconextension/add/
IconExtension has no extended_object.
...
Exception Type: DoesNotExist
Exception Value: IconExtension has no extended_object.
Exception Location: /Users/me/Sites/the_site_name/env/lib/python2.7/site-packages/django/db/models/fields/related.py in __get__, line 326
Most likely I'm just missing something simple, but I can't figure it out. Should I have a foreignkey linking it directly to the page? I thought it was handled automatically, but obviously I'm not completely getting it jsut yet.
Any help is appreciated.
You must edit extensions in the frontend editing toolbar. Add a button to toolbar as described in the section "Adding a Toolbar Menu Item for your Page extension" in the documentation you linked above.
I'm getting this weird AttributeError on the app I'm currently working on. I'm developing using the development web server i.e. "runserver" command of django toolsets. Then I decided to test the application on apache+mod-wsgi and I persistently get this error though it works fine sometimes. So I think there must be something wrong with that piece of code,
so I decided to comment it out and see what happens. And YES, it still give me the same error (See 2nd picture). <-- NOT RELEVANT NOW. The AttributeError I'm getting on custom User model, even if it actually contains the classmethod get_by_type_and_id() is what I'm interested on.
Have you even seen like this one before? What do you think is causing this? I've followed the tutorial here to deploy it. Note though that User is not the built-in django User model. I think it's a "customized,stripped-down" implementation based from the django's Auth module.
Note that I have not gotten this error on my development using django's own development server. This only happens when I deployed the app on Apache+mod_wsgi.
More Info:
Django version == 1.2.5
Thanks! I'd really appreciate any kind of help.
First Picture:
2nd Picture:
Few things to notice:
Are you sure that you have get_by_type_and_id method for the User?
You set pasword instead of password (typo)
I think you have to indent line 60 in your second screenshot
After hours of diving into the code, I had a eureka moment. So I thought, maybe at some point django.contrib.auth.models.User model is being put into action by some django module used in the application. Because like I mentioned, this app's User model is customized and the application is not using django.contrib.auth.* at least directly. This was my suspicion because this kind of error is not specific to that particular attribute. Sometimes it gets through that point, but then another AttributeError would occur on some other view referring to other User model attributes. Then at one point I noticed that the attributes of User in the error messages was that of django.contrib.auth.models.User.
So I decided to "remove" django.contrib.auth.models on my python path, and there it showed, an error occurred in one of the modules I'm using specifically django.contrib.messages. I removed it, and I'm not seeing the AttributeError again. It turned out that django's Message model has a foreign_key to django.contrib.auth.models.User.
But then, I lost the flexibility of django message framework, especially when I'm using it on view with a HttpResponseRedirect i.e. no way to put useful messages in a template's context. or maybe there is? :)
UPDATE 2 (Pretty Sure Now):
Yes, I'm pretty sure now that django.contrib.messages is the one causing the error. I tried reproducing the error on another application which uses the customized User model i.e. not django.contrib.auth.models.User. I enabled django.contrib.messages module and produced basically the same error. I would like to know why is this happening on Apache+mod_wsgi, but not on django's own development server.
I just delayed my first Django app via Heroku and I'm having an issue that's proving very difficult to resolve. I have django-registration and profiles installed and apparently something runs afoul unless the 'django.contrib.sites', and SITE_ID is removed from settings. Unfortunately, when content is submitted by a user to be displayed, I'm getting the following error:
TemplateSyntaxError at /Caught AttributeError while rendering: 'Settings' object has no attribute 'SITE_ID'.
Only when deleting the user submitted content via the admin does the site reestore.
Adding django.contrib.sites and SITE_ID back just kills the whole app. These issues did not arise during initial development, but only began when the app was deployed. Looking to see if anyone has any insight or advice on how to resolve this.
What kind of error do you get when you add SITE_ID in the settings file?
This problem usually occurs when there is a discrepancy with data in the table django_site. Check if your dev and prod database have the same values in that table. Some models may refer to some Django models that use the Site models itself, and unless they cannot find a valid django.contrib.sites.models.site instance in the database, they will raise an exception. This happens if using the FlatPage models for instance.
I have a Django project that employs modeltranslation. On the development box, it registers 10 models and works flawlessly.
On the production server, when started it notifies that it has registered "0" models (instead of 10) and doesn't throw any exceptions. However when any admin page that shows a should-be-registered model is visited, the NotRegistered exception is thrown.
All non-admin pages, and admin pages that don't include translated models work without problems.
Suggestions are highly appreciated.
Moving the modeltranslation folder from the project folder into the packages folder resolved the issue.
have a look into your database, i would bet that "syncdb" did not add the required colums/tables
if you have no production data on the database: simple delete it and re-sync it