I've installed multiselectfield on my machine and it works well. I can choose multiple items thanks to multiple checkboxes in admin:
Then I had to copy/paste all the files of the project to my VPS using Filezilla. So I have the exact same code and the exact same files locally and remotely. The site works well remotely (the VPS django admin page too).
However on the server's django admin page, the multiselectfield widget shows a simple text field instead of an actual list of checkboxes, plus it says Enter a list of values. when I try to validate the form.
So, how is it, that with the same code at two different places, the multiselectfield acts differently and how to I fix this ?
my field looks like this in the model:
ram_list = tuple((ram.ref, ram.name) for ram in RAM.objects.all())
ram = MultiSelectField(choices=ram_list)
Related
I've just set up a new local version of my django application, and all working fine until I checked on the django admin.
127.0.0.1:8000/admin works fine and brings up the usual Django Admin homepage with full list of apps, but when I click into any of the individual app elements it breaks. The URL changes, but instead of displaying that app's admin site it shows an oddly rendered version of the admin homepage, with the app list collapsed on left side of screen (see screenshots below)
Can't immediately see which parts of codebase could be relevant here, so please request copies of any code you want to see.
The correctly displayed Django Admin homepage
How it renders when I click into any of the individual app/model admin sites
As above, with list of all apps expanded from left
This happened to me when I upgraded to django 3.1.
Set admin.site.enable_nav_sidebar = False on your admin.py file.
from django.contrib import admin
admin.site.enable_nav_sidebar = False
Actually the admin does load the pages for every model but the nav_sidebar takes all the space. If you zoom out long enough you'll see the models and forms are there.
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 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.
On the web page, I get the following error:
FieldError at /foo/bar/
Cannot resolve keyword 'foos' into field. Choices are: __unused__, [snip]
The problem code is
User.objects.filter(foos__name='bar')
When I run this in the shell, it works and I get a recordset:
>>> User.objects.filter(foos__name='bar')
[<User: JordanReiter>]
But on the webpage I get the exception above.
I've never run into this issue before and I wonder if I'm missing something?
Update
Based on doing a diff between the "Choices are: ..." on the web and in the shell it appears there are 7 fields that are available in the shell that aren't available if I do the query on the web. They appear to be ordinary ForeignKey fields pointing to User, with no difference from the other fields that work.
Tested So Far
INSTALLED_APPS are identical for both settings
runserver version also works (as would be expected)
User used is identical in both cases and is django.contrib.auth.models.User
related names for the shell's User and the web app's User are definitely different. User._meta.get_all_related_objects() in the shell displays around 7 more related fields than the if I dump that from the web app.
values for settings are also basically identical (one has the TEST_XYZ settings but those don't affect anything)
This is only sort-of an answer. Turns out the reason that the field is not available is because all of the installed apps' models do not correctly load in when the app is first compiled, so the app permanently believes certain fields don't exist, even after they recognize the models for those fields do exist. It appears to be related to this earlier, equally confusing problem:
SO: Internal Server error on the first request (and only the first request) after server reload
Oh, and so how I fixed it was to change areas of code that imported the models that the web server couldn't find on the first request. Somehow, omitting those meant that the server would recognize that the fields in question were present. Super weirdness!
Reverse foreign keys are only added to models if the app they are in is in INSTALLED_APPS. I know you say that your settings.py is the same as in development, but somehow it is the case that your foo app is in INSTALLED_APPS locally, but not on the server. Do you have a local_settings override perhaps?
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?