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.
Related
I'm nearly done with my Django app and I was wondering if it's to create a custom page where the app user admin will be able to cahnge one-off overall app settings like language, timezone, currency, URL slug, app limits (e.g. Max number of xyz, default abc etc) etc Is this possible? Feel like I'm missing a trick here. Any advice or resoucrces would be great.
I tried to find a way to use the filter that gives the Django Admin in my applications, as you know by just adding "list_filter" in admin.py, to enter the Admin, our results can be filtered, I would like know if there are ways to use the same application but in my own projects
Thanks!!
You can use ListView and add a filter form to context. It's not like "add one line to admin class" but it does not need much time to do too.
Django has lots of magic in admin site because built-in powerful admin site is one of Django's killer features. So it works out-of-the-box without setting up static url and with only tiny admin module linking your models. But all this magic is not isolated and in most cases cannot be used outside the admin.
I am using django 1.2 to create a multi site shop. I need multiple admin logins for each shop instance, e.g.
site.com/au/admin
site.com/uk/admin
and so on.
I have a middleware class and a dbrouter that handles database connections based on the URL. This works fine.
I am trying to add some customisation per admin system based on what is available for that particular shop. So:
in admin.py :
if country == 'au':
admin.site.register(Orders)
admin.site.register(Payment)
if country == 'uk':
admin.site.register(Store_locator)
etc.
Hers's the problem: If I log into the AU version of the site the admin system displays the correct elements for AU. If I then log into UK, it still shows the AU version of the admin system, so the above code seems to only get used on the first load. if I kill the django server and restart it, then go into the different shop admin page, it will have reconfigured for that shop.
How I can get it to pick up a change in country each time the admin system loads? Why is this problem happening in the first place?
Any help would be greatly appreciated.
Thanks,
imanc
I'd bet that Django doesn't read the admin config on each request, but on each time the server is restarted - that's why it 'sticks' to whichever you accessed first.
Why not do something with Django.contrib.auth's permissions to limit what a particular admin user can see in the admin, and register all the models in admin.py as standard?
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.
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